RE: Gen-ART LC review of draft-ietf-dhc-dhcp-privacy-03

[Sheng Jiang <[e-mail]>]

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:[e-mail]]
>Sent: Friday, February 05, 2016 6:02 PM
>To: [e-mail]
>Cc: [e-mail]; [e-mail]
>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.