Hi, Peter, Thanks so much for your thorough review. We have submitted a new 04 version to address your comments, as the link below. https://tools.ietf.org/html/draft-ietf-dhc-dhcp-privacy-04 Many thanks and best regards, Sheng >-----Original Message----- >From: Peter Yee [mailto:peter@xxxxxxxxxx] >Sent: Friday, February 05, 2016 6:02 PM >To: draft-ietf-dhc-dhcp-privacy.all@xxxxxxxx >Cc: gen-art@xxxxxxxx; ietf@xxxxxxxx >Subject: Gen-ART LC review of draft-ietf-dhc-dhcp-privacy-03 > >I am the assigned Gen-ART reviewer for this draft. The General Area Review >Team (Gen-ART) reviews all IETF documents being processed by the IESG for >the IETF Chair. Please treat these comments just like any other last call >comment. For background on Gen-ART, please see the FAQ at ><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> > >Document: draft-ietf-dhc-dhcp-privacy-03 >Reviewer: Peter Yee >Review Date: February 4, 2016 >IETF LC End Date: February 4, 2016 >IESG Telechat date: TBD > >Summary: This draft is basically ready for publication as an Informational >RFC, but has nits and a minor issue that should be fixed/considered before >publication. [Ready with issues] > >The draft describes privacy concerns arising from identifiers used in DHCP. >It doesn't not prescribe fixes for these concerns and the Security >Considerations are a little short. > >Major issues: None > >Minor issues: > >Page 9, section 5.6: the general concern with pervasive monitoring doesn't >necessarily arise from the operator but from an adversary who is able gather >information across a wide range of networks and develop correlations from >that information. In many cases, a user has no true expectation of privacy >from the user's operator (ISP) and this may well be delineated in the terms >of service. Consider beefing up this rather thin section. > >Nits: > >General: append a comma after each occurrence of "e.g." > >General: consider if you should use the term "DHCP" or "DHCPv4". They are >used somewhat interchangeably, but not consistently. RFC 2131 doesn't use >the term DHCPv4, obviously. > >General: idnits complains about the reference to RFC 2629. I don't know if >you care or if it needs to be cited in the document or acknowledgements. > >Page 2, section 1, 1st paragraph, 2nd sentence: delete "The" and "protocol". > >Page 3, section 1, 1st full paragraph, 2nd sentence: change "It is" to >"These changes are". > >Page 3, section 2, Stable identifier definition, 2nd sentence: delete "may". >Append a comma after "client-id". Change "or" to "and". > >Page 3, section 2, Stable identifier definition, 3rd sentence: change >"other" to "another". > >Page 3, section 2, Stable identifier definition, 4th sentence: change >"identifier" to "identifiers". > >Page 3, section 3, 1st paragraph, 1st sentence: change "which" to "that". >Insert "that" before "can be". Delete "the" before "identification". > >Page 3, section 3, 1st paragraph, 2nd sentence: insert "the" before >"identifiers". > >Page 3, section 3, 1st paragraph, 3rd sentence: change "would be" to "are". > >Page 4, section 3.1, 2nd paragraph, 6th sentence: change "document" to >"documents". > >Page 4, section 3.1, 2nd paragraph, 9th sentence: delete "a" before >"non-volatile". > >Page 4, section 3.1, 3rd paragraph, 2nd sentence: change "disabled" to "not >yet enabled". > >Page 4, section 3.1, 3rd paragraph, 3rd sentence: insert "the" before >"client". Delete the space after "link-". Insert "it is" between "if" and >"being". > >Page 4, section 3.2, 1st paragraph: insert "an" before "allocated". > >Page 4, section 3.2, 3rd paragraph: insert "a" before "client". > >Page 5, section 3.4, 2nd sentence: change "an option" to "options". > >Page 5, section 3.5, 1st paragraph: append a comma after "Vendor Class >option". Append "the" after "and". > >Page 5, section 3.6, 1st sentence: delete "of the". Delete before "DHCP >clients". > >Page 6, section 3.7, 1st sentence: change "is" to "are". Insert "a" before >"DHCP server". Delete "the" after "provide". Delete "the" before "DHCP >clients". > >Page 6, section 3.7, 2nd sentence: change "It enables" to "They enable". > >Page 6, section 3.8, 1st sentence: insert "a" before "DHCP client". > >Page 6, section 3.9, 1st paragraph, 1st sentence: append "option" after >"Information". > >Page 7, section 4.2, 1st paragraph, 2nd sentence: insert "a" before >"configured". > >Page 7, section 4.2, 2nd paragraph, 2nd sentence: change "can be" into >"being". > >Page 7, section 4.2, 2nd paragraph, 4th sentence: insert "an" before >"available". > >Page 7, section 4.2, 3rd paragraph, 1st sentence: insert "the" before >"available". > >Page 7, section 4.2, 3rd paragraph, 2nd sentence: insert "a" before >"returning". > >Page 8, section 4.2, 1st partial paragraph, 2nd full sentence: append a >comma after "scanning". > >Page 8, section 4.2, 1st partial paragraph, 3rd full sentence: insert "a" >before "much". > >Page 8, section 4.2, 1st full paragraph, 1st sentence: insert a hyphen >between "identifier" and "based". > >Page 8, section 4.2, 1st full paragraph, 2nd sentence: delete "being". > >Page 8, section 4.2, 1st full paragraph, 4th sentence: insert "it" after >"e.g.,". Change "reverted" to "reversed". > >Page 8, section 4.2, 2nd full paragraph, 1st sentence: insert "an" before >"available". > >Page 8, section 4.2, 2nd full paragraph, 3rd sentence: change "With the pool >allocation increasing" to "With increasing allocation from a pool". Insert >"chance of a" before "collision". Insert "the" before "birthday". > >Page 8, section 4.2, 2nd full paragraph, 4th sentence: change "being" to >"are". Change "most" to "more". Change "resource" to "address". > >Page 8, section 4.2, 2nd full paragraph, 6th sentence: insert "a" before >"privacy". Append a comma after "vendor discovery attacks". > >Page 8, section 4.2, 2nd full paragraph, 7th sentence: append "the" after >"e.g.,". Change "can" to "may". Insert "the" before "client-id". > >Page 8, section 4.2, 2nd full paragraph: I will repeat Robert Sparks' >admonition on a similar paragraph in the DHCPv6 privacy draft: "the >paragraph on Random allocation comments on the poor performance of a >specific simplistic implementation of random selection. More efficient >algorithms exist. But the discussion is mostly irrelevant to the document. >Please simplify this paragraph to focus on the benefits of random >allocation." > >Page 9, section 5.5, 2nd sentence: change "Option" to "option," (note the >comma too). Change "options" to "option". Insert a hyphen between >"long" >and "lived". > >Page 9, section 5.6, 1st sentence: insert "of the" before "aforementioned". > >Page 9, section 5.6, 2nd sentence: change "operator" to "An operator". >Insert "a" before "non-trivial". Change "observer" to "observe". Insert >"the" before "client's". > >Page 10, section 5.7, 1st sentence: append "a" after "put". Append "the" >after "into". > >Page 10, section 5.7, 2nd-4th sentences: I'm not sure what a discussion of >Client ID is doing here in the discussion of discovering a client's IP >address or hostname. Perhaps it belongs somewhere else? > >Page 10, section 5.8, 2nd sentence: change "deducted" to "deduced". Insert >"the" before "correlation". Insert "of the" between "that" and >"identifier". > >Page 10, section 5.9, 1st sentence: insert "a" before "user". And I'll let >slide the distinction between device and user for this discussion. > >Page 10, section 5.9, 2nd sentence: insert "the" before "client's". Append >"the" after "on" and change the immediately following "address" to >"addresses". Insert "an" before "attacker" in the "active" part of the >sentence. > >Page 10, section 5.9, last sentence: change "owner" to "owner's". > >Page 10, section 5.10, 1st sentence: change "as" to "to be". Append "as a" >after "either". Append "as a" after "or". > >Page 11, section 5.10, 1st paragraph, 1st sentence: insert "the" before the >first "DHCP". > >Page 11, section 5.10, 2nd paragraph, 2nd sentence: insert "an" before >"operator's". Insert "the" before "server's". > >Page 11, section 6, 1st paragraph: delete the 2nd "the". > >Page 11, section 6, 3rd sentence: change the second "for" to "to". > >Page 11, section 7: change "at" to "in". > >Page 11, section 9: append a comma after "Schaefer". > >Page 12, normative references: I'm not sure why RFC 2136 is normative, yet >many of the options are informative. I seem them as all being of the same >level.