[Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05

Roni Even <roni.even@mail01.huawei.com> Sun, 29 January 2017 09:02 UTC

Return-Path: <roni.even@mail01.huawei.com>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0370E129441; Sun, 29 Jan 2017 01:02:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roni Even <roni.even@mail01.huawei.com>
To: gen-art@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.41.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148568056700.24536.11691583944564362484.idtracker@ietfa.amsl.com>
Date: Sun, 29 Jan 2017 01:02:47 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/6h_XUUOBCbNFnMEZkzu7qjc5-gs>
Cc: dhcwg@ietf.org, ietf@ietf.org, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@ietf.org
Subject: [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 29 Jan 2017 09:02:47 -0000

Reviewer: Roni Even
Review result: Almost Ready

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

For more information, please see the FAQ at


Document: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05
Reviewer: Roni Even
Review Date: 2017-01-29
IETF LC End Date: 2017-02-09
IESG Telechat date: 2017-02-16

Summary: This draft is almost ready for publication as a standard
track RFC.

Major issues:

Minor issues:

1.	I think that this document updates RFC3633 and it should be
mentioned in the title and abstract
2.	In section 3.1 reference RFC3315 for solicit message and 3.3 for
advertise messge
3.	In section 3.1 solution last paragraph is the order of the two
IAPREFIX options important?
4.	In section 3.2 solution why are you suing SHOULD and not MUST in
all recommendations?
5.	In section 3.2 solution, what should the server do if cannot
provide any of the requests
6.	In section 3.2 solution last paragraph “SHOULD try to provide” and
in the first paragraph “SHOULD provide” should be the same in both.
7.	In section 3.4 “If the client decided to use  the prefix provided
by the server despite being longer than the  prefix-length hint” yet I
did not see in section 3.2 that the server can provide a longer
8.	In section 3.5 solution the document use “as close as possible” and
section 3.2 only talk about smaller.
9.     In section 3.5 solution why offer options 3 and 4. The draft
says that option 3 will break client connections and 4 talks about “a 
short non-zero valid-lifetime” which may cause the  client to lose
connection if "too short for the client" since “short” is not an exact

Nits/editorial comments: