IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-10-22. 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:
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:
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
3.4.2 Returning items
3.4.3 For action
Telechat:
1036 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Working Group News
Amy: room numbers for Yokohama
1049 EDT Adjourned
(at 2015-10-22 06:00:03 PDT)
draft-ietf-homenet-dncp
Thanks for talking through my Discuss, which was This should be an easy Discuss to ... discuss ... I'm looking at this text: If keep-alives specified in Section 6.1 are NOT sent by the peer (either the DNCP profile does not specify the use of keep-alives or the particular peer chooses not to send keep-alives), some other existing local transport-specific means (such as Ethernet carrier- detection or TCP keep-alive) MUST be used to ensure its presence. and wondering if using TCP keep-alive for liveness detection is realistic in the use cases this specification is expecting to address. Unless I missed something, the default TCP keep-alive interval is still two hours (that's been true since RFC 1122, and also true in the relatively recent version of Linux I'm using). If that's OK, I'll clear. If you're assuming a keep-alive interval that's shorter, lots of implementations allow you to tune this, but it seems like the specification should say something about that. Given that the other example of "transport-specific means" is Ethernet carrier-detection, which would be orders of magnitude faster, I thought I should ask.
Just to note version -10 took some of my comments below into account. I didn't check in full detail, my comments being non blocking. - 8.3 generally: I think this could be the basis for something quite good but that'll only become clear really (to me) when I go over it in a real protocol and not in the abstract. I'd also speculate that you might end up changing this if it gets more security review, but again that's hard to get in the abstract. Basically: be prepared for changes as this is made concrete and if that would be a problem please yell now. If you do yell, I'm fine with making this a DISCUSS so we're sure to resolve it. (I nearly did make this a DISCUSS, as I'm not sure this is all fully worked out, but I'm ok that we can fix that later. And you have enough DISCUSS ballots;-) - The write up notes various drafts were input to what became this one. I assume that none of those had associated IPR that hasn't trickled through to being noted as applying to this one? If not, as I expect, that's fine, no response is needed, I'm just noting this since I didn't see any "replaced by" entries in the history and it's those that cause IPR to be transitively visible. - section 2 - it's not clear to me why all node identifiers need to be the same length - some protocols using DNCP could I guess have variable length identifiers. IPv4 and IPv6 and Ethernet for example all have different lengths. - 4.2: seems to contradict itself. 1st para says that MC is not used for anything sensitive, but 2nd-last para of section says that network state TLVs can be sent "now and then." (Reason to ask is that (D)TLS won't work if sensitive data is sent via MC.) - 4.4, 2nd para: what is a "valid" address? - 8.1: do you mean one PSK per network or per pair of nodes? Better to say. I assume it's the former. - 8.3: This is an example of (a fairly complex) use of opportunistic security (RFC7435). Be good to note that. - 8.3: Calling this "certificate based" is I think a misnomer. I suspect all the same things could be done with raw public keys (RFC 7250). - 8.3: please do note that a concrete protocol might need changes to this distributed algorithm and that this section is guidance and not to be considered entirely fixed (when coding).
For -10, I just have a couple of nits from my comments related to -09. In the Introduction s/currently or recently bidirectionally reachable/currently bidirectionally reachable In Section 2. (Terminology) the definition of bidirectionally reachable still uses “recent” in the definition. Given the text in Section 4.5. (Adding and Removing Peers) I suggest simply to s/if a recent and consistent multicast/if consistent multicast
Update: The new version made some changes to appendix B, but at least for the transport security section, it's not clear to me if this means the _section_ is optional or that _transport_security_ is optional. If the former, then I'm concerned people may take that as a license not to think about transport security requirements. Would it make sense to make the section required, even if took the form of "This profile does not require transport security because of <reasons>"? Previous comment: Thanks for the new appendix B. How should we interpret the "(optional)" tag on some of the sections of that appendix? For example, does for the Transport Security section, does (optional) mean the section is optional, that transport security is optional, or both?
I am abstaining, as this draft is not specifying a full protocol but just giving an abstract protocol (i.e., a hull only). I would ballot with no-objection if the designated status of this draft would be 'Informational', but given that it is 'Proposed Standard' I do not see that RFC 2026, Section 3.1 and 3.2 are covered. It is neither a Technical Specification nor an Applicability Statement. However, I will not stand in the way of the publication of the document.
Other ADs focused on the protocol specific points. So let me focus on something else. The applicability section doesn't answer my questions: when to (re-)use this protocol? Note that the write-up mentioned ANIMA. I see the protocol description: DNCP is designed to provide a way for each participating node to publish a set of TLV (Type-Length-Value) tuples, and to provide a shared and common view about the data published by every currently or recently bidirectionally reachable DNCP node in a network. However, this applicability section doesn't tell me when to re-use DNCP (or define a profile for it). I see an effort to address my discuss in the appendix B of draft version 11. Thanks What would solve my DISCUSS is an applicability section that would contain a high level set of criteria that would briefly explain whether DNCP is applicable for the specifications I have in mind. The first 2 paragraphs of section 1.1 is a good start, then it goes considerations about Trickle, the interval A_NC_I, etc ... and you lose the readers. Something like: DNCP is designed to provide a way for each participating node to publish a set of TLV (Type-Length-Value) tuples, and to provide a shared and common view about the data published by every currently or recently bidirectionally reachable DNCP node in a network. [As an example of what I'm expected, see below. Btw, I have no idea if this text is correct or complete, but that's besides the point] DNCP works with profiles in which you have the flexibility to specify: - the appropriate transport: the available options are TCP and UDP (see section appendix B for the tradeoffs) - the transport security: TLS or DTLS, see appendix B). - If service discovery is required, an optional multicast service can be defined. - TO BE COMPLETED DNCP is applicable to LAN, WAN, or even the Internet. DNCP can exchange enterprise specific TLV or an IANA registry could be specified DNCP specific extensions are possible. TO BE COMPLETED DNCP limitations: - Data published limited to 64kB - Doesn't work for SCTP, DCCP - All devices in the network must be DNCP node? - TO BE COMPLETED To summarize, I need the 2 min elevator pitch of when (not) to use DNCP.
- I would agree with Alvaro, when he wrote: "In general, I found the text not straight forward or easy to understand." Potentially due to the structure. - I hope that a document about manageability considerations (see https://tools.ietf.org/html/rfc5706#appendix-A) will follow.
Thanks for your detailed work on this draft to provide all of the security related options in section 8. Thanks for addressing my prior discuss with a note in section 8 on why TLS/DTLS should be used and the expanded guidance in the appendix for a profile.
In the IANA Considerations, we would normally use a normative reference to RFC 5226 to define the "Standards Action" and "Private Use" policies. I suggest adding that.
Thank you very much for addressing my previous Discuss points and comments. I understand that version -11 will handle the most recent concerns, as shown in the github diff. I've also read this draft too many times at this point to be certain that I've picked up all the points of unclarity. a) As pointed out by Lizhong, it would be very useful to have some text discussing the issues around a network hash collision. I suspect that this is related to guidance for a DNCP profile on how to make a decision about what hash function to use and how many bits to include 6) Please define H(...) in terminology, since Sec 4 uses it before it is defined in Section 7.
After spending a bunch of time reviewing the DISCUSS and COMMENT points made by all the IESG members and having several in-depth discussion with other IETF participants, I am abstaining on this document. I believe the concept of an "abstract protocol specification" does not align with the IETF's goal of generating clear and inter-operable protocol specifications. This approach requires an implementer to resolve differences between the abstract protocol specification and the profile rather than simply implementing a single protocol specification. Such an approach has a higher probability of error than the single specification approach. If the basic premise of a protocol is sound and applicable for other uses, a new protocol specification can be written that borrows the necessary part from the previous protocol and makes any requisite changes for the new use. Given this, I will not support the publication of this draft, but I will not stand in its way given the perceived rough consensus for it.
publication in conjunction with an actual profile would I think have gone a long way towards ameliorating concerns associated with the nature of the document as it is it's incomplete. however it's time to move forward.
draft-ietf-pals-ms-pw-protection
I appreciate all the background given, it makes the text very clear. I have one question: Is it that easy? The substantive part of this document is "the PW status signaling defined in RFC 6478 MUST be used…in place of LDP-based status signaling". Do all the parts of Sections 6 and 7 of RFC 6870 just translate to the alternate signaling? For example (this is the first thing that I found, nothing special about it), 6.2 (RFC6870) says that "a common Group ID in the PWid FEC element or a PW Grouping ID TLV in the Generalized PWid FEC element, as defined in [2], MAY be used to signal PWs in groups in order to minimize the number of LDP status messages that MUST be sent." I found the Status TLV in RFC6478, but not these other ones — I may of course be missing the references.. I have other minor comments: 1. Just a nit.. It's interesting how (in the Introduction) when presenting the optional mechanism the text says that it "MUST be identically provisioned in the PE endpoints". However, then talking about the MTI mechanism (in Section 3. (Operational Considerations)), the text "just" says that "operational care must be taken so that the endpoint T-PEs are identically provisioned". [To be fair, the same "low key" text is later included in the Appendix referring to the optional mechanism.] The text itself is not a big deal to me..it just caught my attention the difference in treatment when for either mechanism to work both endpoints must be provisioned the same say. 2. Section 1. (Introduction) Please expand PSN and put a reference in for "PSN tunnel protection", or at least make it clear that the protection you're referring to is what was described above (at least that's my guess). 3. Section 2: s/in the place of LDP-based/in place of LDP-based
Just total nit-level stuff here: unexpanded abbreviations that should be expanded. Note to responsible AD: "OAM" should certainly be flagged in the RFC Editor's abbreviation list as not requiring expansion, and it's not so flagged. -- Introduction -- PE, MPLS-TP, L2TP -- Section 2 -- CE, AC (in fig 1) -- Appendix A -- SDH, OTN, G-ACh
draft-ietf-pals-mpls-tp-mac-wd
I expect that this is a very simple and quick Discuss to deal with. 1) In Sec 4.1, it first says "The retransmission MUST be ceased anytime when ACK is received or after three retries." which is fine but then - "For instance, 1 second retransmission with three retries in absence of ACK response is suggested in this document. However, incremental backoff with higher number of retries is also feasible and may be worth consideration to address the scale issues. This document does not mandate a strict guideline since there are no interoperability implications." CLEARLY, using MUST is more than a gentle suggestion - but is exactly mandating a strict guideline. Please fix either the MUST or the remaining text.
- The secdir review [1] raised a few points that deserve a response I think, did I miss the response? [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06097.html - Where in the referenced RFCs in the security considerations is the DoS potential of MAC address withdrawal covered?
I have some comments that, while non-blocking, I would like to see addressed before publication. 1. Section 3. (MAC Withdraw OAM Message) I don't understand why "when sequence number wraps, all MAC addresses are flushed". Presumably, the wrap in the sequence number would be the result of a new MAC List TLV, so why would all the addresses be flushed and not just the ones on the list? What am I missing? 2. Section 4.1. (Operation of Sender) "…if a need to send a new MAC withdraw message with updated sequence number arises then retransmission of the older unacknowledged withdraw message MUST be suspended and retransmit time for the new sequence number MUST be initiated." That sounds fine to me, but I have a related question. Should the contents of the withdraw message include both the un-ack'ed list as well as the new addresses? It is not clear from the text above. I ask this in light of the text in Section 3 that reads: "The receipt of same or lower sequence number message is responded with ACK but does not cause removal of MAC addresses." IOW, if the un-ack'ed list is not included in the new message then those addresses may not be withdrawn. 3. Also in 4.1. "The 'R' reset bit is set in the first MAC withdraw…" I'm assuming the Sequence Number with the R-bit set will always be 1, is that true? Does the text mean that there will in fact be a MAC List TLV if the R-bit is set? Later in Section 4.2 it says that a message "…with 'R' bit set…MAC withdraw message processing is performed as described above." All this seems problematic due to the text ("above") that says: "If the sequence number in the received message is smaller than or equal to the value in the register, the MAC TLV(s) is/are not processed." IOW, of the R-bit is set (assuming Sew Number = 1), then the Seq Number will be smaller than whatever was received before and the MAC TLV will not be processed. The logic doesn't seem to work for me.. 4. Security Considerations. I traced all the way back to RFC4385, where it hints at the ability of an attacker to disrupt the PW by misusing the associated channel..but couldn't find an authoritative reference to whether spoofing or changing the messages in flight is an issue. I'm worried about the ability of someone to, for example, inject/modify the MAC List, or simply change the R-bit setting. I may just be paranoid, so please point me in the right direction.
Just a few editorial comments: - Please expand PW, H-VPLS and PBB-VPLS on first mention. (The abbreviation list is helpful, but it's still good to expand them in place on first mention.) - section 1, first paragraph: s/withdrawl/withdrawal - section 3: "A single bit (called A-bit) is set to indicate if a MAC withdraw message is for ACK" I don't understand what this means, and I don't find any further explanation of the A-Bit. Do you mean to say that the MAC withdraw message requires an ACK? Isn't that always true? If the A-bit is already defined elsewhere, a citation would be helpful. - Paragraph starting with "Only half of the sequence number space is used. " It seems odd to find that between the descriptions of the A and R bits. Does it relate to the A-Bit, or does it stand alone? (I gather the latter.) - There's an empty "Informative References" section.
I agree with the Gen-ART review from Ralph Droms; there are points where this document could be clearer. The one case that I felt personally strongly about was the part about what number the sequence numbers must start from. The text makes the reader wonder if one should read it literally, or if the starting number is handled differently. It would be better to be explicit. I have balloted no-obj for this document, but would very much like to see the discussion with Ralph continue and some changes based on the comments adopted.
I also agree with the SecDir review (Stephen already provided a link) and would like to see the security considerations specific to this draft added.
Just total nit-level stuff here, mostly unexpanded abbreviations that should be expanded. Note to responsible AD: While "MAC", by itself, still needs to be expanded (because of multiple possible meanings), "MAC address", as a unit, probably qualifies for flagging in the RFC Editor's abbreviation list as not requiring expansion. -- Abstract -- PW, VPLS, H-VPLS (Because the abstract has to stand alone.) -- Introduction -- PBB. It would also help to have a forward pointer to Section 2, though I honestly don't know how to do that without having it look silly. -- Section 2 -- For MPLS, "Multiprotocol" (one word, no capital "P") is the preferred spelling. For PW, "Pseudowire" (no capital "W") is the preferred spelling. -- Section 3 -- H-VPLS -- Section 4.2 -- A MAC withdraw message with 'R' bit set MUST be processed by resetting the send and receive sequence number first. I suggest making it "the send-and-receive sequence number" (with hyphens), so no one thinks there are two sequence numbers (and gets confused by it not being "numbers").
draft-ietf-pals-redundancy-spe
It is not clear that the solution applies to both static and dynamic MS-PWs. The Introduction talks about reusing the signaling in RFC6870, but it is not until Section 3 when RFC6478 is mentioned that I realized the applicability.
Just some very minor nits: - section 1, 2nd paragraph: s/provide/providing - section 3 and subsections: Several occurrences of "Active Preferential Forwarding status bit" need a leading "the".
From my perspective some of the things that Robert raises in the Gen-ART review are very valid questions. I'm raising one of those items in this Discuss. The particular item that I’m interested in is the text in Section 3.2, which seems like explaining what happens in an example, but it also uses normative language and keywords to say what various entities should do. Yet, the example is just one example. Is there a need to lift the keyword statements out of this paragraph and generalise them to make sure that the specification is about the general case and not about the example? Alternatively, maybe I misunderstood the purpose of the keyword statements.
(I also agree with Robert that the document is fairly hard to read. This isn’t the first document in the IETF to be like that, and I didn’t feel that this issue is discuss-worthy.)
No objection regarding the publication of the document. However, based on Linda Dunbar's OPS DIR review, and the Jimmy's answer, a new revision is needed with the agreed changed (see the OPS DIR list for the details)
Just total nit-level stuff here: unexpanded abbreviations that should be expanded. -- Abstract -- PE, T-PE (Because the abstract has to stand alone.) -- Section 2.1 -- CE -- Section 3.1 -- AC -- Section 4 -- CC, VCCV
Linda Dunbar provided the opsdir review.
draft-ietf-pcp-port-set
- section 4, last sentence: I didn't get why this MUST NOT was needed. I've no clue if it'd be obvious to a PCP implementer or not though. 4.2 does say though, maybe consider moving the note up? - 4.1: size == 0xffff has gotta be operationally dangerous, I'm surprised you don't have a bunch of caveats on it's use. Shouldn't you have at least some guidance in 4.2 for that as well? 6.1 and section 7 cover this though I guess. - 4.2: Is there a possible troublesome case where the client asks for parity and gets that but gets fewer ports than requested? E.g. if client wants 6 with parity and only gets 5, then the client might not be able to use that as it really needs 3 pairs of ports. Did you consider saying that a server has to return an even number of ports if parity is requested? (Or would that make sense?, I'm not sure:-)
I have a few minor comments and a question: - Section 4: How is Port Set Size encoded? (something like unsigned short integer?) Why might the first internal port in a response differ from the requested internal port? Even if the server could not map the entire range, wouldn't the first internal port still be the same? The statement that the internal and external set sizes will always be the same could use some elaboration. I assume this means the set sizes will match after mapping, _not_ that the external set size will always match the _requested_ set size. -4.1: should "port preservation" be "parity preservation"? Also, I assume you use port parity in terms of even/odd parity. It might be useful to state that somewhere. - 4.1: Isn't the statement that PREFER_FAILURE MUST NOT (which is, btw, redundant with the similar statement in section 4) appear a requirement on the client rather than the server? Is there some server action expected in the (invalid) case that it does? (Also, you do not merely "not recommend" PREFER_FAILURE. You forbid it.) Editorial Comments: ================= - 4.3, first sentence: The word "unconditionally" doesn't seem to be needed. That it, it doesn't really change anything. - 6.3, last paragraph: Is _intentional_ overlap okay? - 7, first sentence: There seems to be a missing word in the phrase " In order to prevent a PCP client to control ...". Do you mean "prevent... from controlling"? or "prevent ... from attempting to control"?
Just one question about Port Set Size = 1: In Section 4.1: A PCP client MUST NOT send a PORT_SET option for single-port PCP MAP requests (including creation, renewal, and deletion). ...but earlier, in Section 4: Port Set Size: Number of ports requested. MUST NOT be zero. Should the Port Set Size definition instead say "MUST be greater than 1.", given what 4.1 says? ...and in Section 4.2: o If the Port Set Size is zero, a MALFORMED_OPTION error is returned. What happens if Port Set Size is 1? This seems to answer that: SHOULD map at least one port (which is the same behavior as if Port Set Size is set to 1). ...but how is that allowed, given what Section 4.1 says?
draft-ietf-trill-rfc7180bis
I would like to thank Meral for the extensive and detailed Gen-ART review.
Based on a scan of the changes compared to the obsoleted and updated RFCs in appendix C, I don't see any changes that would impact OPS.
The security considerations text left me wondering what "some" of the changes were as there is only one consideration listed. Are there considerations for this change: Appendix C.2 3. Change for the requirement to use the RPF check in [RFC6325] for multi-destination TRILL Data packets by providing an alternative stronger RPF check. Or for any other changes? Thanks.
draft-ietf-netconf-call-home
I have three points to discuss, I think these may be fairly easy to resolve, or maybe not, but I'd like to chat about 'em. (1) HTTP Auth: is it ok for a client to send it's e.g. basic auth credential to any of the servers that the client can validate? I.e., is an additional level of pinning needed for this? That would be a new form of pinning and is not defined for either TLS or SSH afaik. That could also be done in various ways and I'm not sure if those might have interoperability consequences. Or perhaps if not doing that, this draft should say something about a need for stronger credentials esp. for basic auth. Did the WG consider this? (2) The secdir review [1] calls out issues related to TLS-PSK and (I guess also) bare keys. I think it'd be good to be speific as to wheher or how those are to be supported here. If you are going to say those are supported, then I suspect some additional text is needed. Kent's answer to that (which was "see RFC7589" as I read it) doesn't quite do it here I think. that says that certificates must be supported (which is fine) but doesn't say that TLS-PSK or bare keys can or cannot be supported. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html (3) Consider zmap. When this is deployed, what'll be the effect of surveys that fingerprint all of the devices on the visible Internet who implement this protocol? Did the WG consider that? I'm not sure of the impact, if any, but it could be good if there's a way to help deployments end up less vulnerable to fingerprinting (and the ensuing exposure to unpatched vulns).
- OCSP: any issue there? is it mandatory to use in any case for TLS?
One comment and a question: - 3.1, S1: If the client MAY be configured to listen on a non-standard port, doesn’t that imply that the server MUST be _capable_ of being configured to connect to a non-standard port? - 4: I'm curious why people felt it necessary to reverse the usual TLS or SSH client and server roles. Did the working group consider having the NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the reasons be summarized in a sentence or two?
Three points in decreasing order of importance: 1) Why is this parapraph below (and subsequently the other similar ones) using RFC 2119 language with respect to the port numbers The NETCONF/RESTCONF client listens for TCP connection requests from NETCONF/RESTCONF servers. The client SHOULD listen for connections on the IANA-assigned ports defined in section Section 5, but MAY be configured to use a non-standard port. Using the right port number is not something that influences the interoperability of the protocol per se, but is an operational parameter. Checking other protocol specifications, e.g. HTTP/1.1, there is no RFC 2119 language about the usage of specific port numbers. 2) I am not a fan of having different port numbers to differentiate different vanilla flavors of a protocol. However, I can understand the why this is happening this way. But what is happening if there is X-over-TLS/SSH/foo coming after RESTCONF? Are you again in need of more port numbers? This does not look like a tactical wise and sustainable way. 3) This document will benefit from an overview figure that details who is the server/client on what level for what.
Section 2.1 & 3.1 Why is authentication limited to server-side authentication? It seems that this really should be mutual authentication to ensure the server is also connecting to the correct client and there was no attack prior to the callback. 3.1 S3 - Why is client-side authentication optional? Without this must, there should be a security consideration that the call back could go to a malicious client. The types of authentication matter as well, but that's covered in Stephen's discuss points along with the SecDir review questions on TLS-PSK.
In section 1.3, please add a sentence that points to the threat/security analysis for use of this function with NETCONF and RESTCONF after the last sentence: In such circumstances, allowing the SSH/TLS server to contact the SSH/TLS client would open new vulnerabilities. Any use of call home with SSH/TLS for purposes other than NETCONF or RESTCONF will need a thorough, contextual security analysis.
In Section 2.1, C5: This validation MAY be accomplished by certificate path validation or by comparing the host key or certificate to a previously trusted or "pinned" value. It's a finnicky point, but I think it's an important one: You list two methods for validation: (1) cert path validation, and (2) comparing to a pinned value. Is it (A) acceptable for the validation to be done by other methods as well as those two? Or is it (B) required that one of those two be used, but either is acceptable? If (A), then the text is fine as it is. But if (B), the text as written doesn't require the use of one of the specified methods, because "MAY" is optional. If you mean (B), you should write it as "MUST be accomplished either by [...] or by [...]." Alternatively, you could just add it to the previous sentence, as, '...client MUST validate the server's presented host key or certificate, either using certificate path validation or by comparing the host key or certificate to a previously trusted or "pinned" value.' (That wasn't a DISCUSS point because I think implmentors are likely to get it right anyway. But I do think the text needs to be tightened up in order to make it fully clear.) In Section 2.1, C8, an even more finnicky and not very important point: Once the SSH or TLS connection is established, the NETCONF/ RESTCONF client MUST immediately start using either the NETCONF- client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] protocol. What *else* might the client do, which merits a MUST here? I think all you should say here is, "Once the SSH or TLS connection is established, the NETCONF/RESCONF client starts using either [...the protocols...]." Continuing... Assuming the use of the IANA-assigned ports, the NETCONF-client protocol is started when the connection is accepted on either port PORT-X or PORT-Y and the RESTCONF-client protocol is started when the connection is accepted on port PORT- Z. But no: the (NETCONF/RESCONF)-client protocol is NOT started when the connection is accepted (that was in C2), but when the SSH/TLS connection/session is established. Which you already said in the previous sentence, and C1 already said what ports the client listens on. Why is this sentence even here? Why not just remove it? These same two comments apply to S6 in Section 3.1.
In this text: C1 The NETCONF/RESTCONF client listens for TCP connection requests from NETCONF/RESTCONF servers. The client SHOULD listen for connections on the IANA-assigned ports defined in section Section 5, but MAY be configured to use a non-standard port. are SHOULD/MAY mutually exclusive here, or can you do both? I'd be guessing if I said I knew, from this text. Could you provide "as well as" or "instead of" guidance?
draft-ietf-ippm-type-p-monitor
My apologies for thinking slowly ... but it doesn't look like these questions will be difficult to resolve. I talked with David Black about this draft, and he had questions that I translated into AD-speak as: Reflecting an unknown DSCP value is a MAY. Can reflecting packets using a DSCP value you don't understand be a bad idea? How important is that the DSCP value is NOT 0 (CS0, default forwarding)? If you are reflecting a DSCP value, are you also reflecting the ECN(0) bit unchanged? TWAMP doesn't look congestion-controlled to me (certainly not in the reflected direction - https://tools.ietf.org/html/rfc5357 says the packet is reflected as quickly/immediately as possible in at least three places I can see. What is a typical sending rate for the Session-Sender, and is that likely to cause problems in the reflected direction? His note to me follows: This bullet at the end of 2.2.2 bothers me: o if the negotiated/provisioned DSCP value is not known (e.g. TWAMP Light), the choice of the DSCP is implementation specific. For instance, Session-Reflector MAY copy the DSCP value from the received test packet and set it as DSCP in a reflected packet This is implicitly recommending reflection of the DSCP value, and by omitted implication, reflection of the ECN value. Both of those seem like bad ideas, it would be better to say that in this case the DSCP should be set to 0 (CS0, Default forwarding). I would also say that the ECN field MUST be set to 0 (not-ECT) in the reflected packet, always. I’m a bit concerned about setting ECT(0) or ECT(1) on the forward measurement path, as TWAMP is not congestion-responsive. Is the transmission rate of TWAMP low enough to not cause a problem if CE signals are received and ignored in the ECN field at the Reflector?
Just a couple of nits: In Section 2.2.1., please put a reference to rfc5357 (?) to show where the test packet formats came from and to indicate where the fields are described. Figure 4 doesn't show the S-DSCP-ECN field in it.
Just a few mostly editorial comments: - Abstract: Did you mean OPTIONAL to be capitalized in the abstract? I'm not sure what the purpose of a 2119 keyword would be there. - 1, first paragraph: There are lots of missing articles ("the") in the first paragraph. -1, 2nd paragraph: There's no need to say it's OPTIONAL more than once. - 2.1, 1st paragraph: "DSCP and ECN monitoring flag" and "Mode" each need a leading "the". - 2.2.1: The MUST in the first paragraph is not really needed. The Session-Reflector either supports the extension and does these things, or does not support the extension and does not do these things. - First bullet in list at end of 2.2.1: s/extracts/extract
As mentioned by Al Morton, part of his OPS DIR review: Summary: Almost ready, comments and editorial suggestions follow. The draft header should indicate that this draft updates RFC 5357. Section 2.2.1 Figure 1 has a number of canonical references that should be cited to ensure IPv4 and IPv6 applicability, including RFC 2474, RFC 3168, and other relevant updates (of which there are many). <later> o if the negotiated/provisioned DSCP value is not known (e.g. TWAMP Light), the choice of the DSCP is implementation specific. For instance, Session-Reflector MAY copy the DSCP value from the received test packet and set it as DSCP in a reflected packet. Question: What about the ECN value? From 3168: +-----+-----+ | ECN FIELD | +-----+-----+ ECT CE [Obsolete] RFC 2481 names for the ECN bits. 0 0 Not-ECT 0 1 ECT(1) 1 0 ECT(0) 1 1 CE It makes little sense to copy a "11" == CE into the reflected packet, and it may affect the measured performance if "11" were copied. The draft needs more guidance here (there is a general problem when the negotiated values are "not known"; this does not apply to the Standards Track TWAMP protocol or its extensions). -=-=-=-=-=-=-=-=-=-=-=-=- Editorial comments/suggestions: OLD 2.2. TWAMP-Test Extension Monitoring of DSCP and ECN requires support by the Session-Reflector and changes the format of its test packet format both in unauthenticated, authenticated and encrypted modes. Suggest: Monitoring of DSCP and ECN requires support by the Session-Reflector and changes the test packet format in all the original (unauthenticated, authenticated and encrypted) modes. 2.2.1 OLD o the first six bits of the Differentiated Service field MUST be copied from received Session-Sender test packet into Sender DSCP (S-DSCP) field; o the following two bits of the ECN field MUST be copied from received Session-Sender test packet into Sender ECN (S-ECN) field. Suggest: o the six (least-significant) bits of the Differentiated Service field MUST be copied from received Session-Sender test packet into Sender DSCP (S-DSCP) field; o the two bits of the ECN field MUST be copied from received Session-Sender test packet into Sender ECN (S-ECN) field. because RFC 3168 defines: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DS FIELD, DSCP | ECN FIELD | +-----+-----+-----+-----+-----+-----+-----+-----+ DSCP: differentiated services codepoint ECN: Explicit Congestion Notification Figure 2: The Differentiated Services and ECN Fields in IP. -=-=-=-=-=-=-=- OLD 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-DSCP | S-ECN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Sender DSCP and ECN field format Suggest: The extra "+" within bit positions are distracting, and don't conform to the conventions of these diagrams. Also, there's no "8" when numbering from 0. Some attempt should be made to put Figure 3 on a single page in the final version. There's one line taken up by "+" that is unnecessary in the modified field: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TTL | S-DSCP-ECN | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | >> + + << | MBZ (14 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Since rfc5357 has more discussion on the differences between unauthenticated, authenticated, and encrypted modes, it would be helpful to have a pointer to that specific point in the Security Considerations section.
draft-ietf-lisp-impact
Hi, Thanks for producing this document, and appreciate the honesty contained therein. I have two suggestions. From the introduction "The main goal of LISP is to make the routing infrastructure.." please consider s/is/was/ given the tone of the rest of the document and the discussions underway regarding the WG. Section 2, second paragraph "Provider (interdomain) Aggregatable"; I think "interdomain" is superfluous here. Thanks Terry
The opening of this draft "The Locator/Identifier Separation Protocol (LISP) relies on three principles to improve the scalability properties of Internet routing: address role separation, encapsulation, and mapping. The main goal of LISP is to make the routing infrastructure more scalable by reducing the number of prefixes announced in the Default Free Zone (DFZ)." is targeted at solving the Internet scalability issue for Internet routing. While the document goes into some details about rather large unknowns and issues observed, it does not have any indications or caveats up front that this is still experimental work - certainly as far as solving this Internet-scale problem. At a minimum, I think there need to be clear caveats on the experimental nature, on the aspects still to be understood, and on the complexity and concerns around the operational and security aspects. While LISP is a really neat idea and it's good to see how far work and research on it has progressed, this document reads much more like marketing than something discussing the engineering and operational trade-offs. 1) There is no discussion of what the "mapping system" is and I think that some of the discussion is assuming the use of BGP, but it's a bit hard to tell. At a minimum, it'd be good to clarify whether an Internet-scale deployment must use the same mapping system and what the trade-offs there are. 2) In Sec 4.1, "When there are several RLOCs, the ITR selects the one with the highest priority and sends the encapsulated packet to this RLOC. If several such RLOCs exist, then the traffic is balanced proportionally to their weight among the RLOCs with the lowest priority value." It is unclear whether the "highest priority" means the lowest priority value. Please clarify because it incorrectly sounds like the highest priority RLOC is picked - unless there are multiple in which case load-balancing among the lowest priority value RLOCs is done. 3) Sec 5.1 "Proxies cause what is referred to as path stretch and make troubleshooting harder." This doesn't actually describe what path stretch is in any way. I can guess from the name, but that's not sufficient. 4) In Sec 5.2: "Deployment in the beta network has shown that LISP+ALT ([RFC6836], [CCR13]) was not easy to maintain and control, which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt]" Can you give a reference or indicate what the benefits of DDT are as compared to ALT in this context?
- section 3: "proven by several studies" without references is bad - we don't want blatent assertion in RFCs so please add some references. That could be done via forward pointers to later in the document or just by adding the refs here as well and explaining them more later. Or else delete the sentence as being redundant. - section 3, para starting "Results indicate...": Which results? I can't tell from how it's writen. - section 4: ConteXtream needs a reference as does the tier-1 operator (even if that has to be "private communication"at least I'd know to go ask the authors if I care. - I think you could note that as a map-and-encap scheme LISP also offers the potential for encryption of traffic between xTRs and reference the relevant lisp-crypto draft. That could go where you add a mention of rfc 7258 if you do add that. (In response to I think Spencer's comment.) - As with Kathleen, I think the secdir review deserves a substantive response. Please give it one.
I won't oppose the publication of this document. The document is well-written and clear. However, for my taste, it read too much like a combination of marketing, a white paper I might find on a vendor's site, and an overview (with pointers to interesting research papers). I also thought of the relationship with draft-ietf-lisp-introduction and wondered why some of the information in this document wasn't just included there.. Nothing necessarily wrong with all that, it just leaves me feeling unsatisfied. I don't think there's anything to be done to change that feeling.
It seems odd to me that an "impacts" paper would leave security impacts out of scope. Even with the detailed security considerations in draft-ietf-lisp-threats, it seems like there might be some higher-level observations to make, along the lines of the rest of the draft. Along those lines, if you want to refer to draft-ietf-lisp-threats for security considerations, it needs to be a normative reference.
Hello, There was no follow up or changes (it seems) as a result of the SecDir review. It would be helpful to address the questions on the aim of this draft and how it applies to security for the user and impact of LISP. https://www.ietf.org/mail-archive/web/secdir/current/msg06103.html
"RLOC" is spelled out on second use, but not on first use. "Addresses are semantically separated in two:" was a bit rough for me. Perhaps something like "Addresses have two components with different semantic meanings:"? In this text: Middle boxes/filters: because of encapsulation, the middle boxes may not understand the traffic, which can cause a firewall to drop legitimate packets. In addition, LISP allows triangular or even rectangular routing, so it is difficult to maintain a correct state even if the middle box understands LISP. Finally, filtering may also have problems because they may think only one host is generating the traffic (the ITR), as long as it is not de-encapsulated. To deal with LISP encapsulation, LISP aware firewalls that inspect inner LISP packets are proposed [lispfirewall]. I wonder if we're far enough along with RFC 7258/BCP 188 that we expect middleboxes may not understand traffic, whether it's encapsulated or not, because of encryption. Perhaps that's worth a thought, if not a mention.
draft-ietf-aqm-fq-implementation
Thank you for a clear and well-written draft. I would like to understand the reference of "Weighted Fair Queues" and have that clarified in the draft. It's a technical concern, but I have confidence that the authors and ADs will address it. 1) Sec 2.2.3 refers to "Weighted Fair Queues" as well as "Calendar Queues". Perhaps it is due to a lack in my recent background - but what's described is nothing like Weighted Fair Queuing (https://en.wikipedia.org/wiki/Weighted_fair_queueing). Do you have a reference for "Weighted Fair Queues" or something else in mind??
In this text: Carrying the matter further, a queuing algorithm may also be termed "Work Conserving" or "Non Work Conserving". A "work conserving" algorithm, by definition, is either empty, in which case no attempt is being made to dequeue data from it, or contains something, in which case it continuously tries to empty the queue. did you mean that an *algorithm* is empty or contains something? I don't understand. A work conserving queue, sure.
draft-ietf-aqm-ecn-benefits
- The discard of packets serves as a signal to the end-to-end transport that there may be congestion on the network path being used. Why not? The discard of packets serves as a signal to the end-to-end transport that there is congestion on the network path being used. - Section 3.5. Bleaching and Middlebox Requirements to deploy ECN Sligthly confused by ECT(0) is different the zero codepoint When ECN-capable IP packets, marked as ECT(0) or ECT(1), are remarked to non-ECN-capable (i.e., the ECN field is set to zero codepoint), ... A network device must not change a packet with a CE mark to a zero codepoint, if the network device decides not to forward the packet with the CE-mark, I had to look up https://tools.ietf.org/html/rfc3168 +-----+-----+ | ECN FIELD | +-----+-----+ ECT CE [Obsolete] RFC 2481 names for the ECN bits. 0 0 Not-ECT 0 1 ECT(1) 1 0 ECT(0) 1 1 CE If you had one or two sentences to introduce the codepoints, that would avoid the confusion and would ease the readability. And below is Dan Romascanu's OPS DIR review: The following three comments are editorial in nature, triggered by difficulties in understanding some of the information (otherwise clearly presented): 1. It would be useful to break the definition of ‘ECN-capable’ in two separate definitions for ‘ECN-capable packet’ and ‘ECN-capable network device’. It also would be good to copy or refer the definition of ECN codepoint from RFC 3168. 2. Section 2.5 uses both CE-marking and ECN-marking terms. They are meant to be synonymous, so chosing one of them would make the text more clear 3. Sections 4.3 and 5 uses the following phrase about endpoints – ‘it can … conservatively react to congestion’. Please explain what this means.
In this text: The authors would like to thank the following people for their comments on prior versions of this document: Bob Briscoe, David Collier-Brown, Colin Perkins, Richard Scheffenegger, Dave Taht, Wes Eddy, Fred Baker, Mikael Abrahamsson, Mirja Kuehlewind, John Leslie, and other members of the AQM and TSV Working Groups. At the risk of making the name redundant, the ack probably needs to go to the TSVWG working group.
The document fails to note that devices exist which still are or can be configured to use the tos byte as part of a hash key and therefore may induce extremely odd behavior including reordering or due to hashing to a stateful device, connection resets in the face of ecn capability signaling. While we see these are rare they nevertheless still exist. The canonical example of a network device doing this probably being junos enhanced hash key which still supports this in contemporary code.
draft-ietf-6man-predictable-fragment-id
Is the 2119 reference actually needed? As far as I can tell, the only capitalized 2119 keyword is a MUST that occurs in a quote from another spec.
Thanks for addressing the SecDir review comments. https://www.ietf.org/mail-archive/web/secdir/current/msg06126.html
draft-ietf-ace-usecases
This draft seems especially worth the effort of publishing a use case draft as an RFC. I learned a lot while reviewing it. The security considerations section seemed unusually valuable for a use case draft. Do the title and abstract call enough attention to that? The section title "2.1.1. Bananas for Munich" would also be a great name for a rock band ... :-)
While I'm not ordinarily a big fan of publishing use cases as RFCs, I think this one has value. Otherwise, I have only a few minor comments: -Please expand ACE in the title, abstract, and body. - 2.6.1: Is it reasonable to expect wearable devices to have what sound like multi-user-profile capabilities? - 2.7: An informational reference for stuxnet might be helpful.
"ACE use cases." And ACE stands for :-)
draft-housley-sow-author-statistics
Jari's tools take a stab at gender. Such information ought not be added to the tracker DB, and nor ought heuristics that could allow one to derive the gender from an author's other published information. I think warning about that possibility would be good too even if you don't end up saying to not do stuff like that.
- 3.1, last paragraph: Is there an expectation that the list of such techniques will change over time? - 3.3: I note that the existing pages get my affiliation wrong. They seem to infer affiliation from my email address domain. It might be worth mentioning that any official tool should not do that, lest we have “gmail” as the biggest employer in the IETF.
Data in aggregate can be revealing from a privacy standpoint, but it is all public and already being done today. As such, I have no objections.
-- Section 3.2 -- What does the second paragraph say that isn't in the first? Unless I've missed something, it's just repetition. Was that a paste-o?
conflict-review-vinapamula-flow-ha