IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-12-04. 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: Pete, John
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
1207 EST no break
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
Amy: returning to action-items, (name) agreed to be expert, any objections? (silence); thus that Action-item will go to status completed.
7. Agenda Working Group News
1248 EST Adjourned
(at 2014-12-04 07:30:33 PST)
This document addresses several of the concerns I've had with previous versions of NFS. Thanks for doing it!
(1) 220.127.116.11: Do you really still need to say that clients do not need to support rpc_gss_svc_privacy? That seems inconsistent with e.g. RFC7258 and the recent IAB statement on confidentiality. Neither of those strictly require protocols to support confidentiality of course, they mostly encourage it, so I'm not DISCUSSing on the basis that our processes require confidentiality. It just seems to me like it's probably not really a problem today to say that client MUST support that GSS service as well. Am I wrong? I'm perfectly willing to be convinced that I'm wrong here btw e.g. if there are a whole slew of implementations that can't support this but I suspect that might no longer be the case. (I can well imagine it used be the case a decade ago.) And if I am wrong then I'm happy to clear the DISCUSS, on the basis that you're not really changing the protocol here so it'd not be reasonable to insist on you adding confidentiality part of this work. (2) 18.104.22.168: The reference to Kerberos via 4121 (and updates) presumably makes AES the MTI crypto alg now? If not, that I think would need to be called out but I think it is the case. I just wanted to check that we're not allowing for something mad like single-DES still be nominally consistent with this spec. (I saw from Tom Haynes August 2013 response to my DISCUSS on -26 that there are such implementations, but I hope they are not considered compliant in that respect.) So this is just checking.
Review is based on diff: https://tools.ietf.org/rfcdiff?url1=rfc3530&url2=draft-ietf-nfsv4-rfc3530bis-34.txt And also on the diff vs. version -26 which was the last time I reviewed this (in May 2013) https://www.ietf.org/rfcdiff?url1=draft-ietf-nfsv4-rfc3530bis-26&difftype=--html&submit=Go!&url2=draft-ietf-nfsv4-rfc3530bis-34 - Despite splitting out the xdr stuff, you have still managed to increase the size of another NFS monster spec. That's not really going in the right direction from the POV of this reader. I'd encourage the WG to consider re-factoring the NFS documentation into more digestable chunks at some point. (While fully realising the huge and thankless effort that would involve.) At some point, making these RFCs bigger and bigger is going to by itself break something. - 1.5: The move away from lipkey and spkm is quite reasonable. - 3.3.1 - SECINFO is no longer "new" since that text hasn't changed since 3530:-) - 5.9: What does "kerberized" mean? If you mean "uses Kerberos" then saying that would be better than inventing a new term. If it means something else, then I'm not sure what. - 6.2.1 says: "Therefore servers should accept every ACL that they can without compromising security." I know what you mean, but I'm not sure if it's possible to implement that, in general. Wouldn't it be possible to say some more about what a server has to implement? - 10.4.1, last para: (This was a DISCUSS on -26, but is now a comment based on Tom's response) "making private copies" of credentials sounds odd. I assume you mean kerberos tickets but I'm not sure how that can work. I'd also guess its security mechanism specific. Doesn't that need either some more text or to just say that it doesn't work? Or am I confused? (Quite possible;-) And Tom said: "Actually, it simply means UID and GID here. As an example, there are scenarios in Solaris where when pages get flushed to disk, the UID and GID from the original system write have been lost and the page goes across the wire with root credentials. This can be okay on a local file system but not on a remote one." So I think making that clear would be good or just not saying those are credentials. - section 17 says: "...the translation SHOULD be done in a secure manner that preserves the integrity of the translation." I don't know how that SHOULD turns into code - does 5.9 really tell me exactly? If not, what's missing in 5.9 and shouldn't that be here? If 5.9 does tell me exactly then I think a more precise reference to the bit of 5.9 that's not a MUST (presumably leading to this SHOULD) is needed.
As Barry said, the rewrite of section 12 is generally excellent work. Thanks for that. My only concern is 12.6. I've spent some time trying to fix this section, and I think any problems can be easily addressed, but I'm not sure what the intention is, so I've not been able to come up with the right text. So, let me ask some questions. Do you mean to reject strings that have characters that are not IDNA-valid according to IDNA2008? That is, do you want to allow or disallow strings that are valid UTF-8 but aren't valid U-labels? Similarly, do you want to reject invalid ASCII LDH-labels or invalid A-labels? Remember, U-labels and A-labels only contain IDNA-valid characters. Or, conversely, do you want to use the old NAMEPREP routine from RFC3491 and map invalid stuff into valid stuff? The text as written doesn't make that clear, and it doesn't do either of those two things correctly, so let me know what you want to happen, and I'll try to help you make it happen.
I have re-reviewed those sections that have changed (particularly section 12) and included comments from my earlier review that have not been addressed. 1.3.6: At OPEN, the server may provide the client either a OPEN_DELEGATE_READ or OPEN_DELEGATE_WRITE delegation for the file. If the client is granted a OPEN_DELEGATE_READ delegation, it is assured that no other client has the ability to write to the file for the duration of the delegation. If the client is granted a OPEN_DELEGATE_WRITE delegation, the client is assured that no other client has read or write access to the file. Personally, I think the 3530 use of the informal words is better instead of OPEN_DELEGATE_READ/WRITE in the introductory section. Those terms are not defined at this point. 2.1: s/String MUST be sent as ASCII/String is sent as ASCII 4.2.3: SHOULD return an error of NFS4ERR_FHEXPIRED. So you're now saying that it's an interoperability problem to return other than NFS4ERR_FHEXPIRED, but there might be cases where you have to? Can you give an example of one of those cases? 5: In this section, you changed "mandatory attributes" to "REQUIRED attributes" and "recommended attributes" to "RECOMMENDED attributes", and uppercased a bunch of MUSTs, SHOULDs, and MAYs. I'm a bit worried you did this simply because one or more people said "Shouldn't those all be 2119 terms?" without any particular reason, and I'm worried that some of the new uses actually don't make sense. For example, you now have: A server should support as many of the RECOMMENDED attributes as possible but, by their definition, the server is not required to support all of them. RECOMMENDED, in the 2119 sense, doesn't mean that. RECOMMENDED (like SHOULD) means, "There may be reasons to not do this, but you need to understand the full implications of doing so, because normally this is required for interoperability or to avoid harm." Later in 5.2 you say: A client MAY ask for any of these attributes to be returned by setting a bit in the GETATTR request but must handle the case where the server does not return them. A client MAY ask for the set of attributes the server supports and SHOULD NOT request attributes the server does not support. A client must handle the case where the server doesn't return REQUIRED attributes as well (i.e., a client can't just crash because a server is broken). It sounds to me like these RECOMMENDED attributes are really OPTIONAL in the 2119 sense. (They might be "recommended" in the informal sense, as I think you had it before, but 2119 terms muck up the issue.) Also, it seems to me that a client MUST NOT request attributes that the server does not support, not SHOULD NOT. I'm not convinced this improved the document. 5.9: OLD For example, the DNS domain name might be "lab.example.org", but the user names are defined in "example.org". This is written ambiguously. I think you mean NEW For example, the DNS domain name of the host running the NFS server might be...". I don't think the following is helpful: OLD Internationalization issues (for a general discussion of which see Section 12) make this impossible and the client needs to take note of the following situations: I think you should simply refer to section 12 and not give the examples here: NEW Internationalization issues make this impossible under certain circumstances and the client needs to take note of these. See Section 12 for a detailed discussion of these issues. 8.2, third paragraph: s/whether it has moved or not/whether it has moved or simply never existed 9.8, fourth paragraph: I don't know how to implement a "MUST NOT assume". Change back to "may not" or make it "can not", or explain exactly what it is that a client MUST NOT do as a result of a failed operation. 10.2: However, the time allowed for recall completion SHOULD NOT be unbounded. That's not a very helpful normative requirement. I don't see why you changed it to such a thing. 12ff: Generally, excellent work. Thanks for this. 12.1 makes me laugh a little, since those definitions are *exactly* how 2119 defines the terms, only in more detail. The "conformance" use that we see in other documents nowadays, that this section is trying to distinguish itself from, is not what 2119 says. 12.3 (editorial): This sentence is repeated twice: "Such servers ignore normalization-related issues and there is no way for them to implement either normalization or representation-independent lookups." 12.4: I don't understand the reference to 2279. There's nothing in there that isn't in 3629. 12.5: s/must normalize/will need to normalize Just to avoid confusion.
Based on the "Changes since RFC 3530" section 1.5, I don't believe that there is any OPS related new issues.
I support Stephen's discuss points and will add to the pile-on request (I believe the author agreed with this already) to slit the document up into digestible chunks next time. As Alissa pointed out, some of the text comparing versions adds unnecessary bulk to the draft. I think it would be helpful to just have one section that includes changes, then have the set of specifications that make up the new version just specify that new version. If you need to track motivations, perhaps using a wiki or a draft that may or may not be published would be better. In the Security Considerations section, in the last two sentences of the first paragraph it seems like the word "privacy" is used where you mean "confidentiality", both are important. Confidentiality is a security property that can help with privacy, but so can leaving the privacy sensitive data out and not encrypting sessions. Confidentiality can apply to scenarios other than privacy specific ones as well, so they really shouldn't be conflated. Confidentiality may be required to protect business information that doesn't have an effect on privacy (not HR sensitive data or identifying information about an individual). It seems odd in section 3 to call one of the security "flavors" privacy, I think you mean confidentiality here. I'm guessing this term usage is because of rpc_gss_svc_privacy. It might be helpful to explain the intended use and then map to the GSS functions. Section 8.4 - Just as an FYI that does not need to be added to the draft, the location information would also be useful for ESI Data Maps, part of which requires an organization to track each instance of data (along with security protections and other information like retention periods.)
First, a general comment on Section 12: This was a lot of work, and is very well done. Of course, it necessarily often throws up its hands, but that's as it has to be, given the variables involved. As one of the App ADs who sent this back to have this stuff fleshed out, this is a big "Thanks!" for the good work on the internationalization text. I know it wasn't easy. Thanks also for addressing my list of comments. Only two remain, and they are non-blocking: -- Section 8.8.1 -- o All file system instances servers should be considered as of different readdir classes. I can't parse "file system instances servers". I see that you removed the word "servers" from the previous list item, so I guess it's just that. -- Section 18.1 -- Thanks for changing the policy specification to make it clear that it's Specification Required. It would be good if you would also provide some brief guidance to the designated expert as to what she should be considering in her review. Should the expert *only* consider whether the specification is suitable to build interoperable implementations from? Should the expert also consider the merits of what is being proposed? It's worth bring explicit about that, and, if the latter, to say something about when it might be appropriate -- and when not -- to deny a request or to send it back for re-work.
Please remember that I'm not smart about NFS, but I did have some questions. Please consider them along with the other feedback you've collected. And telling me I don't understand NFS could be a fine response ... In this text: o The user or group may be returned or used for verification in a different form, as a result of Unicode normalization at the server. The result SHOULD be a canonically equivalent Unicode string [UNICODE]. Other sorts of string modification, including case mapping or folding, SHOULD NOT be done as such modifications ^^^^^^ ^^^ may cause the server to merge identities that are separate at the client. I lack understanding why violating this SHOULD NOT would be OK. If there's a reason why violating this SHOULD NOT would be OK, would that be a candidate to point out as a security consideration ("your server may hand objects that belong to you to anyone else with a similar user or group")? In this text: - In this particular case, we are pretty sure anyway that what has moved is /this/is/the/path rather than /this/is/the since we have the fsid of the latter and it is that of the pseudo-fs, which presumably cannot move. ^^^^^^^^^^ Is it possible for a pseudo-fs to move? (can you be pretty sure, but wrong?) In this text: Stateid values whose "other" field is either all zeros or all ones are reserved. They may not be assigned by the server but have ^^^ ^^^ special meanings defined by the protocol. Would that be a MUST NOT? I want to emphasize that my next comment is just from pattern matching, but what triggered it, was that the second bullet read strangely. In this text: o Otherwise, if the entity corresponding to the lock-owner (e.g., a process) sending the I/O has a byte-range lock stateid for the associated open file, then the byte-range lock stateid for that lock-owner and open file SHOULD be used. So, I'm reading this as one lock stateid for that lock-owner and open file. Is that right? In this text: o If there is no byte-range lock stateid, then the OPEN stateid for the current open-owner, and that OPEN stateid for the open file in question SHOULD be used. I'm reading this as two OPEN stateids, one for the current open-owner, and one for the open file. Is that right? If it is, I just tripped over a non-pattern that's not supposed to match. If it's not, the sentence sure makes it sound like there are. In this text: Since the sequence number is represented with an unsigned 32-bit integer, the arithmetic involved with the sequence number is mod 2^32. Note that when the seqid wraps, it SHOULD bypass zero and use ^^^^^^ one as the next seqid value. So, if this SHOULD is violated, what happens? In this text: In any event, the server is able to safely release state-owner state (in the sense that retransmitted requests will not be erroneously acted upon) when the state-owner no currently being utilized by the ^^^^^^^^^^^^^^^^^^^^^^^^^^^ client (i.e., there are no open files associated with an open-owner and no lock stateids associated with a lock-owner). I couldn't parse the sentence, starting where I indicated.
I am balloting No-Obj based on a "quick" read for any impacts on INT-related technologies. Given the amount of time that my quick read took, I fully support Stephen's suggestion of carving this beast up into more manageable specifications.
I agree with Kathleen's DISCUSS following up on the secdir review.
I want to thank David Black for an extensive review of this document, as well as the authors for working diligently through some of the points raised. The discussion is still ongoing, but I see Joel has already a Discuss raised to ensure that the resolutions get completed. Thank you. I am interested in the resolutions, but I do not plan to hold another Discuss for the same topic.
I can't say I truly understand the technology in G.711.0 (let alone G.711), but I am still left to wonder why section 3 is in this document. I would expect any implementer is going to have to read the G.711 specs anyway in order to produce the data, and section 3 just seems to repeat information you could get from there. Maybe there's something in section 3.3.1 which adds something specific to RTP, but otherwise, I don't understand. Can this be deleted? (Nobody ever wants to delete things from documents.) Throughout: I always find the "we" language jarring. "We" in this case is the WG, and that just comes out sounding bizzarre. Instead of "we note", use "note that". Instead of "In this section we describe", say "This section describes". Etc. Please change this. 3.3: Hiding a MUST inside a figure is a really bad idea. Luckily, the MUST is useless. Change "MUST be" to "is" and you're fine. 3.3.1: Change "MUST be supported" to "are always supported". Except for the one in section 5.3, you really should change all "MAY"s to "can"s. The one is section 4.2.1 and the one at the end of section 4.2.2 are harmless but useless. The one at the beginning of 4.2.2 is a bit more problematic: As written "MAY be any integer multiple of 5 ms" means that it also MAY be 23 ms (because having it be a multiple of 5 ms is OPTIONAL). If you want this to be a requirement, perhaps you mean, "MUST be any integer multiple of 5 ms", but I think "can" is correct. The one at the end of 4.2.4 cracks me up. Speaking of which: 4.2.4: When SDP is used, the number of channels is known because the optional parameter is a MUST when there is more than one channel negotiated (see Section 5.1). Additionally, when SDP is used the parameter ptime is a RECOMMENDED optional parameter. OK, I have to say, using MUST as a noun would be pretty funny by itself, but also getting in a "RECOMMENDED optional parameter" is just adorable! :-D Do you simply mean the following?: When SDP is used, the number of channels is known because the channels parameter is always present when there is more than one channel negotiated (see Section 5.1). Additionally, when SDP is used the parameter ptime is normally present. I think that's simpler and clearer.
Joel holds a DISCUSS for the OPS-DIR review.
Hello, Thanks for your work on this draft. The SecDir review turned up a few important considerations that I'd like to discuss. Here is a link to the review (includes nits and grammar that you should look at as well in addition to the points I'll pull out below): https://www.ietf.org/mail-archive/web/secdir/current/msg05189.html It seems there should be a reference to RFC 6562 (Guidelines for the Use of Variable Bit Rate Audio with Secure RTP) in the Security Considerations section, can that be added or is there a reason to leave it out? The VBR security problems cited in RFC 6562 seem to apply to this draft and the mitigation techniques described in the draft don't seem to properly address those problems. For example, adding statistically variable padding to very small G.711.0 frames would not prevent recognition of a prerecorded message if the set of all possible messages is known. If the authors of this draft have not consulted an expert on the security issues raised by VBR, they should do so. In addition to this concern, there may be a buffer overrun vulnerability in the payload decoding algorithm described in section 4.2.3. The authors carefully ensure that the input buffer is not overrun but no similar protections for the output buffer are described. At least, the SecDir reviewer (& I) didn't see them. A buffer overrun of the output buffer would be a major flaw. If such a flaw is present, it would be best to correct this now. Please see their review for nits. Thanks.
= Section 5 = "The parameters defined here as a part of the media subtype registration for the G.711.0 codec." s/as/are/ (or is there some other word missing?) = Section 5.1 = s/values are "complaw=al" or "complaw=mu" are used/values "complaw=al" or "complaw=mu" are used/
Holding a discuss for the resolution of the genart / opsdir dicussion. http://www.ietf.org/mail-archive/web/gen-art/current/msg10824.html I expect a rev or an rfc editor note, or a line from the participants that this is now copacetic. thanks
I support the changes Alissa has proposed to address the privacy concerns she raised.
I support Alissa's concerns on privacy.
- This is not a blocking DISCUSS as it may be a feature request but I'd really like to chat about it. In 2.4 you say that the username can be omitted or be anonymous and that other protocols can support that which is fine. But shouldn't you also consider that sometimes (parts of) the realm part might also be sensitive and handled similarly? E.g. if the "real" NAI was "email@example.com" then (assuming example.org is sufficient for routing) wouldn't it be nice if "@example.org" or "@anonymous.example.org" could be sent as the visible NAI with the full NAI being protected elsewhere in the protocol? For example replacing the string sensitive in that NAI with the name of a disease or counselling service might be a real use case. Did the WG discuss this possibility? (Note: I'm not trying to insist that this be done, I'd just like to chat about it since it could be easy enough to allow for here even recognising that it might not be possible in some important use-cases if the "protected" other protocol field is only expected to contain the username part of the NAI.) - I agree with Barry's discuss and Aliss's concerns and would like to see the follow up discussion on that and suspect that involving the WG in that discussion would be good. Even if the document is perhaps not "pushing" the idea of using the same identifier everywhere, I do think that an analysis of the impacts of doing so, and of how to usefully not do so, should be done, whether or not all of that analysis output is needed in this document. That is, I could buy the concept that the WG might take on the task of analysing the consequences of (not)reuse of NAIs in multiple contexts in a separate document, if the WG would really do that in a timely manner. And if the WG waned to do that, then some simple qualifiers added here and there might be sufficient to handle Barry and Alissa's points. - Generally, I'd prefer if the term "identifier" was used throughout, and the term "identity" was never used, or only very carefully. The abstract does not do that IMO. Other text seems pretty good though but I didn't check fully. - Intro: " We suggest that this re-use is good practice." needs a qualifier to handle the privacy issues. (Recommending the format is fine, which goes to Alissa's discuss.) - 1.3: Same point: "as there is no need to maintain multiple identifiers for one user" needs a qualifier. - 1.3, 2nd last sentence: do you mean sybil attacks here or something else? If the former saying so would be good (or adding a ref), if the latter can you tell me what you mean? - 2.4, last para: saying "is typically required" seems a bit weak, I wonder why you cannot require that the realm part be routable or some such?
Thanks for writing this document. It was and is badly needed, and as noted, roaming, network access authentication, and the use of NAIs is growing and there is an obvious need to make sure internationalised identifiers in particular work correctly. And as we understand now, RFC 4282 indeed didn't provide a satisfactory answer on that issue. However, I have a couple observations of the text in the comment section and one question that I would like to discuss before recommending an approval of this draft. The question: I noticed the change from 4282 in terms of the bang syntax. This isn't my favourite syntax, but conditions for its use were specified in 4282. As far as I can see, the same conditions still exist in the draft, but the draft adds that the usage is NOT RECOMMENDED, and adds some rationale for this. Stating that the usage is historical. The draft also removes the processing rules from what they were in 4282: In this case, the part before the (non-escaped) '!' MUST be a realm name as defined in the ABNF in Section 2.1. This realm name is an "IDN-unaware domain name slot", just like the realm name after the "@" character; see Section 2.4 for details. When receiving such an NAI, the other realm MUST convert the format back to "firstname.lastname@example.org" when passing the NAI forward, as well as applying appropriate AAA routing for the transaction. I have two questions related to this. First, has the WG been aware of existing, not historical usage, of this syntax? Quick search reveals that 3GPP networks use a routing convention with the syntax, see http://www.3gpp.org/DynaReport/23003.htm and http://www.qtc.jp/3GPP/Specs/24302-a70.pdf (note that I'm not the expert on these types of usage and there might be additional examples, or the experts might understand the situation better than what we can gain merely by looking at the existing specs). Also, RFC 5729 discusses the use of decorated NAIs in Diameter context. In any case, I think the WG should be aware of existing realities of deployed usage. Secondly, does that usage change any of your recommendations? Perhaps one could argue that when you understand your situation and have good justification, you can go against a SHOULD or RECOMMEND. Or perhaps one could argue that specific conventions (such as the 3GPP usage) where the routing table distribution is not an issue are safe. And finally, it seems that deprecating processing rules (regardless of the recommendation about general use of decoration) seems problematic if there are existing systems that rely on this. Thoughts?
Section 1.4: * [RFC4282] Section 2.4 required mappings that are language-specific, and which are nearly impossible for intermediate nodes to perform correctly without information about that language. Section 2.6: In contrast to [RFC4282] Section 2.4, we expect AAA systems to perform NAI comparisons, matching, and AAA routing based on the NAI as it is received. This specification provides a canonical representation, ensures that intermediate AAA systems such as proxies are not required to perform translations, and can be expected to work through AAA systems that are unaware of international character sets. Not that it matters greatly, but the characterisation of 4282 procedure seems incorrect. Again, it is clear that we need a better specification for the internationalised identifiers in NAIs, but RFC 4282 does say: The mapping, normalization, and bidirectional character processing MUST be performed by end systems that take international text as input. In a network access setting, such systems are typically the client and the Authentication, Authorization, and Accounting (AAA) server. NAIs are sent over the wire in their canonical form, and tasks such as normalization do not typically need to be performed by nodes that just pass NAIs around or receive them from the network. The real issue isn't that 4282 required intermediate systems to do translations - it didn't - but rather that the reality of the existing EAP and other clients is that they put (local) blobs of text into the protocol payloads and did NOT do anything at the end systems. Which your draft correctly notes in Section 2.6.1. Which made the translate-to-ascii approach of 4282 unworkable, and the approach in the current draft more workable. Section 2.6.1: These limitations have the following theoretical and practical implications. * edge systems used today generally do not normalize the NAI * Therefore AAA systems SHOUD attempt to normalize the NAI The suggestion in the above sentence contradicts the suggestion in the previous section. This is the reality of imperfect protocols. Where the user identifier can be normalized, or determined to be in normal form, the normal form MUST be used as the NAI. In all other circumstances, the user identifier MUST NOT be treated as an NAI. That data is still, however, a user identifier. AAA systems MUST NOT fail authentication simply because the user identifier is not an NAI. That is, when the realm portion of the NAI is not recognized by an AAA server, it SHOULD try to normalize the NAI into NFC form. That normalized form can then be used to see if the realm matches a known realm. If no match is found, the original form of the NAI SHOULD be used in all subsequent processing. I'm trying to read the draft but I cannot find where it says explicitly what to do when an AAA system (such as a NAS or a proxy) performs such normalisation. Are the results of the normalisation only used locally, such as for routing? Or is the normalised result somehow passed onwards (such as when passing the RADIUS request to the next entity)? I think you mean the former but I'd like to be sure. Other comments: I agree with Alissa's comment on distinctions between format and identifier. I agree with, to the extent that I understand them :-) with Pete's comments on internationalised names. I partially disagree with Stephen's suggestion to consider hiding realm portions in addition to user names. It is useful functionality, and to the extent that it can be supported by existing mechanisms (like omitting the sensitive part, or using the bang syntax in some manner) it should be noted. But this RFC-to-be is for describing very widely deployed functionality, and I wouldn't like to see additional requirements for intermediate RADIUS nodes as they quite simply are not implemented today, and hence it would be difficult to use them.
1.4: OLD The intent appears to have been to encode, compare, and transport realms with the ToASCII operation defined in [RFC5890]. RFC5890 does not define ToASCII. ToAscii is defined in 3490, which you really don't want to refer to. See section 2.3.4 of 5890. Instead try this: NEW The intent appears to have been to encode, compare, and transport realms by converting them to the Punycode [RFC3492] encoding form as described in [RFC5891]. 2.5: Internationalization of the realm portion of the NAI is based on "Internationalized Email Headers" [RFC5335]. First of all, 5335 has been obsoleted by 6532, so you should use the updated reference if you need it. However, I have no idea why you'd use that for the *realm*. A reference to 5890 and/or 5891 should be completely sufficient for the realm portion. Conversely: In order to ensure a canonical representation, characters of the username portion in an NAI MUST match the ABNF in this specification as well as the requirements specified in [RFC5891]. The username needn't follow 5891, does it? Do you have the username and realm reversed here? If you meant to base the username on 6532, perhaps what you want to say is: Internationalization of the username portion of the NAI is based on the "Internet Message Format" [RFC5322] "dot-atom" form of the "local-part" portion of an email address, as extended by "Internationalized Email Headers" [RFC6532] to allow for UTF-8 characters. In order to ensure a canonical representation, characters of the realm portion in an NAI MUST match the ABNF in this specification as well as the requirements specified in [RFC5891]. Is that what you had in mind? Then down in 3.1, you can change the first two paragraphs as follows: As proposed in this document, the Network Access Identifier is of the form "user@realm". Please note that while the user portion of the NAI is based on the "Internet Message Format" [RFC5322] "local-part" portion of an email address as extended by "Internationalized Email Headers" [RFC6532], it has been modified for the purposes of Section 2.2. It does not permit quoted text along with "folding" or "non-folding" whitespace that is commonly used in email addresses. As such, the NAI is not necessarily equivalent to usernames used in e-mail. However, it is a common practice to use email addresses as user identifiers in AAA systems. The ABNF in Section 2.2 is defined to be close to the "addr-spec" portion of [RFC5322] as extended by [RFC6532], while still being compatible with [RFC4282]. I have no idea why you wanted to reference 5198. 3.2: The ToAscii problem. OLD There is therefore no reason for a NAS to apply the ToAscii function to the "utf8-realm" portion of an NAI, prior to placing the NAI into a RADIUS User-Name attribute. NEW There is therefore no reason for a NAS to convert the "utf8-realm" portion of an NAI into Punycode encoding form [RFC3492] prior to placing the NAI into a RADIUS User-Name attribute. OLD When the realm portion of the NAI is used as the basis for name resolution, it may be necessary to convert internationalized realm names to ASCII using the ToASCII operation defined in [RFC5890]. As noted in [RFC6055] Section 2, resolver Application Programming Interfaces (APIs) are not necessarily DNS-specific, so that the ToASCII operation needs to be applied carefully: NEW When the realm portion of the NAI is used as the basis for name resolution, it may be necessary to convert internationalized realm names to Punycode [RFC3492] encoding form as described in [RFC5891]. As noted in [RFC6055] Section 2, resolver Application Programming Interfaces (APIs) are not necessarily DNS-specific, so conversion to Punycode needs to be done carefully: 3.4: Same problem as above: OLD One example given in [RFC4282] is still permitted by the ABNF, but it is NOT RECOMMMENDED because of the use of the ToAscii function to create an ASCII encoding from what is now a valid UTF-8 string. NEW One example given in [RFC4282] is still permitted by the ABNF, but it is NOT RECOMMMENDED because of the use of the Punycode [RFC3492] encoding form for what is now a valid UTF-8 string.
Throughout (and this is the second document this week): I always find the "we" language jarring. "We" in this case is the WG, and that just comes out sounding bizzarre. Instead of "We suggest", say "This document suggests". Instead of "we note", use "note that". Etc. Please change this. 1.3 (and similarly in 2.7): Non-AAA systems MAY accept user identifiers in forms other than the NAI. s/MAY/can in both places. This is not specifying a protocol option. It's stating a fact.
Thank you for including an explanation of what is intended by inter-domain authentication per my previous discuss point. I think this will be helpful to the reader. I also appreciate the language updates to get rid of the term identity and replace it with identifier as well as you using the suggestions I provided for the NAI definition. The changes do help, thank you. I support Barry's discuss on privacy concerns and appreciate the text you provided to address this concern.
Thanks for addressing my comments in version -12. -- Sections 2.6 and 2.6.1 -- Good work on these sections. This is difficult stuff, and I think you've handled it well -- at least, in the best way you can. My favourite bit it this one, which is absolutely true: The suggestion in the above sentence contradicts the suggestion in the previous section. This is the reality of imperfect protocols. Thanks for making that reality clear.
I have no problem with the publication of this document, but I do have a few points for you to consider. 1. The references contain RFC 5335. However, 5335 has been obsoleted by RFC 6532. 2. Can you drop the "hope" from section 1.3 and make a more definitive statement about the use of this document? Additionally, most of 1.3 does not read like the Purpose of this document. Can it be tightened up by removing some of the nebulous text on AAA and non-AAA systems and focus on the NAI itself?
= General = This document seems to confuse an identifier format with an identifier, and I'd like to discuss that. In my reading, all this document specifies is an identifier format and length, plus some processing rules for use by AAA systems. It does not specify the particular contents of the identifier for any specific protocol or usage, nor does it specify any semantic rules for the construction of such identifiers (e.g., "the same user should always use the same identifier"). However, the document repeatedly makes the case -- in sections 1, 1.3, 2.1, 2.7, 2.8 -- that "the NAI" (whether the actual identifier or the format, it's not clear) should be the universal identifier of choice for all situations and protocols, because it "simplifie[s] the management of credentials," allows other protocols to "leverage AAA for user authentication," removes the need to "maintain multiple identifiers for one user," etc. The claims in all of these sections seem to conflate a single user's use of the same identifier with a single user's use of the same identifier *format*. I thought what is being defined in this document is a format and nothing more. I'm perfectly fine with encouraging the use of a standard format across protocols and applications (although I still don't see the need to repeat the same recommendation over and over again in the document). That has basically happened already in lots of places. I'm not fine at all with a blanket recommendation to use a single identifier for the same user everywhere. The ability to authenticate to different services (and even to different networks!) using different identities is a fundamental building block for privacy on the Internet. The message from this document seems to be that we should erase that protection. I note that although the stated motivation for this document relates to internationalization, pretty much all of the text recommending One Identifier to Rule Them All is new. So perhaps there were multiple motivations for this document update? I could offer a bunch of detailed text suggestions, but first I'd like to understand what this document is actually trying to do, and whether the term "the NAI" is meant to refer to an identifier or an identifier format. = Section 2.4 = "Therefore, the utf8-username portion SHOULD be treated as opaque data when processed by nodes that are not a part of the authoritative domain (in the sense of Section 4) for that realm." What does it mean to treat a cleartext username as opaque data? Should the nodes outside the realm not log these usernames, or not process them in any way? "Omitting the username part is RECOMMENDED over using a fixed username part, such as "anonymous", since it provides an unambiguous way to determine whether the username is intended to uniquely identify a single user." I don't understand why this is true, other than by convention. If I process a bunch of authentication transactions that use "@example.com" as the NAI, how am I supposed to know that each of those was intended to identify a single user? Is the usage of an NAI to authenticate a group of users discussed somewhere? In general, I'm uncomfortable with the approach this document takes of making a few notes about how the username part could be constructed without providing a more thorough analysis of threats and mitigations related to identifiability, uniqueness and persistence. This also comes up with the example in Section 2.8, where uniqueness is discussed in the context of the example, but there is no generalized discussion about uniqueness in identifier construction. This might get back to my larger point above about format versus content -- if this document is just specifying a format, it probably shouldn't be commenting on the identifier content or the consequences of it (although being able to omit the username part is certainly a format issue).
= Section 1 = Is dial-up really a prevalent use case to be highlighting first here? If we're going to obsolete an old document, it's worth making it current. Similarly, I wonder how current this text is in Section 1.3? "As described in [RFC2194], there are a number of providers offering network access services, and the number of Internet Service Providers involved in roaming consortia is increasing rapidly."
imho I think the hope statements are ok. and I can live with draft 12 ------ opsdir review of 11 (by Mehmet Ersue) for the record. I have reviewed the document "The Network Access Identifier" (draft-ietf-radext-nai-11.txt) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Intended status: Standards Track Obsoletes: RFC 4282 Current draft status: Submitted to IESG for Publication Summary: The document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing resources. This document obsoletes RFC 4282. I would suggest to change: "In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server." as "Concerning the support of roaming capability, one of the requirements is the ability to identify the user's home authentication server." It is praiseworthy that the draft includes a section on the administration of names, which however has been kept short and handles NAI realm namespace piggybacks, NAI realm name uniqueness and the location of the authentication server. I agree with Brian Haberman who asks to drop the "hope" from section 1.3 making a more definitive statement about the use of the document. There are three occurrences of the verb hope, which should be rewritten in a more explicit manner. I don't see any other issues from the operations and management pov. There are some nits in the draft: The format of Table of Contents is wrong. It lists Appendix A before Introduction. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs -- Obsolete informational reference: RFC 5335 (Obsoleted by RFC 6532)
Adrian's and Pete's point is worth supporting.
Moving to a No Objection ballot. The authors and responsible AD say they will remove the text: c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by extending section 4 'IPP Standards' and section 10 'Security Considerations'. I trust them to do this.
Adrain's DISCUSS saves me from having to put one on. As discussed in email, choice (c) in the list of documents that this document updates is not appropriate. If the PWG wants to say in one of their documents that PWG5100.12 is updated by this IETF document, that's their business. But *we* can't say in *our* document that we're updating their document. If you need a note, it could say: Note: IEEE-ISTO PWG has indicated that they intend to use this document as an update to their IPP Version 2.0 Second Edition [PWG5100.12], by extending section 4 'IPP Standards' and section 10 'Security Considerations'. But either way, (c) should go. 1.2: Does this document intend to deprecate use of 2817? Should we be moving 2817 to Historic? 4.3: Per PWG IPP Everywhere [PWG5100.14], for compatibility with existing IPP implementations, IPP Clients and IPP Printers MUST accept explicit port 443 (assigned in the 'https' URI scheme [RFC7230]) in 'ipps' URI values. An IPP Client MUST accept 443, but can reject other port numbers? That seems bogus. Are you really simply saying that IPP Printers MUST listen on port 443 in addition to any other ports it might want to use? I don't understand this instruction.
Resolutions of the Gen-ART review issues still need to be done. I expect the AD in charge will handle this.
""" - basically the IPP Client can send its whole Print-Job request before the IPP Printer has a chance to respond and say, "Wait! You need to encrypt first!" """ My favorite sentence of all the docs this telechat :) Thanks!
Thanks for your work on this draft. The Security considerations look good, I just have a few comments that I'd like you to consider as updates, although this is non-blocking. Section 6.1.1, bullet d, theft of the data is more of a concern, so listing both of these within this bullet should satisfy that request. How about the following: d) The print document content itself (for example, theft of the data or to corrupt the documents being transferred). This would be to the print spooler for theft before it is sent in an encrypted stream, which seems to fit in with the description for this section. Section 6.3 Implementers will likely find it helpful to have a reference to the BCP on TLS best practices that is in WG last call now. An informal reference would not hold up this draft. https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
I agree with Adrian and Pete about the wording on updating IEEE specifications. I'd support the text Pete suggested. I had one comment on this otherwise lovely draft: In this text: 2) Some existing IPP Client and IPP Printer implementations of HTTP Upgrade [RFC2817] do not perform upgrade at the beginning of every HTTP [RFC7230] connection, but instead only shift to secure IPP for selected IPP operations (inherently dangerous behavior on the same underlying TCP [STD7] connection). STD7 isn't TCP in any meaningful way, because the vast majority of TCP functionality hasn't advanced to full Internet Standard status, and we can't add Proposed Standards to an STD number until they advance to Internet Standards. STD7 doesn't even include Slow Start. The best reference I can offer is https://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-08, currently in the RFC Editor's queue. You have STD7 as a normative reference, but I'd expect the TCPM doc to pop out first. STD7 also appears in 6.1.2 and in a couple of other places, but it looks like the other places are in sections slated for removal.
comments from the opsdir reviewer. I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready Reviewer's Notes: It took me a while to perform this review because I first had to read-up on IPP, which is a fair amount of text... But I found this draft and the related IPP documents to be well written. Cheers, -Benson
I am glad for the existence of this document. Thanks for taking the time to write it. Alissa's first comment needs to be addressed.
(Apologies, I only had time to skim this one, so my comments might be a bit off the mark - feel free to tell me I'm being dumb if so:-) - The IPR declaration says licensing is to be provided "later" though a note in fact does seem to contain a (nice) set of terms. Might be good to fix? - Could conex signals be used as part of an oracle attack? I'm not sure they could but has someone thought about that? If not, and if there were a way in which to abuse conex along those lines then it could be that stating a requirement that specific protocols consider this would be a good idea. Note that I'm not sure if a feasible way to use conex in such an attack exists. If it did, a simple countermeasure might be to just not allow for very fine-grained signals. - It'd be good if the security considerations here considered how more and more use of ciphertext might affect conex, in particular for the proxy or audit functionality. For example, is there any interplay with what tcpinc is likely to produce?
Thanks for your response and agreed changes per the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg05057.html The draft looks good, thanks for your work on it and the detail level for security requirements like the specific requirements to protect against several attacks that may lead to a DoS in section 3.2 Audit. I found the first paragraph of 5.4 helpful to better understand what was intended by the term audit and think it would have been good to have that understanding a little earlier in the draft. I was looking for possible security concerns that don't apply once I read this definition.
I submit that a good number of the references really are normative, in that understanding them is necessary in order to understand this document. I'd like to see the authors sort that out, and make an appropriate split in the references, so readers can know which ones truly do just add extra detail (informative), and which provide necessary background (normative). That said, I don't consider that important enough to this document to block on it, so this is a non-blocking comment. Please consider doing this, but there is no need to respond to me about it. Thanks.
= Section 2 = "This document extends the capabilities of the Internet protocol suite with the addition of a new Congestion Exposure signal." This document doesn't do that, right? Maybe one of the standards-track conex documents will, but this document does not directly affect the Internet protocol suite. "ConEx represents a recognition that the IETF cannot regulate this space directly because it concerns the behaviour of users and applications, not individual transport protocols." I'm not sure what "ConEx represents" means here, but no matter which way I interpret it I have a hard time getting to the conclusion that this sentence makes. I would recommend that this sentence and the one that follows it focus on the implications of the abstract mechanism described in this document, rather than on what the IETF does or does not do. = Section 4.4 = "As long as the packets in a flow have uniform sizes, it does not matter whether the units of congestion are packets or bytes. However, if an application sends very irregular packet sizes, it may be necessary for the sender to mark multiple packets to avoid being in technical violation of an audit function measuring in bytes (see Section 4.6)." This makes me wonder how the sender is supposed to know whether an audit function at any given point on the network is counting in bytes or in packets, or what happens if the same packet/sender encounters audit functions on two different networks (in a single path, or in a multi-homed sender scenario) that count using different units. The requirement in Section 4.6 that the encoding scheme specify its assumption about units isn't sufficient, because packets that use the scheme could encounter an audit function that makes the opposite assumption. Is this addressed somewhere?
I tend to agree with Pete's concerns about marketing fluff in the document, but I think the core message of the document is worth stating. It would be nice if some of the fluff Pete is complaining about could be removed, but I'm not going to insist on it.
I have no objection to the publication of this document although a few editorial nits are revealed by idnits.
In the end, I'm not going to stand in the way of this document if there is consensus on its content; it is just Informational. But on our agenda, we are specifically asked regarding Informational documents: "Is this document a reasonable contribution to the area of Internet engineering which it covers?" And I'd like to take a moment to DISCUSS that question. There's a significant amount of the discussion of the ISP Use Case that contains a lot of fluff about business and operational models that I think probably doesn't belong in an IETF document, though it's nothing out of hand. But I'm having some real trouble with some of the discussion on the Regulator Use Case. Some examples: 2.2 Regulator Use Case Regulators in jurisdictions around the world are responding to consumers' adoption of Internet access services for traditional telecommunications and media services by promoting competition among providers of electronic communications, to ensure that users derive maximum benefit in terms of choice, price, and quality. Competition is more effective with better information, so some regulators have developed large-scale measurement programs. For example, programs such as the U.S. Federal Communications Commission's (FCC) Measuring Broadband America (MBA)... 4.1 Promoting competition through transparency Competition plays a vital role in regulation of the electronic communications markets. For competition to successfully discipline operators' behavior in the interests of their customers, end users must be fully aware of the characteristics of the ISPs' access offers. In some jurisdictions regulators mandate that transparent information imade available about service offers. [...] 4.2 Promoting broadband deployment Governments sometimes set strategic goals for high-speed broadband penetration as an important component of the economic, cultural and social development of the society. To evaluate the effect of the stimulated growth over time, broadband Internet access take-up and penetration of high-speed access can be monitored through measurement campaigns. An example of such an initiative is the "Digital Agenda for Europe"... It seems completely inappropriate for an Internet *Engineering* Task Force Working Group to be making proclamations about economic competition and the merits (and no notable demerits!) thereof, talking about competitions's "vital role in the regulation of electronic communications markets", and touting programs for "economic, cultural and social development of the society." I think it's a bit unseemly, and at some level (and certainly for folks from different cultures) potentially offensive. (And I haven't mentioned the whole net neutrality discussion that Alissa points out.) Is this really appropriate material for an IETF consensus document? I can see it as an IAB document, I can see it as an independent submission, but as an IETF WG document? I'd really like to hear other IESG members' opinions on this. As I said, in the end I won't stand in the way, but before I ABSTAIN, I'd like to hear what others think.
- I do think that this kind of document is useful in this case and am fine that it becomes an RFC. - I agree with the comments about the language in the regulator section in particular. - 3.5: I'd be interested in a reference to back up that 80% figure if there's a good one. - 3.5: The on-demand test that the call centre runs sounds dangerous to me unless at least accompanied by a s/w update for the CPE - how do you avoid leaving bad holes open otherwise? - section 5: I think the list at the end should acknowledge that a measurement system might itself include vulnerabilities that put the user's home network at risk, e.g. if it required opening a port on the CPE or if someone could spoof the server-side of the measurement system and the home-side had a buffer overrun. - section 6: I'm wondering if it's really wise to include both measurement and troubleshooting capabilities in the same thing. I see the attraction but the latter may have more onerous security requirements that would tend not to be met by implementations of the former. - section 7, point 4: Would it be worth noting that the pattern of times for measurements could leak information about the user's presence/activity at home? E.g. if measurements are normally taken mostly at night but for two weeks in august happen precisely every hour all day long, then I could conclude the person at that location is on vacation. - section 7: "informed consent" - hmm, I wonder what that really means but I like that you recognise the issue and particularly the secondary uses problem. - section 7 (or section 6): I think it would be good to say here that LMAP protocols really do need signiicant analysis of privacy considerations and it's likely that those ought end up being explicitly documented in the relevant specifications.
The draft is well written and easy to read, thank you for that. I just have one concerns I'd like to chat about: Section 3.1, second to last paragraph This discusses the probes nicely in terms of privacy concerns, but leaves out the security concerns that have resulted in any type of probe traffic being blocked in the past. If you are going to leave the privacy concerns in this section, you should also have the security concerns with network mapping and the ability to use this information to assess open ports as well as path information that could be used in the first case to attack/compromise a host or for denial of service attacks for the first and second case. Path information is mentioned in 3.3, so perhaps the DoS mention would be better there and the general security along with the privacy in section 3.1. Later section 5 mentioned the use of an app to gather information from the end user as opposed to their gateway. Security and privacy considerations should be mentioned here as well since they differ from the the probe scenario. I would not recommend going in depth on this topic as this is just the use case document, but rather mentioning it. It would be out-of-scope to get to deep into application security and protections from compromise or the ability to gather privacy information about the user patterns. A high level statement of those concerns is enough (IMO) and can get addressed in the solution documents. Apps and desktop tools can be directly associated with a user as opposed to a home and can lead to desktop compromise, so this is different than the previously mentioned privacy concerns in section 3. I am aware that these types of services are available today via web pages and is up to the user to initiate. Section 7 First bullet I'd keep DoS attacks restricted to the degradation of service and have the points on privacy and business confidentiality listed separately as merging them confusing the points and attack vectors. Both can potentially use information gathered from the probes or the actual management station itself, but in different ways, this isn't clear from the bullet. The DoS could be launched directly from the management station or information about the network and path to hosts could be used to launch a targeted DoS attack. The accuracy of the measurement system mentioned in the last part of the bullet makes sense combined with the Dos Attack. For privacy, you could collect patterns of use to understand user behavior (already in bullet 2). Additionally, one could use the information gathered from probes to determine open ports and potential vulnerabilities that could be used to compromise the end point (security concern). For business confidentiality, I'm not sure what you mean here. Is this referring to an ability to gather endpoint information to monitor along paths for a business? I would assume that the probe traffic will be designed to include innocuous information and will just be used for measurement data. It looks as is the SecDir reviewer had similar concerns with the connections between points made in bullet one, so it would be good to fix this and I hope my above explanation is enough to help you adjust the text and add the additional considerations. I'm happy to help with the text if needed. The suggested text to the SecDir review is helpful, but would need to change to address the additional concerns I raised (thanks for your work on that with Hannes!). http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security The SecDir review had a few other good points for bullet 6 that you have addressed with proposed text and your proposed text is included here for tracking purposes: Part of Hannes' request: * prevent unauthorized access to collected measurement data, * give users the ability to view collected data, * give users the ability to exert control over sharing, and * enforce retention periods. ** Editor's proposed text on all points for bullet 6: 6. a measurement system that does not indicate who is responsible for the collection and processing of personal data and who is responsible for fulfilling the rights of users. The responsible party (often termed the "data controller") should, as good practice, consider issues such as defining:- the purpose for which the data is collected and used; how the data is stored, accessed, and processed; how long it is retained for; and how the end user can view, update, and even delete their personal data. If anonymised personal data is shared with a third party, the data controller should consider the possibility that the third party can de-anonymise it by combining it with other information.
Like my commentary on "requirements documents", I don't see the value in publishing use cases as standalone RFCs. I would rather see these maintained in a wiki or living I-D and either not published or published as an appendix to the corresponding protocol specification. That being said, I will not stand in the way of this document.
= Section 4.3 = I would recommend removing or re-wording some bits of language from this section that aren't strictly necessary and could be contentious or turn the reader off. The following seems like it could be deleted (especially since some of the relevant bits of the R&O, relating to transparency, have not been overturned): "such as the court action negating the FCC R&O" Similarly, I would suggest the following: OLD Net neutrality regulations do not necessarily require every packet to be treated equally. Typically they allow "reasonable" traffic management (for example if there is exceptional congestion) and allow "specialized services" in parallel to, but separate from, ordinary Internet access (for example for facilities-based IPTV). A regulator may want to monitor such practices as input to the regulatory evaluation. However, these concepts are evolving and differ across jurisdictions, so measurement results should be assessed with caution. A regulator could monitor departures from application agnosticism such as blocking or throttling of traffic from specific applications, and preferential treatment of specific applications. A measurement system could send, or passively monitor, application-specific traffic and then measure in detail the transfer of the different packets. Whilst it is relatively easy to measure port blocking, it is a research topic how to detect other types of differentiated treatment. The paper, "Glasnost: Enabling End Users to Detect Traffic Differentiation" [M-Labs NSDI 2010] and follow-on tool "Glasnost" [Glasnost] are examples of work in this area. NEW A regulator may want to monitor traffic management practices or compare the performance of Internet service with services offered in parallel to but separate from Internet access (for example IPTV). A regulator could monitor departures from application agnosticism such as blocking or throttling of traffic from specific applications, and preferential treatment of specific applications. A measurement system could send, or passively monitor, application-specific traffic and then measure in detail the transfer of the different packets. Whilst it is relatively easy to measure port blocking, it is a research topic how to detect other types of differentiated treatment. The paper, "Glasnost: Enabling End Users to Detect Traffic Differentiation" [M-Labs NSDI 2010] and follow-on tool "Glasnost" [Glasnost] are examples of work in this area.
The text in 3.1 about sample size seems poorly justified. should be genericised, I think and would hopefully never be interpreted literally. "The understanding can be gained through a "panel", i.e. measurement probes deployed to a few 100 or 1000 customers. The panel needs to include a representative sample for each of the operator's technologies (fiber, Hybrid Fibre-coaxial (HFC), DSL...) and broadband speeds (80Mb/s, 20Mb/s, basic...). For reasonable statistical validity, approximately 100 probes are needed for each ISP product."
o Management protocols such as NetConf, SNMPv3, and CORBA. Please spell NETCONF right. And references would be welcome.
A couple of minor, non-blocking comments that I hope you'll consider: -- Section 2 -- As RFC 6163 is used to define necessary terminology, I think it's a normative reference. -- Section 3 -- I found the first paragraph here to be confusing: one thing can't be grouped into multiple categories, and "regardless" seems not the right word. Also, the sentence (ending in ":") that introduces the list doesn't have anything to do with the list it introduces. May I propose this instead, and let you fix it if I don't have it quite right?: OLD The WSON RWA information model in this document is grouped into four categories regardless of whether they stem from a switching subsystem or from a line subsystem. A switching subsystem refers to WSON nodes such as ROADM or Optical Add/Drop Multiplexer (OADM) and a line subsystem refers to devices such as WDM or Optical Amplifier: NEW The WSON RWA information model in this document comprises four categories of information. The categories are independent of whether the information comes from a switching subsystem or from a line subsystem -- a switching subsystem refers to WSON nodes such as ROADM or Optical Add/Drop Multiplexer (OADM), and a line subsystem refers to devices such as WDM or Optical Amplifier. The categories are these: END
In Sec 4.4, the basic settings for Maximum TCP Window Size and MTU are not given. If there isn't a recommended value, saying so would be good.
Thanks for addressing Terry's Routing Directorate review. --- I liked the understatement of BGP is ... used by several service providers as the default Inter AS routing protocol. Several == "more than two but not many" Perhaps you could s/several/many/
Shouldn't the conclusions from the discussion after the Gen-ART review be incorporated to a new draft version?
As notes by Scott Bradner in his OPS directorate review. Some comments/questions on the contents of the draft: 1.1 "FIB (Data plane) convergence is defined as the completion of all FIB changes so that all forwarded traffic now takes the new proposed route. " should route be singular or plural - i.e. is the assumption that the routing table converges to a single next hop? (at least for the test traffic) if so, does the draft specifically say that (or does rfc 4098 and I missed it) note: figure 1 shows multiple peering links - sec 4.1 seems to argue for multiple peers "Data plane convergence is different than control plane convergence within a node." might want to say how they are different since reporting requiremenst are covered in section 6 should they also be mentioned here? (if so, how about in section 4.2) secton 4.4 & 4.8 maybe replace TCP MD5 with TCP Authentication Option (2 places) or at least mention it section 4.4 basic test settings - maybe say why these values were chosen section 4.7 agree as to the importance fo rrepeating trials - is there a recognized source that discusses "generally accepted testing practices regarding repeatability ..."? section 5 what about Graceful Restart (RFC 4724) - would that impact the clean start desire? section 5.1.1 "D. Start the traffic from the Emulator tx towards the DUT targeted at a routes specified in route mixture (ex. routeA)" change "a routes" to "a route" or "the routes" E & F - as noted earlier in the document - these times should be very close to the same - is it actually worth the additional complexity to collect the time when the update is received? also 5.1.2 H & I, etc section 5.1.2 mentions NTP but section 5.1.1 does not - is there a reason? section 5.2.1 - since the shutdown event is not timed - does this test provide a useful measurement? (or should the time be recorded and its just not mentioned?) section 5.3 - F - implies that the time is recorded but not actually say say that it is general comment - review all steps of all tests to be sure that NTP is called for when it is needed and that event times are specifically called for when they are needed and use consistent langage in each case the overall requiremenst - e.g. NTP could also just be noted before the test descriptions and not inlcuded in each one if it is needed in all of them - same with advice about nukbers of routes (do tests with different numbers or routes up to the full Internet table) section 6 - should this also include the number of AS Paths?
Thanks for your work on this draft and the clear security considerations section.
So sorry... I posted comments about the wrong document here. Please ignore that last message.