Re: [dhcwg] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05

tianxiang li <peter416733@gmail.com> Tue, 31 January 2017 15:59 UTC

Return-Path: <peter416733@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295E3129EDF; Tue, 31 Jan 2017 07:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7GlXLI2M74qy; Tue, 31 Jan 2017 07:59:33 -0800 (PST)
Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272B6129D11; Tue, 31 Jan 2017 07:59:31 -0800 (PST)
Received: by mail-ot0-x235.google.com with SMTP id 73so268997333otj.0; Tue, 31 Jan 2017 07:59:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b+wX0Neu1HwBBACPYSYMTgmHx09kzPeEsHMFXakCR1U=; b=mpArjdY5Ayb/PDQjAuCb57m4tP1OAX6vN8l9am+4zBfJUGnZKBvuZ+c8aJ4IVxDFe3 azYNUrsV6t0gQKXYBKxsDHeZXire0uZ08bDCBTeBTAtrZBkJOQCC63URmJ+LrCnUl19M t2p2AlCMVkQEHM/4Zrj22TopFKzx5h5HmXo+McME2AUzlXPFyM+ocyQZcMj2Idq/x4ZM HA2tCfdsvy7P5sw2S+6UAwhKWXdEksliIQGvKPPQBtZG2xes+5kLHOfh1tBjirlo8MHY WIOEaEI0Gg2OPfXRF2eCxEbQUDznJvqm/ygwoLsSvjxtNnMJfKaf4C8Jd9nf6GteeOnv v9oQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b+wX0Neu1HwBBACPYSYMTgmHx09kzPeEsHMFXakCR1U=; b=V8E6TvT+zjIev+iHN8iaw0HzSK4aMJgxPL8Pjk6XWznxVaBUBsNZGwh+/gmPT4DmTU snOb8SKrNuuZeg1VfRe7xOotQZFl+urDmjR6KR6gi4obYANSp1chwbi+GKQ0RJfCl3IS 835GC6usURRxz5WgYe+Ak3WjTyB1F97WNSODZObKWzg5+OyAj0wgpyuhRU6Fw5XIjZLN PMnGlmV6REmSGgZI5gXVsKUZk0ppRm2/aX4e2rRGOrQ6YeCIWujyo+LpeZe1nu2pSVce o/h503ZsLmOwClRR6+rj5ioMDYQJdgiIifIELayiO84Fhs4PbS9cgTzUFzOAyS4LzVLj ymqQ==
X-Gm-Message-State: AIkVDXLorIMVQXrG77KC5rqkPUct+XS1Egqx3G8tdl4OIPqyYoc0tUre8sNLh5EbO2RoTf9m51m5RiJe4wJj0g==
X-Received: by 10.157.15.221 with SMTP id m29mr12617290otd.186.1485878370492; Tue, 31 Jan 2017 07:59:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.1.202 with HTTP; Tue, 31 Jan 2017 07:58:50 -0800 (PST)
In-Reply-To: <148568056700.24536.11691583944564362484.idtracker@ietfa.amsl.com>
References: <148568056700.24536.11691583944564362484.idtracker@ietfa.amsl.com>
From: tianxiang li <peter416733@gmail.com>
Date: Tue, 31 Jan 2017 23:58:50 +0800
Message-ID: <CAFx+hEPy0rzAa_QFu4wOBc2hpRqX-5MM0OtZfmuy82Ls7WRmAA@mail.gmail.com>
To: Roni Even <roni.even@mail01.huawei.com>
Content-Type: multipart/alternative; boundary="001a113d101873e6e30547660466"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/f7tdtJumSY9teIek5Sjq8Fn3ZMA>
Cc: dhcwg <dhcwg@ietf.org>, gen-art@ietf.org, ietf@ietf.org, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@ietf.org
Subject: Re: [dhcwg] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jan 2017 15:59:35 -0000

Dear Roni,

Thank you for providing a thorough review of this document.

I have a few questions regarding the comments, please see inline.

Best regards,
Tianxiang

2017-01-29 17:02 GMT+08:00 Roni Even <roni.even@mail01.huawei.com>:

> 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
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> 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
>

[Tianxiang] This document does not change any of the text in RFC 3633, but
specifies the client and server behavior when using the "prefix-length
hint", which was not explained in RFC3633. Would it be suitable to state
"this document updates RFC3633"?


> 2.      In section 3.1 reference RFC3315 for solicit message and 3.3 for
> advertise messge


[Tianxiang] Okay, we'll add reference to RFC3315 in section 3.1 and 3.3
when mentioning Solicit and Advertise messgae.


> 3.      In section 3.1 solution last paragraph is the order of the two
> IAPREFIX options important?
>

[Tianxiang] There is no strict requirement for the order of the two
options. Would you prefer if we added a sentence to specify this?


> 4.      In section 3.2 solution why are you suing SHOULD and not MUST in
> all recommendations?
>

[Tianxiang] In this document, we used "MUST" for some of the client
behaviors, as they are mandatory to avoid client failure and necessary if
the client wanted to express its prefix-length requirement.

For server behavior, we used "SHOULD" because this document specifies the
desired server behavior if the server wants to consider the prefix-length
hint, but the server could have its own behavioral policy (e.g. neglect the
prefix-length hint).


> 5.      In section 3.2 solution, what should the server do if cannot
> provide any of the requests
>

[Tianxiang] If the server could not provide the requested prefix or
prefix-length, it should provide a prefix closest to the prefix-length
hint, as stated in the last sentence of section 3.2.

Are you referring to what the sever should do of it simply could not
provide ANY prefixes to the client? In that case, we could add a sentence
at the end of the section 3.2:

"If the server will not assign any prefixes to any IA_PDs in a subsequent
Request from the client, the server MUST send an Advertise message to the
client as described in section 11.2 of RFC 3633."


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

[Tianxiang] Thanks for pointing that out, we'll change it to "SHOULD
provide".


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

[Tianxiang] This was mentioned in the last sentence of section 3.2:

"If the requested prefix is not available in the server's prefix pool, and
the client also included a prefix-length hint in the same IA_PD option,
then the server SHOULD try to provide a prefix matching the prefix-length
value, or the prefix with the shortest length possible which is closest to
the prefix-length hint value."


> 8.      In section 3.5 solution the document use “as close as possible” and
> section 3.2 only talk about smaller.
>

[Tianxiang] This was mentioned in the last sentence of section 3.2.


> 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
> value
>

[Tianxiang] The idea was to list all the options, and discuss their
consequences. And the server could decide which option to use depending on
its policy.

Option 3 avoids the complexity of handling multiple delegated prefixes,
despite of breaking up all connections. Option 4 allows to server to
configure a valid-lifetime for the old prefix depending on actual
requirements, rather than let the old prefix expire on its own.


>
> Nits/editorial comments:
>
>
>
>