[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.