[Gen-art] Gen-ART LC review of draft-ietf-dhc-dhcp-privacy-03

"Peter Yee" <peter@akayla.com> Fri, 05 February 2016 10:01 UTC

Return-Path: <peter@akayla.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E541B2BB3; Fri, 5 Feb 2016 02:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.1
X-Spam-Level: ***
X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_LIST=2.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_XRJpiuEAt1; Fri, 5 Feb 2016 02:01:38 -0800 (PST)
Received: from p3plsmtpa06-08.prod.phx3.secureserver.net (p3plsmtpa06-08.prod.phx3.secureserver.net [173.201.192.109]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82BB1B2BF7; Fri, 5 Feb 2016 02:01:38 -0800 (PST)
Received: from spectre ([173.8.184.78]) by p3plsmtpa06-08.prod.phx3.secureserver.net with id Ea1d1s00H1huGat01a1dYg; Fri, 05 Feb 2016 03:01:38 -0700
From: Peter Yee <peter@akayla.com>
To: draft-ietf-dhc-dhcp-privacy.all@ietf.org
Date: Fri, 05 Feb 2016 02:01:42 -0800
Message-ID: <02a801d15ffc$3704e500$a50eaf00$@akayla.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdFf8Ww8Pi/nG3IDTUO4GBplGCUhuQ==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/6cCI6Q8rqbQUfPqia4aPDROszRQ>
Cc: gen-art@ietf.org, ietf@ietf.org
Subject: [Gen-art] Gen-ART LC review of draft-ietf-dhc-dhcp-privacy-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2016 10:01:40 -0000

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.