IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-01-07. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
2. Protocol actions
2.1 WG submissions
2.1.1 New items
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
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
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
1051 EST no break
1100 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Working Group News
1118 EST Adjourned
(at 2016-01-07 06:00:07 PST)
Hi just a couple of comments: - 18.104.22.168: rp_name is labeled "human readable". Are there internationalization considerations? -5: It would be nice to see the IANA request details in this draft
Thanks for clearing up the sentences discussed in the SecDir review in your next version: https://www.ietf.org/mail-archive/web/secdir/current/msg06302.html
I have the same question as Ben does about rp_name: nothing is said about it other than "human readable". Can we have a brief discussion about this?
victor kuarsingh performed to opsdir review resulting in v15, no objections.
Please take the comments below with a pinch of salt - I'm not sure I understood what this was specifying so I may be off base below. (Mind you, this caveat is also a comment of sorts;-) abstract: "RP" could be interpreted as reverse path or rendezvous point, suggest expanding this in the abstract. section 7: I don't understand: "A router processing 'Explicit' or 'Loose' RPF Vectors MUST verify that the order in which RPF Vectors types appear in the PIM Join Attribute list received from its downstream PIM neighbors are equal." Seems like a bad plan to have a MUST in such a hard to grok sentence. Or is that just me? (Actually, that entire paragraph is hard to get.) - section 12: couldn't this allow one node to try DoS another by including it in the vector? Isn't that worth noting? - please also respond the secdir review  which raised a couple more points.  https://www.ietf.org/mail-archive/web/secdir/current/msg06295.html
I agree with Alissa's and Brian's comments
I may have missed it, but don't see a response to the SecDir review. In particular, the last question would be good to see answered/elaborated on in the security considerations section. https://www.ietf.org/mail-archive/web/secdir/current/msg06295.html "Also, the security consideration section in ietf-pim-rfc4601bis document discusses the impact of a forget Join message and its implication on the multicast traffic. You might want to add some text to explain if this new attribute, defined in this document, changes the implication of a forged Join message or not; if it does, you might want to explain how."
I agree with Brian's comment about clear applicability and with Alissa's comments on the "we" language.
I support the publication of this document, but I do have two points I would like you to consider... 1. The use of 2119 keywords in the Introduction are inappropriate. They can easily be changed to non-normative words and the meaning will not be lost. 2. While this approach is viable, and needed, in a subset of deployment scenarios, it is also inappropriate for other scenarios. I think some guidance on when to use, or not use, this option would be useful as an addendum to the motivation provided in section 3.
I find the use of the word "we" in this document to be confusing. Sometimes it seems to refer to the authors or the WG ("we're defining a new attribute") and sometimes to implementations ("we use the RPF Vector stack"). Particularly problematic is the use of a normative requirement on an ambiguous "we" (Section 1): "For these vectors we MUST NOT do a unicast route lookup." I would suggest replacing every instance of "we" with the appropriate subject, e.g., "the router" or "this document," or leaving the subject out altogether.
The introduction uses a MUST for the receiver to use the URO, but the later text uses SHOULD. Could you please clarify and make them the same?
There were changes that seem to have been agreed as as result of the secdir review.  Some of those could I think nearly but not quite be discuss level, but as they aren't and the discussion seems to have started, I'll ballot no-objection but I do hope that the promised changes get made, and I'd recommend cycling back to the secdir reviewer (Sandy Murphy) as it wasn't clear to me that the discussion reached closure just before the holidays.  https://www.ietf.org/mail-archive/web/secdir/current/msg06296.html - Could this be used as a way to nicely disguise a DoS? I'm not sure if that's new to this or not though. - Thanks for the applicability statement in the security considerations. Makes me wonder about MPLS/UDP but sure. - Saving a single bit to distinguish address families via length seems unwise here, as everywhere.
The text related to when the URO is used of not clear, and I think it could even result in technical incompatibility. I don't think that this main concern raises to the level of a DISCUSS since it should be resolved easily (but it might be close). In short, it is not completely clear when the URO should be considered in light of the rules in RFC6374; it is not completely clear if the rules in RFC6374 always take precedence. Here are the specifics of my concern: Section 4.2. (Receiving an MPLS PM Query Request) says that "in addition" to the processing in RFC6374, "with a URO present, then the responder SHOULD use that IP address and UDP port to send MPLS-PLDM response back to querier." RFC6374 says that the "Source Address of a query message SHOULD be used as the destination for an out-of-band response unless some other out-of-band response mechanism has been configured, and unless a Return Address object is present, in which case the Return Address specifies the target of the response." Several questions/observations: * What does the phrase "in addition" mean in 4.2? I'm interpreting it as adding rules to what RFC6374 says. IOW, this document seems to be updating what RFC6374 says (or at least adding extra rules if the URO is present). Is that the intent? * As far as I can tell, there is no restriction for having both a Return Address object and the URO in the same query, right? If so, and if the intent is *not* to update RFC6374, then it seems (from the text in RFC6374) that the URO would never be used (if a Return Address object is also present). * Nitpicking a little at the meaning/interpretation of "configuration". RFC6374 mentions (from above) "some other out-of-band response mechanism has been configured", but as you imply in (i.e as I interpret) Section 5. (Manageability Considerations) the mechanism in this document is signaling, not configuration: "Nothing in this document precludes the use of a configured UDP/IP return path in a deployment in which configuration is preferred to signalling." Yes, you could configure the system to prefer the URO signaling.. * The point with all this is that it is not clear what exactly is meant, and that the current text can result in more than one (defensible) interpretation. * Small nit from the text quoted above in section 4.2: the response may in fact not go back to the querier. I have a couple of other minor comments: 1. Section 3. (Solution Overview) says (in the first sentence) that if the URO "is present in a MPLS-PLDM Query, the responder MUST use the IP address and UDP port in the URO to reply back to the querier". Clearly related to the comments above, but also an incomplete statement: as explained in 4 and 4.1, the Control Code should also be set to "Out-of-band Response Requested". Comments/questions: * [Nit] I don't think there's anything explicitly wrong with that first sentence, but it just doesn't sound right because of the conditional MUST ("unless configured otherwise"). You might want to consider something like this instead: "This document specifies that if the Control Code of the MPLS-PLDM query is set to "Out-of-band Response Requested", and a UDP Return Object (URO) is present in a MPLS-PLDM Query, the responder SHOULD use the IP address and UDP port in the URO to reply back to the querier." * What happens the URO is received in a query that doesn't have the correct Control Code? 2. Section 3.1. (UDP Return Object) * What happens if the URO contains an address not supported by the receiver? * "The URO MUST NOT appear in a response." What should the receiver do if it does? Should it ignore the URO or the whole datagram? 3. s/MPLS-PM (and MPLS PM)/MPLS-PLDM
I am in favour of publishing this document, but I have two major points that are not addressed in the document by now: 1) It is not clear for anybody what the expected size and sending frequency of such MPLS-PLDM over IP/UDP responses are. This will influence any measures an operator has to take in order to assure that there is no congestion caused by these messages. I can understand that this cannot be foreseen, but a few words considering this fact are excellent to have in the document. 2) This leads to my second point: the lack of any reference to RFC 5405 "Unicast UDP Usage Guidelines for Application Designers" and the content out of this RFC that is applicable for this draft. There is no discussion about this at all. Please note well that this is BCP 145. With regard to point 2): I can try to find some help from the transport area, in case you need help.
And we're now redoing the OWAMP/TWAMP protocols ... This is kind of sad that there is no alignment. At the very minimum, in the terminology and concepts. From RFC 5357 +----------------+ +-------------------+ | Session-Sender |<-TWAMP-Test-->| Session-Reflector | +----------------+ +-------------------+ ^ ^ | | | | | | | +----------------+<----------------+ | | Server | | +----------------+ | ^ | | | TWAMP-Control | | v v +----------------+ | Control-Client | +----------------+ Something I already mentioned to the RFC 6374 authors in the past when doing my OPS-DIR review. Sigh... Anyway, please engage in the discussion regarding Eric Vyncke's OPS DIR review: This short I-D is quite clear and easy to understand, security & manageability sections are correct. I found nothing in this framework document which could cause operational issues EXCEPT: as I am unsure of the usual PLDM procedures, what is the expected behavior when a PLDM message (incl a URO) is received by a PLDM node which does not support this object type? If it is well defined in PLDM, then there is no problem of course. Can a reply be fragmented? Should the reply contains the DF bit for IPv4? Probably worth mentioning what to do over fragmentation. What is the expected behavior when the URO contains an IPv6 address and the PLDM responder only has IPv4 address(es)? Small nits: in introduction, I guess you meant "internally be forwarded" rather than "internally forwarded" Section 4.3, when selecting the source address, you may want to refer to RFC 6724
I agree with Stephen's comments and would like to see additional follow up from the SecDir review.
-- Section 3 -- Multiple UROs MAY be present in a MPLS-PLDM Query indicating that an identical responses SHOULD be sent to each address-port pair. A small point: I think this is not meant to be instructions to the entity issuing the query, but to the entity responding. Is that correct? If so, the "MAY" is a statement of fact, not a normative requirement, so it should be "may" (or "might"). Also, the word "an" should be removed. -- Sections 4.x -- Should the subsection titles of 4.1, 4.2, 4.3, and 4.4 say "MPLS-PLDM" instead of "MPLS-PM"?
I would be fine keeping the to-be-deleted text explaining alternatives that were not selected, especially if it was moved to an appendix. If anyone ever wonders about the alternatives, that would mean they didn't have to dig through e-mail archives to see what was considered and why the alternatives were rejected. I'm not understanding why When the MPLS-PLDM Response is requested out-of-band by setting the Control Code of the MPLS-PLDM query to "Out-of-band Response Requested", and the URO is present, the responder SHOULD send the response back to querier on the specified destination UDP port at the specified destination IP address contained in the URO. is a SHOULD. Could you help me with that?
Eric Vynke performed the opsdir review
- I agree with the discuss points about use of TLS. - I think it'd be better if you clarified that by "mutually authenticated" you mean TLS client auth and TLS server auth and not e.g. HTTP BASIC plus TLS server auth. - I think a statement to the effect that the mechanisms for access control are dCDN-specific (for now at least) might be a good addition. I'm guessing that someone might want to use some form of OAuth later on (or is doing so now) so part(s) of that might be a thing to standardise later.
I've got two concerns that I think leave ambiguity around important normative requirements. Hopefully they will be easy to resolve: - 4.7, 2nd bullet under handling of offline surrogates: I assume I am missing something here. How does a surrogate know that the situation exists in the first place? How would a surrogate know about invalidate commands that happened while it was offline? - 8.1, 4th paragraph from the end: The language here is ambiguous about whether the use of TLS is _always_ required, or just when "such protection is required." From context, I assume the latter to be the case. But "To that end..." can be interpreted to mean "In that case, one MUST do X", or to mean "In order to make that possible when needed, one MUST _always_ do X" I propose the following: OLD: In an environment where any such protection is required, mutually authenticated encrypted transport MUST be used to ensure confidentiality of the CI/T information. To that end, TLS MUST be used by CI/T, including authentication of the remote end. NEW: In an environment where any such protection is required, mutually authenticated and encrypted TLS MUST be used to ensure confidentiality of the CI/T information. END.
- 3, paragraph 5: SHOULD should not be equated with "optional to implement". MAY means that. SHOULD is intended to be stronger. - 4.5, 2nd paragraph, 1st sentence: This is pretty convoluted. I suggest reformulating without the past tense "MUST". For example, "The dCNI MUST report the expiration times if..." -4.6: "If CDNs B and C delegate delivery of CDN A’s content to each other" Is this a reasonable configuration? It seems like they might already have a delegation loop before the trigger interface got involved. Also, the first sentence is a fragment. = 4.8, first paragraph: I suggest s/transform/"similarly transform" - 5.1.3, staleresourcetime, mandatory: Doesn't this effectively mean the value must be the same across all collections? - 5.2.1, content.ccid: Seems like the reference to [I-D.ietf-cdni-metadata] should be normative. - 6.2.5: it looks like the dCDN is sending the request to itself. Is that the intent? - 8.1, last paragraph: "In this case, the dCDN MUST allow each uCDN from which the content could have been acquired to act upon that content using CI/T Commands." This seems like a place where local policy might reasonably vary. Is a MUST really appropriate?
I'm a no objection, but do want to see why TLS is not a MUST. I've responded to Ben's discuss that proposes language to make it clear whether or not TLS is a MUST. Right now, I think it is just a MUST when certain conditions are met - the need for the security properties called out in 8.1 and commercial privacy considerations in 8.3.
= Section 5.1.8 = Name: staleresourcetime Description: The length of time for which the dCDN guarantees to keep a completed Trigger Status Resource. After this time, the dCDN SHOULD delete the Trigger Status Resource and all references to it from collections. I'm not clear on why this is a SHOULD rather than a MUST. If the dCDN tells the uCDN it's going to delete resources after a specified period of time, why shouldn't it follow through on that? For a uCDN that relies on resources not sticking around after a specified period of time (because of security or competitive concerns), doesn't this need to be a firm requirement so that the uCDN doesn't have to issue purge requests to be sure that its resources get deleted? = Section 8.1 = I had the same confusion as Ben and the secdir reviewer concerning whether TLS is always required to use or not. If there are cases in which TLS is not mandatory to use, then I think this should be phrased as a SHOULD with the exceptions clearly enumerated. For example, it's not clear to me whether the only exception is environments where equivalent protections are afforded by a different protocol, or if just being within a single administrative domain is considered protection enough (not sure I agree with the latter).
= General = I think the examples in the document should use https URIs. = Section 3 = "Trigger Status Resources belonging to a uCDN MUST NOT be visible to any other CDN. The dCDN could, for example, achieve this by offering different collection URLs to each uCDN, and/or by filtering the response based on the uCDN with which the HTTP client is associated." Using different URLs for different uCDNs is not sufficient for this, correct? I think the "and/or" needs to be just "and". = Section 4.1 = I don't understand the difference between when status is used in quotes and not in quotes, e.g., 'Once processing has started the "status" MUST be "active"' vs. 'once the CI/T Command is complete, the status MUST be set to "complete" or "failed"'. = Section 4.3 = s/requires no processing in the dCDN, its status MUST NOT be changed/requires no processing in the dCDN. Its status MUST NOT be changed/ = Section 5.1.1 = "Name: cdn-path Description: The CDN Provider Identifiers of CDNs that have already accepted the CI/T Command." I find the phrase "already accepted" somewhat confusing, since a uCDN is supposed to insert its own on ID here, and in that sense hasn't "accepted" anything, but is making the request itself. = Section 8.3 = s/parties other party than the authorised dCDN/parties other than the authorised dCDN/
Before I ballot yes on this I have a question to ask. Most likely the answer will be the obvious one and we'll be done, but I want to check and if the answer is not the obvious one then holding the discuss as we fix stuff would be correct I think. The question: how does this option play with DNS over DTLS?  The reason I ask is that there may be a need in that case for some similar option (or a TLS extension maybe) though for the DTLS session lifetime and not a TCP session lifetime. At present you are saying that this option is not it. And that's a fine answer but you could also have said that this could also be used for DTLS session lifetime handling. And that last might make sense for operational reasons (not sure really, but could be).  https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03
- intro: "However, TCP transport as currently deployed has expensive setup overhead." That seems a bit wrong as the 3-way h/s is an inherent part of TCP and isn't really specific to DNS with TCP trasnport not is it a deployment issue. I'd suggest just delete the sentence and merge the remaining part of tha para with the next. - 3.3.2: What's the last sentence of this section about? A case where a TCP session is handed over? Might be no harm saying why (via a reference to anything would be fine)
- 3.2.2: I think it would be helpful to give some more guidance about the “timeout” period. That is, when does it start, does it reset when a new query is sent, etc? This is somewhat implied by the term “idle”, but it would be better to be explicit. -3.3.2: I understand from later in the draft that the OPT RR in a query does not necessarily need to have include edns-tcp-keepalive for the server to include it in the response. A careless reader might easily miss that distinction. It would be helpful to emphasize it here. === Editorial=== - Abstract: The abstract is rather long. The first paragraph might be better left to the introduction section. - 1: The introduction sort of buries the lede. The idea that clients and servers need to manage idle connections is not mentioned until paragraphs 8 and 9. That's the whole point of the document.
Two comments for your considerations: 1) Section 3.3.2 is talking about this "It is reasonable for this value to change [...] or in consideration of intermediary behaviour (for example TCP middleboxes or NATs)." Can you please clarify how the DNS client or server is able to inspect the behaviour of intermediated devices and adapt its behaviour accordingly? This smells a bit like a half-baked idea which does not belong into a standards track document. 2) Section 3.6. talks about using Multipath TCP. Please note that Multipath TCP is still experimental and has known security issues, which are dealt with right now. Further, I would recommend to move this to a non-normative appendix, noting that this is a potential future way forward, but that is has not yet been tested and deployed. This would also honor that RFC 6824 is listed in the informative part of the references.
-- Section 1 -- Long-lived TCP connections can result in lower request latency than the case where UDP transport is used and truncated responses are received, since clients that have fallen back to TCP transport in response to a truncated response typically only uses the TCP session for a single (request, response) pair, continuing with UDP transport for subsequent queries. This is a really long, awkward sentence, and it appears to have an error in it that makes it unparseable. May I suggest a replacement?: NEW Responses over UDP might be truncated, and when that happens many clients will retry the query over TCP. Such retries typically use the TCP session only for one request/response pair, and the clients then revert back to UDP for subsequent queries. Using long-lived TCP connections in the first place avoids these situations and can result in lower request latency. END In general, calling the retry over TCP "fallback" is misleading, and I suggest not doing that. The term "fallback" generally refers to a situation where an optimization fails, and you "fall back" to the non-optimized method. That's not the case here; here, UDP is the normal method, and you retry over TCP when the response is too big to work with UDP. The use of "fall back to UDP" in Section 3.4 is an apt use of "fall back", in that sense, as is the use of "fallback" in Section 3.5. But the use in the abstract and at the top of page 4 are not. I suggest "clients commonly use TCP only for retries" in the abstract, and "received over UDP with retries over TCP" on page 4.
Thanks for the quick resolution to my DISCUSS point. The proposed change is recorded below for posterity. OLD: It SHOULD honour the timeout and initiate close of the connection before the timeout expires. NEW: It SHOULD honour the timeout received in that response (overriding any previous timeout) and initiate close of the connection before the timeout expires.
Don't we need text warning that TFO is likely problematic with DNS privacy and that attacks that try to prepend information (via TFO) to otherwise secured sessions could occur? While that might sound a bit far-fetched we have seen exactly that kind of issue with HTTPS that had practical impact on Webdav. (The TLS renego and then triple handshake attacks.) So while using TFO may not enable a slam-dunk CVE level 10 attack, I think you do need to consider and talk about it. (Or maybe you did and figured out no attack can work, but then I'd guess you'd be so happy, you'd say that too:-) I'm not sure how this'd best be resolved, but one thing might be to talk to the folks thinking about TCPINC as they have at least hit this as a potential issue for tcpcrypt and for tcp-use-tls. Otherwise, this is a fine document on which I'll ballot yes when the above is sorted.
I don’t have concerns over the technical content of this document, but I do have want to raise a process-related DISCUSS. The Intended RFC Status of this document is “Internet Standard”, which seems like a logical progression from RFC5966 (Proposed Standard). However, I am concerned that the proper process was not followed: 1. RFC6410 calls for “an IETF-wide Last Call of at least four weeks”, but the LS started on Nov/23 and ended on Dec/7, 2 weeks. 2. In looking at the archives I couldn’t find any discussion about changing the maturity level. 3. It also concerns me that the changes go beyond a simple revision of the old text. For example, there are recommendations that are completely new and for topics that were not even mentioned in the original (e.g. pipelining). I may have missed the discussions in the archive. Not being a DNS expert I may also be overestimating the changes to this document. But knowing that the “document was actively discussed and reviewed” and that it “had a broad discussion as the wording of several points were more accurately described” (from the Shepherd’s write up), I think that this document may not be ready to be an Internet Standard. The obvious solution to this DISCUSS is to change the intended status to Proposed Standard.
I'm balloting "yes" under the assumption this is intended as proposed standard. 22.214.171.124: Now that clients SHOULD pipeline, is it enough to say servers SHOULD expect it? Seems like a MUST would be in order. === Editorial=== -1: "... TCP is henceforth a REQUIRED ..." Since the normative language is strengthened in section 5, the REQUIRED seems redundant here. I'd suggest stating this without the 2119 keyword. - 5, 2nd to last paragraph: I concur with Barry on the unclear antecedent of "It".
One comment and request for clarification: In the first paragraph of Section 8: " DNS clients and servers SHOULD pass the two-octet length field, and the message described by that length field, to the TCP layer at the same time (e.g., in a single "write" system call) to make it more likely that all the data will be transmitted in a single TCP segment. This is both for reasons of efficiency and to avoid problems due to some DNS server implementations behaving undesirably when processing TCP segments (due to a lack of clarity in previous standards). For example, some DNS server implementations might abort a TCP session if the first TCP segment does not contain both the length field and the entire message. " This paragraphs says that DNS servers process segments. This is slightly inaccurate, at least under the assumption that DNS clients and servers are user land processes. Such a user land process does not see segments but data being read or written to the sockets. And such data might be one or multiple segments concatenated. I do understand the text, but I would like to propose a change (though the proposed text might not be perfect): This is both for reasons of efficiency and to avoid problems due to some DNS server implementations behaving undesirably when reading data from TCP (due to a lack of clarity in previous standards). For example, some DNS server implementations might abort a TCP session if the first data part read from TCP does not contain both the length field and the entire message.
I was slightly surprised by "implementation requirements" in the title. If we write a RFC, we hopefully hope/require future implementations, right? I understand the willingness to change as little text as possible compared RFC5966, but I would welcome the following update: OLD: DNS Transport over TCP - Implementation Requirements draft-ietf-dnsop-5966bis-05 Abstract This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC5966 and therefore updates RFC1035 and RFC1123. NEW: DNS Transport over TCP draft-ietf-dnsop-5966bis-05 Abstract This document specifies TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC5966 and therefore updates RFC1035 and RFC1123.
-- Section 5 -- This requirement is hereby relaxed. Stub resolvers and recursive resolvers MAY elect to send either TCP or UDP queries depending on local operational reasons. TCP MAY be used before sending any UDP queries. If it already has an open TCP connection to the server it SHOULD reuse this connection. In essence, TCP ought to be considered a valid alternative transport to UDP, not purely a fallback option. The "If it already has" in the fourth sentence was clear in the original 5966 text, but doesn't work here: there's no clear antecedent to "it". Please make it "If the resolver already has". In the last sentence, I think we should say "not purely a retry option," as this isn't really "fallback" in the sense we usually use the term. -- Section 6.1.1 -- However it is common practice for clients to close the TCP connection after sending a single request In the light of edns-tcp-keepalive, do we really want to say this? It's true, but it sounds like a recommendation. Maybe we might say something like, "Clients often close the TCP connection after sending a single request, but see [draft-ietf-dnsop-edns-tcp-keepalive]." ?
In this text: It is however noted that certain primary/secondary configurations with many busy zones might need to use more than one TCP connection for zone transfers for operational reasons. could "for operational reasons" be a bit more precise? I think I know the problem that's being solved, but I'm guessing, and other readers might not know.
While I am not a fan of standards-track requirements documents, I understand the history of 5966 and support the publication of this document. I do have a couple of comments for your consideration. 1. Is it worth mentioning in the Intro that another drive towards more TCP-based DNS exchanges may be the desire to re-use existing security associations for DNS privacy solutions? 2. Is there a reference to back up the statement "However, transport of UDP packets that exceed the size of the path MTU causes IP packet fragmentation, which has been found to be unreliable in many circumstances."? It would be good to be able to gauge just how unreliable this issue has become. 3. I agree with Martin's suggested re-wording in Section 8.
I agree with Ben's comment about the IPR. If it helps, I'd be happy to hold a discuss to get that sorted.
(Note that there was a post IETF LC IPR declaration. We should discuss whether we need to re-run the last call. I think Alissa is on top of this, so I did not make this a DISCUSS) Otherwise, I have a few minor comments: - 4: "The report block MUST be sent in conjunction with the information from the Measurement Information Block [RFC6776]. " "MUST be sent in conjunction" is ambiguous. I think you mean that, if the LC block is sent, the Measurement Information Block MUST also be sent. === Editorial=== - 1, 2nd paragraph: Please expand QoE on first mention. Also, I think there's a cut-paste or edit error in the last sentence: OLD: Evaluating error concealment is important in the circumstance in estimating the subjective impact of impairments. NEW: Evaluating error concealment is important for estimating the subjective impact of impairments. -4:, 1st paragraph: There are several instances of "this metric block" where the antecedent for "this" is not clear. I think they all refer to the loss concealment block. I suggest changing most or all instances of "this metric block" to "the loss concealment block."
-- Section 7.3 -- There is no longer a "RAI" area, and <email@example.com> is no longer an appropriate email address (for two reasons: these aliases have also been moved to @ietf.org). I suppose this should now be "ART Area Directors" and "<firstname.lastname@example.org>". We should check this in other documents that come from the former APP and RAI areas, as well.
... and I would be a Yes, except that I don't want to be a Yes while the sponsoring AD is still a Discuss!
Changing to DISCUSS since I'd like to discuss the IPR situation with the IESG. I had thought re-confirming with the WG that they still wanted to progress the draft would be sufficient given the terms of the disclosure, but if folks think we need to do another IETF LC we should discuss. Also the WG's own discussion about the IPR is ongoing.
scott bradner performed the opsdir review
Thanks for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06287.html
Because abfab-arch defines the terms "Client", "Relying Party", and "Identity Provider", I think abfab-arch should be a normative reference. -- Section 3 -- The RADIUS SAML binding defined in Section 4 of this document uses two attributes to convey SAML assertions and protocol messages respectively [OASIS.saml-core-2.0-os] Nit: "respectively" is out of place here, and should be removed. You would only use "respectively" if you named the two attributes ("...uses two attributes, SAML-Assertion and SAML-Protocol, to convey SAML assertions and protocol messages, respectively."). -- Section 7.3.5 -- If issued by the Identity Provider, the Relying Party MUST process the <samlp:Response> message and any enclosed assertion elements as described in [OASIS.saml-core-2.0-os] "If issued" is dangling, and makes it look like the Relying Party is issued by the Identity Provider. NEW If a <samlp:Response> message is issued by the Identity Provider, the Relying Party MUST process that message and any enclosed assertion elements as described in [OASIS.saml-core-2.0-os] END -- Section 11.2 -- Thank you; this section is well done.
Thanks for answering my questions about extending the SAML spec. The use of normative MAYs in Section 9 does not seem appropriate.
This is a well written document. I have a couple of major comments that should be addressed before publication (and some minor ones/nits below). 1. In Section 6.1. (Topology sub-TLV) I think there's a small RFC2119 conflict. "The variable length Topology sub-TLV MUST be used to describe an explicit tree. The Topology sub-TLV MAY be also used for describing a…GADAG". That text says that the sub-TLV has to always (MUST) be used to describe an ET, and that it can also describe a GADAG. I think that clearly it is one or the other. Suggestion: NEW> The variable length Topology sub-TLV is used to describe an explicit tree. The Topology sub-TLV may be also used for describing a Generalized Almost Directed Acyclic Graph ( GADAG). 2. Section 7. (MRT-FRR Application) talks about the specific use of I-D.ietf-rtgwg-mrt-frr-algorithm. However, the description doesn't match the Default MRT Profile as specified in draft-ietf-rtgwg-mrt-frr-architecture — please include in this document a description of the MRT Profile used. Minor/Nits: 1. It is nice that you put references in Section 3. (Terminology and Definitions) for each entry. However, the definitions are not exactly the same as the source — for example, the definitions in this document and in I-D.ietf-rtgwg-mrt-frr-architecture are similar, but not the same. I'm sure some of the differences are just word choices, but I find that it may be confusing. 2. In Section 2. (Conventions Used in This Document) I found the second paragraph ("The lowercase forms with an initial capital…") interesting, but then couldn't find any cases where the words were used. Did I miss them? If they're not used I would delete the paragraph to avoid confusion. 3. Section 4. (Explicit Trees) * "An ET MUST NOT contain Cycles." I'm guessing that "Cycles" refers to loops, right? I just wanted to clarify because you used a capital C — nothing wrong with that, just that it might be a special term. BTW, the fact that an ET is defined as loop-free should cover this anyway. * s/Unidirectional Utilized Bandwidth/Unidirectional Bandwidth Utilization 4. Section 8. (Summary) is superfluous.
This comment from Suresh Krishnan's Gen-ART review seems relevant: There is no reference for the format of the Bandwidth fields in Sections 6.3 and 6.4. I am assuming this refers to the Single Precision format (binary32) from IEEE 754. If so, please add an explicit reference to this.
As mentioned by the Linda Dunbar in her OPS-DIR review: Minor issues: Why the Bandwidth Constraint sub-TLV is not same as the Bandwidth Sub-TLV defined by https://tools.ietf.org/html/draft-ietf-isis-te-metric-extensions-07#page-10? Need to make sure that the Bandwidth Sub-TLV (unidirectional available bandwidth, unidirectional utilized bandwidth sub-TLV, etc), of draft-ietf-isis-te-metric-extensions is consistent. Regards, Benoit
I was going to ask to discuss this: The lowercase forms with an initial capital "Must", "Must Not", "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" in this document are to be interpreted in the sense defined in [RFC2119], but are used where the normative behavior is defined in documents published by SDOs other than the IETF. ...because I think this is a too-subtle distinction that would be confusing to many readers. But you don't appear to actually have any such terms in the document. Please remove that paragraph.
carlos pigntaro did a great job on the odsdir review resulting in draft 03 and our major concerns are addressed.
- section 2, last paragraph: It was not obvious to me if "An IMAP client SHOULD be able to parse both formats. " meant both STATUS and LIST, or both global and per-mailbox. I assume the former.
Thanks for your work on this extension, it seems useful, I just have a few comments that can be left to the editors and AD to handle if I disappear for maternity leave. I think the security considerations section could be a bit more clear on the actual risks with this extension. I think the flow of the section can be improved to make these risks a bit more clear. First, this extension lets you find out the limit for either the server or individual mailboxes, so shouldn't the first part of the description focus on a possible DoS filling up those resources? I'm not sure why there is a focus on "without this extension". Then, it's a common security programming practice to enforce size limitations in code. Why is there a focus on an attacker sending append content that exceeds the allowable size rather than just saying that such append content should be rejected?
It's unusual to see author names without first initials in the document header. Not sure if that was intentional but seems like it should be fixed (assuming the authors have both first names and surnames). = Section 2 = "In this case the client SHOULD get an APPENDLIMIT value by issuing a STATUS or LIST command. An IMAP client SHOULD be able to parse both formats. By looking at the upload size advertised by the IMAP server, a client MUST NOT try to APPEND mail more than the advertised limit." The first and last normative requirements here seem too strict considering that this extension basically allows an optimization. That is, if a client decides not to find out the append limit for a particular mailbox using STATUS or LIST, that doesn't seem to create any particular problem. Likewise, it seems better for a client to avoid sending an attachment larger than a known limit, but doing so doesn't seem so problematic as to warrant a MUST NOT.
Sarah Banks performed the opsdir review
I suspect the "well reviewed" and that the AD "should confirm" parts of this will be ignored and could be dropped.
recused since it's an action I pretty much instigated. reviewd by Nevil Brownlee for the opsdir
I have no concerns about the contents of this document, but it bothers me that it doesn’t include all the information. Yes, I realize the figures can’t be properly included in ASCII art. I suggest that the authors include a note (at the top of the document or even in the Abstract) that points the reader to the “complete” version. [Take a look at RFC1305 for an example.]
-- Abstract -- The abstract seems to have too much detail about what the document concludes. The abstract should just be a general statement of what the document is about -- just enough that someone can determine whether this document is relevant. I think I would do something like this: NEW Pseudowires (PWs) have become a common mechanism for tunneling traffic, and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. It is thus worthwhile specifying under what conditions such competition is acceptable, where the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. This document makes that analysis and provides recommendations. END The rest of the detail needs to be in the document -- perhaps in the Introduction -- but not in the abstract.
So, very nice. I have one request for you to consider. In this text: The figures presented above demonstrate that TDM service quality degradation generally occurs before the TDM PW would consume more bandwidth that a comparable TCP flow. Thus while TDM PWs are unable to respond to congestion in a TCP-like manner, TDM PWs that are able to deliver acceptable TDM service do not contribute to congestion significantly more than a TCP flow. Combined with our earlier conclusion that Ethernet PWs respond in TCP-like fashion, leads to our final conclusion that no PW-specific congestion-avoidance mechanisms are required. I can't tell whether or not you're saying that a TPM PW only needs a circuit breaker as an absolute last resort, or it doesn't need a circuit breaker, or something else. If you could finish the last sentence with a word about that, I think it would be helpful.
The first sentence in the abstract needs a comma before "scrypt". Or even better "... derivation function, known as scrypt". (I spent some time working out that this was not a misspelling of "... derivation function script")
I strongly agree with both Ben and Kathleen. The abstract reads as if the IETF has reached a consensus position, which is not appropriate for an ISE document.
I'd also like to discuss this one some more. So far, I've looked quickly at the diff between the last one we reviewed and the latest version. That's . That diff absolutely does not convince me that the draft is now only describing something already deployed. For example the latest one still says "...intended to allow broad deployment of the mechanism on the public Internet." That remains entirely inconsistent with IETF BCPs and so I believe we should revert to the previous DNP response to the ISE. If we reach consensus on that, then I'm not sure if we should try to identify all the "badness" in -07 or if we should just say "please DNP, no material change from our POV." I think the latter is more appropriate but maybe this is something we ought discuss with Nevil - what's the right/best kind of IESG response in such a situation. Which leads me on to... Also - from the ballot it's not possible for an AD to determine anything about why the ISE has returned this item. I think that is also something about which it'd be good to chat with Nevil, from a possible tooling POV but also from a transparency and accountability perspective. I think when/if the ISE is interacting with the IESG in cases like this, it would seem fairly obviously beneficial if the ISE's perspective on what's changed was part of the record. (Or perhaps the ISE's editorial board, I don't even know which applies.) The history of this overall set of documents and their authors' doggedness in attempting to achieve publication as an RFC (which is an entirely reasonable thing for authors to do) would seem to indicate that we ought carefully consider if we're collectively (IETF+ISE+RFCed) sending a message that all one has to do is keep asking and you can get any bad idea out as an RFC. I think we do not want that perception to spread.  https://www.ietf.org/rfcdiff?url1=draft-williams-exp-tcp-host-id-opt-05&url2=draft-williams-exp-tcp-host-id-opt-07
Update: I find Alissa's and Stephen's DISCUSS positions convincing. I'd prefer the abstract to read less like an IETF endorsement of identifying hosts behind NATs. (But not so strongly to block things, given the updates.)
The authors have added text in Section 8. Pervasive Monitoring Considerations that addresses aspects of RFC 7258. Plus added statements about what of what not should be used in the HOST_ID part.
First, I agree with Alissa, Stephen, and Ben. Secondly, I do not consider this specific design to be an improvement in the Internet, and that is the reason why I am balloting an Abstain in this case. The Abstain has no significance in the case of this type of a document going through the RFC Editor, but I wanted to be on record in disagreeing with this document. Overall, I understand the need to protect against denial-of-service attacks and other issues, without causing collateral damage for other users behind the same IP address. But, I do not believe we should be increasing the attack surface against the Internet users at large. The potential for privacy violations from criminals, entities involved in collecting far too much information from web users, and illegally operating surveillance organisations is just too great. One additional note: If you want to publish a good document, there might be some other designs, such as the random ID variant that have smaller worries than the current design. I am not saying those designs would be good, or that I would change my position, but those other designs would certainly be a marked improvement over the current document.
I agree with Ben's point, especially in light of the described use cases. Although this is just documenting what happens, it would be best if this does not sound like an endorsement of these practices.
I am with Alissa and Stephen that this should be a Do Not Publish response.
I think the previous conflict review response was correct, not the current one. I think the way that this spec justifies the design decisions that may allow the HOST_ID option to be used for pervasive monitoring can be summarized as: the option merely puts back in host identification information that a middlebox otherwise would have stripped out. I don't think this is really satisfactory. RFC 7258 doesn't say that we will work to ensure that pervasive monitoring remains only as easy or hard as it was before the deployment of CGNs or application proxies. It says that we will work to mitigate pervasive monitoring. So from the perspective of mitigating PM, the loss of unique host identification on the egress side of address-sharing devices is a virtue. Of course, the motivations for re-introducing host uniqueness are well-documented. But this draft doesn't link the specification of the option to those motivations in a way that provides the justification that RFC 7258 requires, IMO. In particular, the document allows for the HOST_ID to contain an IP address or subnet, optionally together with a TCP port number. Under some circumstances using the option in these ways leaks information that allows for correlating the activities of the host more broadly than if the option were not used -- e.g., if an application proxy uses the option in this way, then the host traffic on the egress side of the proxy can be newly correlated with the host's traffic that does not pass through the proxy. If instead the proxy used a random, locally unique ID in the option, this type of correlation would not be re-introduced. So why should the option support embedding an IP address and TCP port, if all it needs to provide is local uniqueness for the hosts sharing the public address? Doesn't an opaque locally unique ID suffice for the three use cases listed in the document?