IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-07-09. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
Telechat:
3.4.2 Returning items
3.4.3 For action
Telechat:
1102 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
7. Working Group News
1123 EDT Adjourned
(at 2015-07-09 06:00:03 PDT)
draft-ietf-hybi-permessage-compression
The secdir reviewer's comment about modifying the signalling seems to me to be something that the hybi WG needs to have debated. Did that happen?
*** Substantive Comments: *** -- I think Robert Spark's secdir comments concerning an intermediary changing the signaling of extensions deserves some thought. -- section 5, several example paragraphs: It's odd to find normative language in example. I _think_ the actual normative text is all covered elsewhere--if so, it should be written descriptively here. -- section 5, paragraph 6: ""Agreed parameters" MUST represent..." That seems more a statement of fact than a normative statement. If it's intentionally normative, the required condition is vague for a MUST. -- 6.1, Numbered list entry "2", third bullet (and several similar assertions) Do I understand correctly that the PMCE needs to know if the next extension wants frames, in order to determine whether to build them? How would it know that? -- 9: I’m surprised that there’s nothing here about intermediaries. For example, if an endpoint chooses not to compress because of the mentioned issue with encrypting compressed data, does it have to worry that some intermediary might choose to compress it anyway? -- 12.2, [CRIME] Seems like this may need to be normative. I’m not sure the reader can fully understand the security considerations without reading it. ***Editorial Comments:*** -- Section 3, first paragraph, last sentence: That seems true anytime a draft or RFC defines terms--what is special about these? -- 3, third paragraph: "An extension in use next to extension" The construction "next to" usually connotes adjacency, not order. I suggest "The next extension in use" (without the "to"). -- 8, 2nd to last paragraph: While you cited the LZ77 bits earlier, it would be useful to repeat that citation here. This is where the information actually gets used. -- 8.2.3.6: It's odd to refer to anything done by a computer as "manual".
I support both of Ben's comments that mention intermediaries.
warren kumari's opsdir review (no further action required) Be ye not afraid. I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-hybi-permessage-compression-22 Summary: Ready, no nits, no comments. Details: Well, this is a first -- I have never before performed a review without finding at least some nits (typos, grammar, etc). Because I feel bad about not having *any* comments I'll scrape the bottom of the barrel -- I find the use of underscores jarring in e.g: 'This document references the procedure to _Fail the WebSocket Connection_. ' and think these could be replaced with quotes instead. I'll fully admit this is bikeshedding. Oh, the title on Section 8 also looks a little odd, was the 'p' intended to be uppercase? Could go either way... There are no operational impacts that I can see, other than less traffic on the wire, and more code in network devices if any of them are websocket servers or clients (e.g for management). W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
draft-ietf-dhc-dhcpv6-active-leasequery
This might seem like a lot of discuss points, but it's really two main ones (privacy and use of TLS) broken out into what I think are separable questions that might help us get the discussion done quicker. (1) I'm not sure I'm following the use-cases for this but clearly this protocol could be used as part of a pervasive monitoring toolkit, to track users or client-devices with very fine granularity. So a) can you explain the main valid use-case(s) and b) did you consider RFC7258 in developing this protocol? The answers here might well result in a few changes to my other discuss points below. I also had a quick peek at 5460, but note that pre-dates 7258 by quite a bit and I'm also not clear how or if this protocol has the same goal of restoring routes. Note also that I am not claiming that there are no good uses for this protocol, I'm just asking what (some of) those are and how you considered the PM issue. (2) I also think you need to add (or reference) privacy considerations text here - the information accessible via this could have significant privacy impact. (3) Along the lines of (1) - can you say why all of the various bits of data one could return are needed by the requestor here? If not, then isn't there a good data-minimisation case to be made for profiling down the information returned to the requestor? I think one can validly argue that the answers we arrived at in 2009 (for 5460) might not be those on which we'd reach consensus today, but this draft seems to (quite understandably) assume that 2009's answers are still good enough. Did the WG consider that? (4) Having TLS is good. But I don't get why you've not reversed the TLS client/server roles to make the requester the TLS server, since it seems to me that authenticating and authorizing the requestor here is the main thing and not authenticating the DHCP server. So why not reverse the TLS roles? (I'll clear this quickly but wanted to check in case it'd not occurred to folks.) (5) The TLS mutual authentication requirement is underspecified. The sentence in 9.1 isn't really enough I think, you need to say that all TLS sessions MUST be mutually authenticated and then that has administrative consequences that might need more text. For example, the DHCP servers need to trust the set of CAs that requestors use - is it ok to be just silent on that? I also wonder about naming and other things - does there need to be some profile of how the DHCP server is named vs. a TLS certificate? (6) Why not just make the use of TLS mandatory or RECOMMENDED here anyway - would that really hurt?
- I had a look at the DHCPv4 equivalent - is the plan that those be as close to one another as possible? If so, then the "DHCPTLS" vs. "STARTTLS" thing seems odd, as does the duplication of text in the two - would it not have been better to develop a separate spec for how to talk to a DHCP v4 or v6 server using TLS? I think that'd be cleaner for all sorts of reasons, e.g. naming, the roles of the peers, TLS extensions needed etc. - sections 8/9: Sending the DHCP REPLY with no status code as a way to indicate acceptance of TLS seems very hacky. Why is that a good plan? I don't think STARTTLS works that way in other protocols for example. - somewhere: I think it'd be a fine thing if you referred to RFC7525/BCP195 and said implementations need to follow that in how they use TLS. - section 10: why is (the usually mythical:-) 3315 a MUST NOT here? I don't get that. I could see it being an EDONTCAR but I don't see the harm if one did go mad and try use 3315. And I could maybe, possibly, with a lot of a nose-holding, see a universe in which one might use TLS server auth for the DHCP server and 3315 to authenticate the requestor, so it seems odd to rule that out in this way.
-- general: I understand this to be a way for a third party to "actively" monitor client DHCPv6 bindings. Does that warrant some privacy considerations? -- section 8.2: The selection of secure vs insecure mode MAY be administratively selectable. It seems like there should a stronger requirement for an administrative option to force secure mode.
I believe the questions from Francis Dupon wrt TLS usage and full specification deserve at least an answer, if not even a clarification in the document. Please take a look!
No objection, but if taken into account, Scott's OPS DIR feedback would improve the document. ================================= Scott, We totally agree that this protocol should be able to restrict who gets the information about what is going on with the DHCP server. We *thought* that we had that covered... The current draft has TLS connections as a SHOULD, and includes the following text at the end of section 9.1: > In the event that the DHCPv6 server sends a REPLY message without > DHCPv6 status code option included (which indicates success), the > requestor is supposed to initiate a TLS handshake [RFC5246] (see > Section 8.2). During the TLS handshake, the DHCPv6 server MUST > verify the requestor's digital certificate. > If the TLS handshake is not successful in creating a TLS connection, > the server MUST drop the TCP connection. The intent here is that in requiring the verification of the requestor's digital certificate that the server would also be able to restrict connections to requestors that it considered acceptable. We recently took a lot of words out of the security considerations section on restricting connections to acceptable requestors because that would have required using IP addresses, which everyone thought was useless. We didn't put more words back in about the TLS certificates, but perhaps we should have? Anyway, there are several issues: 1. Does the verification of the TLS certificates allow the server to be able to determine that a requestor is or is not allowed to access the active leasequery capability? 2. We believe that there is more than one way to utilize certificates to decide if a requestor is allowed. We also sort of assumed that was documented elsewhere and wasn't something that we needed to detail in this draft. Do you know of a draft we could reference on how to do that, or failing that, know of text we could incorporate that explains how to do that. If #1 is no, then we are confused because we thought that was the point of verifying the digital certificates (instead of just using the certificate to ensure that the link is encrypted). =============================== Scott's answer: it is always useful to spell out what is on your mind if you are projecting that the use of certs equals access control you should just say that a few extra words would dog a LONG way Scott
I also support Stephen's discuss points.
I support Stephen's DISCUSS. I was wondering about the use cases as well.
I think opsdir feedback has been heard.
draft-ietf-6lo-btle
- I strongly support Alissa's DISCUSS and would argue that we ought really try hard to minimise any privacy leakage being contributed to by this specification. We basically have one chance to do this well, after which any leakage becomes yet another reason to not do the job well in future in other places. (Based on dodgy but often heard arguments like: "but IPv6/BTLE already dos this badly, so there's no additional harm in foo/IPv6/BTLE being just as bad.") I also note that the fact that some of that leakage relates to link local addresses doesn't really reduce the damage so much with a radio based link layer. (Yes, good l2 crypto could help there, but only if always used everywhere for all packets and I don't know if BTLE requires that, I suspect it does not.) - The secdir review in early June made a couple of points that are worth addressing. [1] I have not seen any response to that review. (Apologies if I missed it.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05744.html
I also fully support Alissa's discuss points on privacy. As the draft says, 'when available' for the security and privacy options, so anything that can be done should be to improve this for IPv6 over bluetooth. Having done some testing of the ability to monitor bluetooth, it can go up to 70' in certain conditions and much less in other conditions. We were also able to monitor through windows. This testing was done with an earlier bluetooth version monitoring point to point sessions in various conditions (it was a fun day at work). People and their IoT devices are much more exposed than they realize especially since the security and privacy options hat can be implemented often are not. That's just a long way of stating that I support Alissa's discuss.
Because of the history of this document, significant explanation was needed -- and provided -- in the shepherd writeup. Thanks, Gabriel, for the good job on that. The writeup says: > This support from BT SIG should address the remaining DISCUSS on > the original document. It does, indeed (it was my DISCUSS), and this document looks great. I'm glad things were sorted out with BT SIG, and thanks to everyone for all the work on this.
In this text: New addresses are typically generated each time a device is powered on. In random addresses all 48 bits are randomized. Bluetooth LE does not support device address collision avoidance or detection. However, these 48 bit random device addresses have a very small probability of being in conflict within a typical deployment. is the working assumption that if a random device address conflict does arise, either a human will recycle power because that's what humans do with electronic devices that don't work, or if no impatient human is available, the device will power off and back on eventually and everything will be fine? I'm looking at this text: In the rare case of Bluetooth LE random device address conflict, a 6LBR can detect multiple 6LNs with the same Bluetooth LE device address, as well as a 6LN with the same Bluetooth LE address as the 6LBR. The 6LBR MUST ignore 6LNs with the same device address the 6LBR has, and the 6LBR MUST have at most one connection for a given Bluetooth LE device address at any given moment. This will avoid addressing conflicts within a Bluetooth LE network. and guessing that the Bluetooth LE network doesn't have addressing conflicts, but does that mean that the device that's trying to use a random device address that would cause addressing conflicts if it wasn't being ignored will give up and choose another random device address?
My understanding from the discussions surrounding draft-ietf-6man-default-iids
was that RFC 6282 constitutes an exception to the main recommendation ("By
default, nodes SHOULD NOT employ IPv6 address generation schemes that embed the
underlying link-layer address in the IID") because the header compression
scheme in RFC 6282 requires that the IID be based on the link layer address. I
see no text that justifies a similar requirement in this document. I think if
this document is going to specify generating the IID from the device address as
the only address generation scheme for link-local addresses, it needs to
provide a justification for that. Otherwise, the default address generation
scheme should be one that generates an opaque IID of limited lifetime. The
possibility that the device address is generated randomly and refreshed on each
power cycle is important to note, but is not by itself sufficient justification
given what I assume is the wider deployment of static device addresses. If the
v6 address can provide better privacy protection than the device address, it
should.
On that point, there also seems to be a discrepancy between Section 3.2.2 and
Section 5. Section 3.2.2 states:
"(After a Bluetooth LE logical link has been established, it
is referenced with a Connection Handle in HCI. Thus possibly
changing device addresses do not impact data flows within existing
L2CAP channels. Hence there is no need to change IPv6 link-local
addresses even if devices change their random device addresses during
L2CAP channel lifetime)."
Section 5 states:
"The IPv6 link-local address configuration described in Section 3.2.2
strictly binds the privacy level of IPv6 link-local address to the
privacy level device has selected for the Bluetooth LE. This means
that a device using Bluetooth privacy features will retain the same
level of privacy with generated IPv6 link-local addresses."
If the IID remains the same even when the device address changes, then the IID
can be used to correlate activities of the device for the full lifetime of the
IID, which goes beyond the lifetime of the device address. So the "privacy
level" afforded by the device address is not the same as that of the IID. If
this document is going to specify the generation of IIDs based on device
addresses, why not regenerate the IID when the device address is regenerated?
Why does this draft reference v4.1 of the Bluetooth spec rather than v4.2? In 3.2.2, I think RFC 7217 should be added to the list in this sentence: "A 6LN can also use a randomly generated IID (see Section 3.2.3), for example, as discussed in [I-D.ietf-6man-default-iids], or use alternative schemes such as Cryptographically Generated Addresses (CGA) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBA, [RFC5535]), or DHCPv6 [RFC3315]." Similarly, in Section 5, s/[I-D.ietf-6man-default-iids]/[RFC7217]/ in this sentence: "For non-link local addresses implementations have a choice to support, for example, [I-D.ietf-6man-default-iids], [RFC3972], [RFC4941] or [RFC5535]."
from opsdir review by niclas comstedt Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document is for the Standards Track. This document defines how IPv6 is transported over Low Energi Bluetooth leveraging 6LoWPAN techniques for 802.15.4. I have no real feedback. The document is well written and makes sense to me. The compression details are a bit outside of my experience so didn’t get into all the details there. There are no real nits (one single referenced draft has a newer version) and my only semantical small change would be: - 3.2.4 first paragraph, remove “in this document”. Header compression as defined … … is REQUIRED as the basis … … Those two first sentences are a little repetitive which adds to it - 3.3, should this just be moved up under 3.2.1 or something? Its only referenced there unless I’m missing something and doesn’t need the context of what comes after.
draft-ietf-jose-jwk-thumbprint
This draft chooses the wrong input to the hash function. Other specifications, even those that do not otherwise use ASN.1 use the SubjectPublicKeyInfo ASN.1 structure for that. I raised that point in the WG and during IETF LC but was in the rough. Nonetheless, this will I believe need to be done over later when or if there is a need to identify a public key in a cross-protocol or similar context. That's a waste of effort for no good reason. The world won't end though.
-- Section 6 --
This specification adds to the instructions to the Designated Experts
for the following IANA registries, all of which are in the JSON
Object Signing and Encryption (JOSE) protocol category [IANA.JOSE]:
o JSON Web Key Types
o JSON Web Key Elliptic Curve
o JSON Web Key Parameters
Because you're changing the DE instructions, either this document needs to
"update" 7517 and 7518 (where those registries are defined), or it needs to
update the registries to add itself to the reference field
("[RFC7518][RFCxxxx]"). And in either case, it needs to make it clear in the
introduction that Section 6 provides additional instructions to the designated
experts for those three registries. Otherwise, it's too easy for DEs for those
registries not to notice this update. [I know the current DEs are well aware
of it. But that's not the point.]
Sarah Banks did the opsdir review.
draft-ietf-homenet-prefix-assignment
I support Brian's second Discuss point (on the text raised by Brian Carpenter). I believe I'm seeing changes to address that. Thank you in advance.
- section 3: I expected some security text here, not to say that this all needs to be encrypted but rather to say that because this is flooding, you can't really encrypt it and that hence this scheme is only suited for smaller deployments and/or those with lower layer security already in place. (And hence also probably small.) - section 3: Similarly, you could also add some privacy text to the effect that this scheme only applies where the privacy characteristics of the various prefixes involved are all roughtly similar, that is, where there's no real privacy difference in which prefixes end up with which nodes. (Mind you, I need to ponder that a bit myself to see if it's really the case;-) - sections 4 & 5: I found this impossible to understand in a (quick) linear reading. I'd find actual code easier tbh. It's interesting that Barry found this clear though (I did not, clearly:-) so this isn't a discuss. But why didn't you first provide an overview of the algorithm? - Where is the evidence that the algorithm converges? I'd have thought there would be a reference to an academic publication that also described the algorithm and a proof for convergence.
I don’t object to the publication of this document, but I do have several comments that I think should help in making it clearer. Comments: (1) Topology Changes. The Introduction reads: "Assigned prefixes do not change in the absence of topology or configuration changes. . .the algorithm also ensures that all assigned prefixes. . .remain unchanged, unless. . .the topology changes and renumbering cannot be avoided.” But later in Section 3. (Applicability Statement) you wrote that the "algorithm supports dynamically changing topologies”. What are then topology changes that may result in renumbering being unavoidable? (2) To Destroy. The term “destroy” is used in several places, but it is not defined in Section 2. It looks like Section 4.2. (Overriding and Destroying Existing Assignments) might define it, but instead it uses “destroy” to to define “Removing an Assigned Prefix”. Destroy seems to be the local action that may result in removing a Published Assigned Prefix. Please add to the terminology. (3) Unique Node IDs. Having unique Node IDs is important to break ties in the algorithm. However, the text seems to allow the existence of duplicate IDs for some (undefined) period of time. Section 3. (Applicability Statement) reads: "Node IDs MAY change over time and be the same on multiple Nodes at some point, but each Node MUST eventually have a Node ID which is unique among the set of participating Nodes.” How long is “eventually”? The sentence is (at best) confusing, but it reads as contradicting to me: If multiple Nodes can have the same ID, how can the MUST be enforced? You mention in the Security Considerations section that an “attacker. . .using a Node ID used by another Node may prevent the correctness and convergence of the algorithm. . .” Allowing for multiple Nodes to have the same ID is then an attack for however long “eventually” is. The same type of language (“eventually” and “at some point”) is used on other places. It would be nice to tighten the text up (where appropriate); for example, the part about “Each Node MUST have a set of non-overlapping Delegated Prefixes..” seems to be ok as it doesn’t mention that at some point the Delegated Prefixes may overlap, just that the sets may not be the same. (4) How is a Node ID defined? What I mean is: is it a number, a string, whatever? It sounds like the specific definition may be left to the Flooding Mechanism, is that true? If so, then I think it would be a good idea to call it out — this also means that as an operator I may have to redefine my Node ID assignment mechanism if I decide to change the Flooding Mechanism. The ordering of the Node IDs will also depend on how they are defined. BTW, “Node ID assignment mechanism” is mentioned in the Security Considerations, but not defined anywhere. It may of course not be an in-the-network mechanism and simply a manual assignment of IDs — it would be nice to say something about what it is (or may be). Nits: (A) Consistency in naming. For example: “Available prefix” is defined, but later “available prefix” is used (I think) to refer to the same thing. Given that common words are used (Available, Valid, etc.) it is important to differentiate when the specific term is used vs just the generic use of the word. Precedence is defined in Section 2.1, but later not used in Section 4. That is ok (except for the text in Section 4 that calls it out) given that it looks like the term is used when defining Best Assignment and Valid — I say it "looks like it" because “precedence” (not “Precedence”) is used. Should it be “Precedence”? Valid (capital V) is also defined but not used later. There are a couple of places where maybe “Valid” should replace “valid”. (B) Section 2. (Terminology) In the definition of “Private Link”, I think the “MAY” should really be “may”. There’s nothing normative about the example. (C) s/received from the Flooding Mechanism/received through the Flooding Mechanism
I'd also like to see the security and privacy text Stephen suggests in his first 2 comments. Thanks.
Well written and clear; thanks.
I agree with Alvaro and Brian on the need to clarify topology changes. In Sec 3, I see " The algorithm supports dynamically changing topologies: o Nodes may join or leave the set of participating Nodes. o Nodes may join or leave Links. o Links may be joined or split." and what isn't clearly stated is that when a link fails (partially or fully) or comes into existence , is that a topology change? For instance, if a link fails, surely that shouldn't be a topology change for the prefix assignment, but rather a matter for routing to handle. I do see in Sec 4.3 "When a Link is removed, all Assigned Prefixes assigned to that Link MUST be destroyed." Perhaps a link removal isn't considered a topology change in this context because it doesn't cause renumbering?? How is a new Link added to be considered? How does a router know that its end of a link is the same link as on another router? How is a link "removed" versus merely down? An assumption seems to be that the flooding mechanism can work without any prefix numbering. That's fine but would be good to state. I'm a bit twitchy about the bootstrapping.
Updated position based on feedback from Int-Dir review (Suresh Krishnan)... I don't object to the publication of this document, but there are some issues that need to be remedied. 1. Section 5 provides the considerations for selecting prefixes. However, those considerations are incomplete. RFC 7421 provides the analysis for the use of the /64 boundary. The Homenet Architecture (RFC 7368) discusses various Homenet-related issues around not getting sufficient address space to allocate /64 prefixes to links. RFC 6164 discusses the use of 127-bit prefixes on point-to-point links. Why does this section not mention any of these considerations when selecting a prefix? 2. I am raising Alvaro's point about the impact of topology changes to a DISCUSS. I think there needs to be sufficient discussion in the document on the impact of topology changes on the prefix assignment algorithm and the impact of changing prefix assignments on nodes in the network. This ties in to the point raised by Brian Carpenter on the claim in the Introduction that this algorithm can be used in "fully autonomic as well as professionally managed networks". This is especially true when convergence is described as occurring "eventually". 3. I understand that this document became standalone when the HNCP and DNCP documents split. What dependencies/assumptions does this document have on either one of them? There appears to be some assumptions on the Node ID and the flood algorithm. 4. How does the algorithm deal with prefix delegations that have holes (e.g. RFC6603)? This text seems to preclude such delegations. 5. Section 6 discusses Listener nodes. Does there need to be some discussion/warning about links that consist of all Listeners? The link will not get a prefix assigned to it in such a situation. 6. How does this approach deal with asynchronous link state changes?
* ID-nits complains about the malformed 2119 keywords text in the Terminology section. It would be good to use the entire boilerplate for the 2119 keywords. * The terminology section claims that the definitions are ordered to avoid forward reference, but that is not the case. For example, Link refers to Shared Link and Private Link, Delegated Prefix refers to Assigned Prefix, etc. * The definition of Node ID is unclear. What do you mean by "The set of identifiers MUST be strictly and totally ordered". A node id is a single identifier, right?
Tim Chown did the opsdir review. I think some of the criticism is well take and it looks like discussion is ongoing to address it. I think brians discuss and the outstanding comments are sufficient to address it. Tim's review follows Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I believe the draft is ready with minor issues, mainly around presentation and clarity. As one part of the proposed HNCP protocol, having this distributed prefix distribution algorithm documented is a Good Thing. Homenet has considered previous work in this area, e.g.both draft-arkko-homenet-prefix-assignment-04 and draft-baker-homenet-prefix-assignment-01 have been discussed in homenet. While those don’t need to be cited, it’s worth noting that homenet has been seeking a self-configuring prefix distribution mechanism for some time (3-4 years). General comments: The draft very much throws the reader in at the deep end. It would be very useful if a high-level description of the philosophy of the algorithm were included in the introduction, such that those principles are in the reader’s mind when they read through the remainder of the document, including the description of the algorithm. Related, there is very little content in the draft. It does not cite or mention that it is used by HNCP, nor does it cite RFC 7368. There is no text describing (even just briefly) why this approach is favoured, or any rationale why this approach is most favoured for HNCP (or regarding the claimed convergence). If those are documented elsewhere, a link/reference would be useful for the reader. Regarding RFC 7368, the draft could claim compliance with that RFC, in particular Section 3.4.3, given the support for assigned prefix stability described within the draft. Given it is a homenet draft, this would seem appropriate. Because the draft describes an algorithm, rather than a detailed protocol, many parts of the document omit specifics, e.g. the format of a Node ID, or of the flooded messages. If the document aims to provide the means for a developer to build an implementation of HNCP, this could be problematic. Are these formats going to be described elsewhere, or are they already described somewhere? What happens if there are not enough prefixes to assign a prefix to each Link? Is there still convergence? What is the failure mode here? RFC 7368 considers this an ‘error’ mode that needs to be indicated to the user. Or would you state an assumption of enough prefixes? Some brief explicit discussion of this, early in the text, would be useful. At present it’s hinted at at the end of Section 4.2 and end of Section 6. The Terminology section could precede the Introduction for clarity. Specific comments: Page 1: What does “or for other private purposes?” mean in the abstract? Perhaps the abstract can mention that the algorithm can support prefix stability over reboot given the presence of stable storage. What does ‘eventually converges’ mean? Page 2: Line 3 of introduction, ‘prefix’ rather than ‘prefixes’. As a homenet draft, should ‘professionally managed networks’ be mentioned here? Maybe say “as well as other deployment scenarios”? Page 3: How is the flooding mechanism made reliable? Or is that down to the method of implementation? Page 6: Is this really an applicability statement? I think of something more general here, by default, which this isn’t. Terms such as 'non-overlapping’ and ‘disjoint’ are used - perhaps be consistent. Page 7: At the top, perhaps also mention here that in the moment context ULA prefixes might also be configured by this method, alongside globally unique prefixes. As an aside - where a moment has two routers advertising a /48 ULA, can this algorithm be used to pick only one to use, or would it by default create prefix assignments on each Link for each 48? Page 8: The term ‘considered’ is introduced a little abruptly here in the first bullet point of 4.1. Page 9: It may be better for ADOPT_MAX_DELAY and BACKOFF_MAX_DELAY to be explained earlier, rather than forward referenced to Section 7. Page 10: ‘is not valid’ - maybe that should be ‘is not Valid’, matching the upper case used in the terminology section? Page 12: So if the upstream ISP goes away, what happens? Do all Links become unnumbered for global prefixes, continuing to use ULAs if configured? Some clarity here would be nice. Page 13: For Randomness, is there a privacy aspect here, that a homenet or a network using this algorithm may choose to randomise prefixes internally over time for privacy reasons (ignoring the complexity that may be introduced elsewhere as a result)? We have considered IID and link layer address randomisation elsewhere recently; this could be argued as another tool in that toolbox. Though adding such text with subsequent comments may lead to delays in publication :) Page 16: I don’t think the Node ID assignment mechanism has been described anywhere? The security considerations do not hint at any solution for the noted threats. There are of course comparative threats to similar algorithms. Tim _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
draft-ietf-roll-mpl-parameter-configuration
- I don't get the update model - if all MPL forwarders have to use the same parameters but they don't all do DHCPv6 at the same time, then won't new parameter settings take a while to propagate to most of the network? And won't that cause a problem? Don't you need a "start using this set of parameters in N seconds" field in the dhcp option to handle that? This is not a DISCUSS as I think it relats to Barry's so please try address this when addressing that. - please do not pretend rfc 3315 is a solution for anything unless you mean it and I don't think you do. 3315 is I think the canonical example for mythical security:-(
-- section 2.6, 1st sentence :" A parameter set for an MPL domain SHOULD NOT be updated more often than twice of Information Refresh Time" The preposition "of" is incorrect. Normally I would say leave that for the RFC editor, but it's not clear to me if this means "twice the information refresh time" or "twice during an information refresh time (interval)". (I assume the former, but it could be more clear.)
From the OPS-DIR review done by Menachem: The document is quite readable. Section 2.1 could be improved if for each parameter defined a reference would be given to indicate where the parameter is defined. I found most of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not sure what the Proactive_Forwarding flag is used for. Section 4 discusses Security Considerations but I think that some phrases in the paragraph are too general. Example: "other methods for security should be applied" does not indicate what these methods are or where to look for them. Another Example: "To protect attacks from outside of the network, unneccessary DHCPv6 packets should be filtered on the border router between the ROLL network and the Internet" - what is meant by "unnecessary DHCPv6 packets"? NITS ==== Section 2.3 First Paragraph Second Sentence - Remove 'is' OLD ==> Note that there may be cases in which a node may fail is to join a domain SUGGEST ==> Note that there may be cases in which a node may fail to join a domain Section 2.3 Last Paragraph is not clear. Perhaps the last sentence should read "In this case" (instead of "In the case"). Section 2.6 - First Sentence - Not Clear Is the update rate not to be more than twice the Information Refresh Time? Not clear to me how many updates are allowed in an Information Refresh Time. Should the word 'of' be replaced by 'the'. "more often than twice the Information Refresh Time". Suggest rephrasing this paragraph.
Thank you for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg05835.html I'll follow along with the discussion from Stephen and Barry's comments, but don't have any additional to add.
This should be a very easy discussion to resolve:
-- Section 2.3 --
A node SHOULD leave an MPL domain if it receives an updated MPL
Parameter Configuration Option without a configuration for the MPL
domain, unless it has overriding manual configuration on the MPL
domain. In other words, if a node is configured to work as a MPL
Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY
stay on the MPL domain even if it receives an MPL Parameter
Configuration Option without configuration for the MPL domain.
I'm confused by this, because it appears to contradict itself.
Some questions might help he understand:
If I receive an updated MPL PCO that lacks a config for the MPL domain, then
there are two possible situations:
Case 1: I do *not* have an overriding manual config for the domain. In this
case, the text says that I SHOULD leave the domain. Is that correct? Is it OK
in this case for me to decide to stay on the domain anyway, even if I have no
manual configuration for it?
Case 2: I *do* have an overriding manual config for the domain. In this case,
the text seems to say that it's entirely my choice ("MAY") whether or not I
stay on the domain or leave it. Is that correct?
Please discuss this with me, so I can suggest how to make the text clearer,
depending upon the answers to those questions.
-- Section 2.1 --
option_len: Length of the option. It SHOULD be 16 (without MPL
domain address) or 32 (with MPL domain address).
"SHOULD", really? What else *can* it be, and still be valid? Is there any
legitimate reason I might make it something else? Or should this just say
this?:
NEW?
option_len: Length of the option, which is 16 if no MPL domain
address is present, or 32 if there is an MPL domain address.
END
In general, this draft is well-written and easy to understand. I do have a few
points of technical clarity that I think are important.
First, a minor point on the "Reserved" bits. In Sec 2.1, it says "Z (7 bits):
Reserved. Should be 0." and then in Sec 2.2: " Clients MUST discard the MPL
Parameter Configuration Option if it is invalid (e.g., it sets reserved bits)."
Frequently, Reserved bits are available for future enhancements - so setting
to zero on write and ignoring the value on read is a useful default. If these
bits are really always going to be zero and interpreted as an error, then could
you rename them to MBZ (Must Be Zero) and indicate in the field definition that
a value other than zero is an error. Also, from what I read in the rest of
the draft, if an invalid option is received, that could cause the client to be
removed from the MPL region. Could you clarify in the document what the
expected behavior is if an invalid option is discarded? Is that like having no
option? Is that pretending that the client didn't get one and staying with the
previous option? It seems like it would be pretty easy to remove a client from
the MPL region by flipping a bit. I would also like to see better
clarification of how an option is considered invalid; while it may seem
obvious, it's these details that impact interoperability. In the write-up, I
don't see any indications that there have been interoperable implementations
yet?
Second, given that the meaning of the *_IMAX values is based on RFC6206 (as
indicated in the update history) and that the *_IMAX and *_IMIN are confusing
values, PLEASE have a reference to RFC6206. To continue, it seems that
DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX have different units - as is explained
in RFC6206 where *_IMAX is the number of doublings and *_IMIN is the value in
milliseconds. However, in draft-ietf-roll-trickle-mcast-12, Section 5.4, the
definition of DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX and C_IMIN and C_IMAX are
given as:
" DATA_MESSAGE_IMIN The minimum Trickle timer interval, as defined in
[RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMIN
has a default value of 10 times the expected link-layer latency.
DATA MESSAGE_IMAX The maximum Trickle timer interval, as defined in
[RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMAX
has a default value equal to DATA_MESSAGE_IMIN.
CONTROL_MESSAGE_IMIN The minimum Trickle timer interval, as defined
in [RFC6206], for MPL Control Message transmissions.
CONTROL_MESSAGE_IMIN has a default value of 10 times the worst-
case link-layer latency.
CONTROL_MESSAGE_IMAX The maximum Trickle timer interval, as defined
in [RFC6206], for MPL Control Message transmissions.
CONTROL_MESSAGE_IMAX has a default value of 5 minutes.
"
Clearly, if DATA_MESSAGE_IMIN is a 16 bit value and DATA_MESSAGE_IMAX is only
an 8-bit value, they are expected to have different ranges. Additionally,
it's quite unclear which actually needs to be divided by TUNIT. The draft
describes this as happening for DM_IMIN and C_IMIN, but then goes on to say
" Note that all time values (Trickle timers and expiration periods) are
in TUNIT milliseconds precision. For example, if TUNIT is 20 and the
data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then
DM_IMIN shall be set to 50."
Unfortunately, the draft doesn't describe which parameters are time values and
apparently draft-ietf-roll-trickle-mcast-12 has some confusion as well. For
instance, CONTROL_MESSAGE_IMAX is defined as a time value (5 minutes).
I suspect that the solution here is to clarify/fix
draft-ietf-roll-trickle-mcast-12, add references in Sec 2 to where the
parameters are defined, indicate which are considered "time values", and clean
up the language in Sec 2.1.
Thanks! It looks like a useful document to address an operational problem once
these clarity issues are addressed.
In Sec 2.1, it says: "OPTION_MPL_PARAMETERS: DHCPv6 option identifier (not yet assigned)" Instead of "not yet assigned", it would be better to use TBD1 and then reference TBD1 in the IANA section. That makes it easy and clear how to update the draft as it is prepared to be an RFC.
Some of these points come from Bernie Volz's INT-Dir review... 1. This is one of the few options that is not a singleton, as defined in section 16 of RFC 7227. While the use of multiple options seems appropriate here, it would be best to clarify that clients (section 2.2) and servers (section 2.4) must be able to support multiple instances of this option. Given the discussion around supporting multiple MPL domains in draft-ietf-roll-trickle-mcast, I would expect there to be situations where the option appears multiple times. 2. In section 2.3 (MPL Forwarder Behavior), there should be a brief discussion of the role of the MPL Domain Address and include a reference to [I-D.ietf-roll-trickle-mcast]. 3. In section 2.6 (Operational Considerations), the text is a bit odd. Why should a parameter set not be updated more often than twice the Information Refresh Time? How does the failure to refresh the option play with text in section 2.3 that indicates a missing option means the node should leave the MPL domain? Perhaps defining what "failure to refresh" means (i.e., I think it refers to lack of a DHCPv6 server response to a Renew or Information Request). Note also that Information Refresh Time is only applicable to Information-Request messages (see RFC 4242) so work may be needed as to how this this sections relate to Renew/Rebind operations? I am also not sure why 2.6 is a standalone section when it appears to be only applicable to clients and should be in either section 2.2 or 2.3.
1. I support Barry's DISCUSS on the lack of an option potentially forcing a node to leave an MPL domain. 2. Why is the text in Appendix B not in the Operational Considerations section? 3. Please be consistent with the use of MUSTs and SHALLs. Pick one. 4. In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph - why would a client discard the option if the reserved bits are set? I would think you'd want to use a new option if you're changing things drastically? But it certainly is your choice as to whether you want to do that. Perhaps a better reason is if one of the not-permitted values is used (such as 0 and 'all-bits-set') where are clearly reserved? 0 in many of these case could be bad since that would yield 0 time values? This really is up to you, but do think about what you might want to do any maintain backwards compatibility. Adding a new flag bit to the reserved field is probably not going to break things if existing implementations ignore the bit(s).
draft-ietf-tzdist-service
- 62 pages! urgh;-) But it's actually a pretty good spec, just be nice if it were shorter. - 4.2.1.2 - I don't get why HTTP authentication (401 etc) is being used here. Is it that you want personalisation but you're hacking that via HTTP authentication? I'd argue that not trying for that via the TXT RR scheme would be better, that is, to say that you don't get personalisation when you use a TXT RR to get the path. Or just say the server can try set a cookie if it wants personalisation. I can't see that clients here will sensibly handle HTTP authentication in any case (well, not unless you adopt something like RFC7486:-) - for example, how would a HTTP UA pick a username here? (The same comment applies to all HTTP authentication uses in the draft.) - 4.2.1.3 - maybe useful to point forward to section 8 here and/or say that you can't go from TLS to port 80 via the .well_known 3xx. - 4.2.2.1 - it'd have been nice to indicate the amount of data that'd be downloaded here just so's some developer doesn't make a bad assumption about when it's ok to do this. - section 8, 2ndary-primary MUST use TLS - thanks! And for the SHOULD use for client-server. - section 9: thanks!
Thank you for the privacy considerations.
Thank you for the elaborated security and privacy considerations!
A detail, really. "Discussion of this document has taken place on the tzdist working group mailing list <tzdist@ietf.org>." is this a new practice for WG document?
I support Stephen's comments and do not have any additional ones to add. Thanks for your work on this draft and the security & privacy considerations.
Well-written spec. And some info about defeating traffic analysis, what a novelty!
Qin Wu performed the opsdir review it looks like change have been incorporated into -10
draft-ietf-ipsecme-chacha20-poly1305
intro: "gold standard" is being a bit too keen IMO, I'd say toning the language down a bit would be better. intro: 3DES may be the "only other widely supported" cipher for IPsec, but that's not true more generally. section 2 says: "As the ChaCha20 block function is not applied directly to the plaintext, no padding should be necessary." That "should" could be confusing as written if a reader thinks it means their code doesn't have to do padding. It might be better to e.g. say something like "In theory no padding is needed for this cipher, however, in keeping with..." section 3: Is "SHOULD inlude no padding" really right? I'd have thought a MAY was better there. "MUST accept any length" is also a bit odd - what if I (try:-) add loads of padding? Appendices: thanks for those - I assume someone checked them for you? (I didn't:-)
This is easier than usual to read for this sort of draft :-) -- Section 1, 1st paragraph: I concur with Stephen's comment. Furthermore, this entire paragraph pretty much reads like advertising copy. Can it be toned down a bit? -- 8.1 (Normative References) The reference to [RFC7539] is a normative downref. I don't see it on the downref registry, nor was it mentioned in the last call notice. (For the record, I think it's a reasonable downref.)
Agree with the comments about toning down the language in the first paragraph.
Juergen Schoenwaelder's comment's from the opsdir review were applied in version 11.
draft-ietf-pcp-authentication
Thanks for addressing an aspect of security in relation to PCP, especially the Advanced Threat Model from RFC6887. I have a few comments 1) I'm sure the RFC editor will pick these up, however there is some comma usage in the document that caused me to re-read some of the paragraphs to understand. The Abstract is one example of this. I'm certainly no expert so perhaps have a skim over this: http://www.grammarbook.com/punctuation/commas.asp 2) s 3.1.1, please consider rewording the text "Section 5.1 updates the PCP request message format to have a result code." to something like "Section 5.1 updates the PCP request message format with result codes for the PCP Authentication mechanism" ...The wording as it stands seems a little non-specific. 3) Basic DoS attacks (such as state bloat) are mentioned in the security section, are there any complex DoS attacks that can be leveraged using the PCP authentication mechanism itself?
Thanks for getting this done. - Why didn't you choose to encrypt the PCP payloads after you've got a shared secret? If the answer here is "oops, we never thought about that," then this will likely turn into a DISCUSS, but I expect the WG did think about it, in which case I reckon my preference for confidentiality doesn't trump the WG consensus. - How would this work in a home network where the f/w is not managed by the ISP and there'd otherwise be no EAP infrastructure? That could be out-of-scope or require some new/odd EAP implementation and no change to this protocol, and that is probably fine, but I do wonder. - 3.3: Is this really needed? I wonder if we could do without it. The protocol would be simpler if this wasn't needed and simpler == more-secure in general. - 5.11: would s/issued the credentials/issued the EAP credentials that will be used to authenticate the client/ be better? As-is, it's a tiny bit confusing maybe. - 6.2: Maybe this is being overly paranoid, but would it be worth saying that in all failure cases when you say discard the message, you mean to not process it's content? With a very perverse reading of the current text, I might be able to argue that I could process the message content first and only then check the authentication afterwards. Yes, that'd be fairly spectacularly dim, but that kind of thing does sometimes happen. (If there's a better place in the draft to put some text on that, that's just fine.)
Thanks for addressing Jouni's OPS DIR review.
draft-ietf-pcp-proxy
I have one thing I'd like to check. Maybe this just works fine, but how does this function work with PCP authentication? E.g. in Figure 1, is the left-most client authenticating to the middle or rightmost server? I think I could imagine either answer being desirable and don't see a way that both could be supported.
I have these comments and questions: 1) There is no clear definition of what a PCP proxy really is. Section 1. shows it as a pure signalling entity only w/o any NAT functionality (no mapping functionality) but the document body itself talks about PCP proxies having a mapping table (and also the possibility of not -- Section 3.4.1). Adding such a statement about the PCP proxy is or can be to the intro or the terminology section is a good thing. 2) Section 3.1 talks about hairpinning: There is a potential noteable issue in terms of network management: If the PCP proxy is performing the hair pinning for the Assigned External Address, the byte counters on the PCP server and the proxy will differ for the Assigned External Address. This might be worth to note in a network managment section (or elsewhere in the document).
This should be an easy Discuss to resolve.
I was surprised to see
In addition, this goes against the spirit of NAT gateways. The main
purpose of a NAT gateway is to make multiple downstream client
devices making outgoing TCP connections to appear, from the point of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
view of everything upstream of the NAT gateway, to be a single client
device making outgoing TCP connections. In the same spirit, it makes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sense for a PCP-capable NAT gateway to make multiple downstream
client devices requesting port mappings to appear, from the point of
view of everything upstream of the NAT gateway, to be a single client
device requesting port mappings.
limited to TCP connections. Is this intentional?
https://tools.ietf.org/html/rfc6887#section-2.2 certainly lists other transport
protocols.
Is it correct to say
In addition, this goes against the spirit of NAT gateways. The main
purpose of a NAT gateway is to make multiple downstream client
devices to appear, from the point of
view of everything upstream of the NAT gateway, to be a single client
device.
?
Please note that I'm not objecting to the focus on TCP in this text:
Where this document uses the terms "upstream" and "downstream", the
term "upstream" refers to the direction outbound packets travel
towards the public Internet, and the term "downstream" refers to the
direction inbound packets travel from the public Internet towards
client systems. Typically when a home user views a web site, their
computer sends an outbound TCP SYN packet upstream towards the public
Internet, and an inbound downstream TCP SYN ACK reply comes back from
the public Internet.
I share Stephen's curiosity in his Discuss, but I'll follow along there (I saw Med responded 15 minutes ago).
draft-ietf-avtext-rtp-grouping-taxonomy
A comprehensive document, and only a small comment that should be easy to clarify if I have misinterpreted. --- 4.14. SSRC --- It might be my stylistic approach, but I prefer the more complete definition from RFC3550 (Section 3:) that starts with: "Synchronization source (SSRC): ..." I understand that the document is long, but do consider that if a reader finds this tome the words provided in 4.14 don't seem to fix the opacity problem the draft is addressing.
While I won't stand in the way of publishing this document, I think that it may be better suited to live on in a Wiki where it can be updated in a more fluent fashion. I didn't get a particularly warm fuzzy feeling from phrases like these: "This document provides *some* clarity..." or "For each concept *an attempt is made*...". That text can be made firmer, but the point remains: it is probable that the concepts could be refined and the taxonomy may evolve.
A few editorial comments: -- section 1: "in Real-Time Transport Protocol" in _the_ Real-Time Transport Protocol... "... has previously often been" has previously been -- 4.1 and children: It's confusing figuring out which section references are to CLUE vs to other sections in this document.
Thanks for this document. I particularly like the figures 1, 2 and 7, as entry points in the document. For completeness, you might consider: - adding a few words about the boundary between analog and digital (in the Physical Stimulus, I guess) - inserting in figure 7 that a RTP session "is a group communications channel which can potentially carry a number of RTP Streams"
Wow, I wish we'd had this document when RTCWeb and CLUE were starting in parallel! Thank you all for producing it. Jitter is called out separately from delay in 2.1.16, but not in 2.1.18, 2.1.23, or 2.1.24. Was that intentional? 2.1.16 also calls out inter packet spacings separately. I'm not sure if that's also relevant in 2.1.18, 2.1.23, or 2.1.24, but wanted to ask.
Thanks for all your work on this. Caught some nits below. = Sec 2.1.3 = s/The time progressing stream/A Raw Stream is the time progressing stream/ = Sec 2.1.5 = s/A stream of digital samples/A Source Stream is a stream of digital samples/ = Sec 2.1.6 = s/Such Media Encoder produce/Such Media Encoders produce/ = Sec 2.1.9 = s/and put their content/and putting their content/ = Sec 2.1.10 = s/A stream of RTP packets/An RTP Stream is a stream of RTP packets/ = Sec 2.1.12 = s/A RTP Stream (Section 2.1.10) that contains/A Redundancy RTP Stream is an RTP Stream (Section 2.1.10) that contains/ = Sec 2.1.19 = s/The RTP Stream that is emitted/The Transported RTP Stream is the RTP Stream that is emitted/ = Sec 2.1.20 = s/The receiver Endpoint's (Section 2.2.1) transformation/The Media Transport Receiver is the receiver Endpoint's (Section 2.2.1) transformation/ = Sec 2.1.23 = s/The RTP Stream (Section 2.1.10) resulting/The Received RTP Stream is the RTP Stream (Section 2.1.10) resulting/ = Sec 2.1.24 = s/The Redundancy RTP Stream (Section 2.1.12) resulting/The Received Redundancy RTP Stream is the Redundancy RTP Stream (Section 2.1.12) resulting/ = Sec 2.1.26 = s/A Received RTP Stream (Section 2.1.23) for which/A Repaired RTP Stream is a Received RTP Stream (Section 2.1.23) for which/ = Sec 2.1.28 = s/The received version of/The Received Encoded Stream is the received version of/ = Sec 2.1.30 = s/The received version of a Source Stream/The Received Source Stream is the received version of a Source Stream/ = Sec 3.1.32 = s/The received version of a Raw Stream/The Received Raw Stream is the received version of a Raw Stream/ = Sec 2.2.1 = s/A single addressable entity/An Endpoint is a single addressable entity/
draft-ietf-dnsop-negative-trust-anchors
Thank you for a well written document. Many more thanks for using github and making commit comment changes there!!
In an ideal world, my YES ballot for would really be "YES,
sadly I suppose we need this kind of thing but wouldn't life be
much better if DNSSEC was much easier to deploy, ah well, too
late now I guess:-("
- section 1.1: Where is the definition? I see you telling me
what an NTA isn't, but not what it is. I think what you want to
say is that an NTA is a domain name or a pair (a domain name
and a sub-domain of that) represented in a resolver
implementation-specific manner so that DNSSEC validation is
turned off from the higher domain name down (to the subdomain
if we have a pair). Is that right?
- 1.1: RFC5914 is a little misleading as a reference as that
was done for X.509 stuff and is nothing to do with DNSSEC.
Maybe it'd be worth pointing that out just in case some reader
somewhere goes and gets confused.
- section 2: what do you mean happens "once per quarter"?
- section 2: "immediately restores" - well that depends on the
screw-up doesn't it? Or are you saying (where?) that an NTA
must only be put in place when the screw-up is specifically and
only about and because of DNSSEC and where ignoring DNSSEC will
result in things "working"? For example, DNSSEC could fail
because all my nameservers are entirely offline due to a f/w
mis-configuration that blocks loads of port 53, but putting in
place an NTA won't help then. (As it happens, I'm right now
gettting a f/w to re-unblock 53 so I can serve some DNSSEC
records so this issue is one that's close to the bone for me:-)
- Section 6: 1st 2 sentences repeat repeat dnssec-failed.org
too too many times.
- random question: why not have an "I'm just testing" RR that I
could put in alongside my ZSK DNSKEY as I start to play with
DNSSEC? Or maybe that exists already.
-- General: This is just an observation, since this is informational draft. I do not expect or suggest any action on it. (But if it had been standards or BCP track, I might have made it a discuss.) If I understand this correctly, it suggests that resolvers be configured to stop validating known broken names. This of course has the risk of circumventing the protection that a domain intended by using DNSSEC in the first place. The draft does discuss those risks. But I would have been happier to have seen something with a tone more along "We know you are going to do this thing, and it's probably better than globally switching to a non-validating resolver-- so here's the risks, and here's some ways to minimize those risks" (which I think might have been good BCP material) rather than "This is a good practice to work around broken DNSSEC configurations." -- section 1.2, last paragraph, last sentence: Out of curiosity, has this been an issue? -- 2, 2nd paragraph: Can an operator be reasonably expected to be able to confirm that a domain is being operated by its rightful owner? -- 2, 2nd to last paragraph: Since the requirement to limit the time an NTA is used is a MUST, it seems like the ability to configure that time should also be a MUST. -- 2, last paragraph: Why is the requirement not to affect another branch weaker than the requirement not to affect other names higher up the same branch? -- 4, first paragraph, last sentence: This seems to favor erring on the side of keeping the NTA. I think security would suggest erring on the side of removing the NTA. Editorial and Nits: -- If you plan to use capitalized 2119 terms, please add the appropriate boilerplate and a 2119 reference. -- section 4, first paragraph: "It is therefore RECOMMENDED that NTA implementors SHOULD" redundant 2119 keywords (RECOMMENDED and SHOULD ) -- 7, paragraph 4, last sentence: I suggest adding “At the time of this writing…”, and add additional text to remind people these may change over time. -- 7: This section jumps into 2nd person. I don’t want to stand on formality, but it would be good to keep a consistent tone across the draft.
= Sec 2 = "Technical personnel trained in the operation of DNS servers MUST confirm that a failure is due to misconfiguration" s/MUST/must/ - seems odd to put a normative requirement on people to do something in people land = Sec 4 = "The lifetime MUST NOT exceed a week. " Would be good to provide the motivation for where this number comes from.
draft-ietf-appsawg-text-markdown
- 1.1: Who says that there's only a 1-dimensional continuum:-) And what's on the other end? You don't say. - The 2119 terms in the para after Figure 1 are bogus, except for the last SHOULD (on p5).
1.2, last paragraph: Is this document attempting to place normative requirements on existing markdown implementations? Or should the 2119 keywords in this section be more statements of fact (and use descriptive language?) 6.1.2, first paragraph, last sentence: Does this refer to section 6.1.2, or 6.1 and children? If the latter, and if there is no expert reviewer, who is expected to perform those checks (automatically or otherwise?) Editorial: IDNits reports a few missing or unused references, please check. There is at least one occurrence of a word inclosed in slashes like /so/. I assume that's intended for emphasis--but whether it's for that or some other reason it would be good to explicitly mention it. section 1.1, last paragraph: Does "author's intent" refer to the author of this draft, or of markdown? Figure 1: The continuation characters and some markup, impinge on the border.
This is a small issue but there's something wrong with the references. Noted in Suresh Krishnan's Gen-ART review. Please look at this, so that we are not missing something important: - RFC 2046 and 2183 are referenced in the text but not defined as references. Please add them as either normative or informative references. - RFC5322 is never referenced in the text. Is some intended text missing?
1. From Nevil's OPS DIR feedback: > 2. The markdown Example (Section 5) is helpful, but it doesn't seem > to have an obvious end marker - it just runs on into section 6. > Does markdown have something like an end-of-file marker you could > use to make that obvious? And answered by Alexey: > > Not really, it is a textual format with no special end marker. > > I suppose the whole example can be surrounded by some markers and a note added that they are not a part of the example? could we use the <CODE BEGINS> and <CODE ENDS>? 2. "A companion document [MDMTUSES] provides additional Markdown background and philosophy." There is more than that. See the draft-ietf-appsawg-text-markdown-use-cases abstract: "Background information, local storage strategies, and additional syntax registrations are supplied" 3. Editorial OLD: [fOo] NEW: [foo]
Cleared DISCUSS based on WG decision to separate.
I'm not making this a DISCUSS because I think I've raised a similar issue before (with this same AD and doc shepherd, no less, I think) and lost the argument, but I don't get why this document is informational. It specifies a parameter syntax for fragment identifiers. If one implementation follows the syntax specified here and another implementation uses some other syntax defined somewhere else, how is this spec helping the two implementations interoperate?
Nevil Brownlee performed the opsdir review.
draft-ietf-appsawg-text-markdown-use-cases
This does not strike me as a 'use cases' document when you make IANA requests to register identifiers with IANA. These seem more appropriate in draft-ietf-appsawg-text-markdown-08.
(Sorry I included this in my comments for the other markdown doc but it relates to this one. I'll take this out of my ballot comment for that but not re-tx the mail.) - Please respond to the secdir review [1] which raised a couple of questions that deserve answers. (Apologies if I missed your answer to that.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05830.html
I agree with others that mixing the IANA Registrations in the use cases draft is odd -- specially when the draft-ietf-appsawg-text-markdown document also exists. Without the IANA Considerations I would also think that use cases would be better off in a Wiki. [No need to reply to this, as it has been talked about elsewhere..] I do have one nit: Section 2 reads: " [MDMTREG] (draft-05) only defines two parameters: the charset parameter (required for all text/* media types) and the variant parameter." I think that is still true in the latest version of that draft; the "draft-05" reference should be taken out.
Like others have commented, I find it a bit odd to mix the IANA registrations with the rest of the material in this draft. Some of the editorial comments (from myself below, from others, and from IDNits) makes me wonder if this draft was quite finished? While I don't think it makes sense to change course this late in the process for this draft, I am skeptical that the material in sections 1 and 2 will benefit from being in an RFC. I think that it might have made more sense to capture it in a working group wiki, or similar repository. (But again, no point in changing now.) -- 3.3, additional parameters: I’m not sure I understand why the list is broken in to “stuff to turn off” and “new stuff”. Editorial: IDNits has quite a bit to say, some of which might even be relevant. Please check. There are a number of words enclosed in /slashes/ or *asterisks*. I assume this is intended for emphasis. (Or perhaps as performance art when discussing methods for formatting text :-) ) But it seems odd for an RFC. If it stays, I suggest picking one method and sticking with it. (If it means something different, please mention that in the text.) -- section 4 refers to Appendix C, but the draft has no appendices.
Thanks for writing this document. This is a really small thing, but the Gen-ART reviewer (Tom Taylor) noted a couple of things. The one that I would raise as a discuss so that we do not forget to fix is first: Section 4.2: ~~Oops this is some mistaken text.~~ Please make sure your text is complete here. It was unclear if this was intended as actual example text, or if there was a problem in the draft on this point. And, please remove or specify the "[CITE]" references. These are indeed minor things and I'm only raising them (as an easily clearable) Discuss because with them, the draft seems incomplete, and I worry that we have forgotten something.
I agree with Benoit Claise's discuss.
Easy to fix DISCUSS: The RFC 2119 boilerplate is missing:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
- I was surprised by the RFC2119 keywords in a use cases document (which I first thought of as an applicability document") But, actually, according to the abstract, it's way more than a use cases document: "Background information, local storage strategies, and additional syntax registrations are supplied.", It's really the companion document of draft-ietf-appsawg-text-markdown. Maybe the title is wrong, and should be something such as text/markdown strategies and registrations? " [MDMTREG] (draft-05) only defines two parameters:" I guess there is nothing special about version 5. The latest version is v8 Editorial: - section 1, para 4. That confused me until I saw figure 1 OLD: On the formal end of the spectrum is markup NEW: On the formal end of the formatted text spectrum is markup - There are a couple of [CITE] reference, including this one: Character set interoperability is well-studied territory [NB: CITE?] To be completed I guess.
Dan Romascanu performed the opsdir review. benoit's discuss should be addressed.
draft-ietf-karp-isis-analysis
I saw "KARP Design Guide" in the abstract and I had not idea what it was: it is not explained in the document. Not even in the acronym section. After some (very quick and easy, I admit) research, I propose OLD: This document analyzes the current state of Intermediate system to Intermediate system (IS-IS) protocol according to the requirements set forth in [RFC6518] for both manual and auto key management protocols. NEW: This document analyzes the current state of Intermediate system to Intermediate system (IS-IS) protocol according to the requirements set forth in Keying and Authentication for Routing Protocols (KARP) Design Guidelines [RFC6518] for both manual and auto key management protocols.
conflict-review-wierenga-ietf-eduroam
conflict-review-saintandre-jabber-scribe
For the IESG - the "why isn't this a wiki?" question comes up often enough with documents like this one and https://datatracker.ietf.org/doc/draft-secretaries-good-practices/ that perhaps we should create a process guidance wiki. How long would that take? If we wanted to do something about this, perhaps asking Nevil to check at publication time whether we've created a wiki and inserting a pointer to it would make sense? I agree with publishing this draft as an RFC, because that's what we've got for now, I'm just suggesting that we make it easy for the community to maintain the text on an ongoing basis.
I'm not objecting but it is weird to have IETF process oriented stuff (even if only advisory) handled via the ISE. For me, that should only be done in cases where the text is something on which we can't get IETF consensus (e.g. when the text says the IESG are a**holes:-). If the text is something where we really should be able to get it done in the IETF stream, then I think we ought do that. I'd encourage everyone to think about whether this'd be better as an IETF consensus RFC or else, as others have suggested, only as a wiki. But I'm not gonna try block it on that basis.
While I agree a wiki would be nice, I do agree with Peter's point that our current setup doesn't make use of wiki's easy as the content can be difficult to locate. It is easier to just refer people to RFCxxxx right now. If we could improve the tools, then a wiki might be a great option.
While I see no conflict with IETF work here, I also think this would be better published as a wiki page (perhaps on the working group chairs' wiki) than as an RFC. Perhaps we should have an easily found and well publicised ietf-wide wiki for these sorts of things.
Agree with Barry.
conflict-review-irtf-cfrg-dragonfly