Re: [dhcwg] Fwd: New Version Notification for draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt

[tianxiang li <[e-mail]>]

Hi Bernie,

Thank you for taking the time to review this document. I will update a new
version of the document soon and include these suggestions.
Hopefully we can start a WG call for adoption soon.

Regards,
Tianxiang

2015-11-30 0:38 GMT+08:00 Bernie Volz (volz) <[e-mail]>:

> Hi:
>
>
>
> (These are my personal comments – i.e., with WG chair hat off.)
>
>
>
> Thanks for updating the document. I think the organization is much
> improved.
>
>
>
> I read over this document and have mostly nits:
>
>
>
> 1.       I think it would be useful if this document actually used
> “OPTION_IAPREFIX”. While is does reference it by its name in RFC 3633
> (IA_PD Prefix Option), actually making use of it would be good – such as
> for google searches.
>
> 2.       In section 1. Introduction:
>
>
>
>    DHCPv6 Prefix Delegation [RFC3633 <https://tools.ietf.org/html/rfc3633>]
> allows a requesting router to
>
>    include a prefix-length hint value in the message sent to the
>
>    delegating router, to indicate a preference for the size of the
>
>    prefix to be delegated.  A prefix-length hint is communicated by a
>
>    requesting router to the delegating router by including an IA_PD
>
>    Prefix Option, encapsulated in an IA_PD option, with the "IPv6
>
>                 ^ insert “(OPTION_IAPREFIX)” here?
>
>    prefix" field set to zero and the "prefix-length" field set to a non-
>
>    zero value.  The delegating routers are free to ignore the hint
>
>    values depending on server policy.  This would not cause problems for
>
>    some hint values such as T1 and T2 lifetimes, but it would be an
>
>                                                         ^ could?
>
>        (note also that we are planning on deprecating T1/T2/lifetime hints
>
>         and saying “such as T1, T2, and lifetimes” would be more proper?)
>
>    issue for the prefix-length hint.  Some requesting routers can't
>
>    function normally when they're provided with a prefix which length is
>
>    different from what they requested.  E.g. if the requesting router is
>
>    asking for a /56 and the delegating router returns a /64, the
>
>    functionality of the requesting router might be limited because it
>
>    might not be able to split the prefix for all its interfaces.  The
>
>    requesting routers usually have higher preference on the prefix-
>
>    length hint than the other option hints, and it should be given more
>
>    consideration.
>
>         (I think this last sentence as no value so would recommend
> dropping)
>
>
>
>    The current specification is unclear about how the requesting router
>
>    ^^^^^^^^^^^^^^^^^^^^^^^^^ [RFC3633]
>
>         (Current is unclear – does it refer to this document or ? So why
>
>          not replace with [RFC3633]?)
>
>    and delegating router should act in different situations involving
>
>
>
> 3.       While minor, there are several places where “/30,/48, and /56”
> is used … add space before /48?
>
> 4.       In section 3.2, “only provides prefixes pf lengths” … pf should
> be of?
>
> 5.       In section 3.4, “delegating routers might not” … “Delegating
> routers might not”.
>
> And, later space is missing after “.” in “during Renew/Rebind.[RFC3633]”.
>
> Also, again “IA_PD Prefix Options” could just be “OPTION_IAPREFIX”?
>
> And, “This is to extend [the] lifetime”. (Add the.)
>
> 6.       In section 3.5, in the solution, I think it would be good to
> clarify that there are two OPTION_IAPREFIX options:
>
>
>
>    Upon the receipt of Renew message, if the requesting router included
>
>    in the IA_PD both the delegated prefix value and a prefix-length hint
>
>    value, the delegating router should check to see whether it could
>
>    extend the lifetime of the original delegated prefix and whether it
>
>    has any available prefix matching the prefix-length hint, or as close
>
>    a possible to the requested length, within the delegating router's
>
>    limit.
>
>
>
> Perhaps reword to something like:
>
>
>
>    Upon the receipt of Renew message, if the requesting router included
>
>    in the IA_PD both OPTION_IAPREFIX option with the delegated prefix
>
>    and an OPTION_IAPREFIX option for a prefix-length hint, the delegating
>
>    router should check to see whether it could extend the lifetime of the
>
>    original delegated prefix and whether it has any available prefix
>
>    matching the prefix-length hint, or as close a possible to the
>
>    requested length, within the delegating router's limit.
>
>
>
> Later in this section assign is misspelled (asssign).
>
>
>
> -          I think you also need to take a first pass at the Security
> Considerations. It may be possible to just state that this document
> introduces no new security considerations over those already discussed in
> [RFC3633] as the document is providing guidance on how requesting routers
> and delegating routers interact with regard to the prefix-length hint
> mechanism introduced in [RC3633].
>
>
>
> Hopefully others will comment on this document and we can soon move to
> doing a WG call for adoption?
>
>
>
> -          Bernie
>
>
>
> *From:* dhcwg [mailto:[e-mail]] *On Behalf Of *tianxiang li
> *Sent:* Saturday, November 14, 2015 12:57 AM
> *To:* dhcwg <[e-mail]>
> *Subject:* [dhcwg] Fwd: New Version Notification for
> draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt
>
>
>
> Hi all,
>
>
>
> We have updated a new version of the DHCPv6 Prefix Length Hint Issues
> draft, according to the comments from the ietf94 meeting and the
> mailinglist.
>
>
>
> Main changes:
>
>
>
> 1. Changed text structure, problem statement and solution are now written
> in the same section.
>
>
>
> 2. Changed document type from Standards Track to Informational.
>
>
>
> 3. Changed terms "client/server" to "requesting router/delegating router",
> to keep text unified with RFC3633.
>
>
>
> 4. In the solution part of section 3.5.  Receipt of Renew/Rebind Message,
> we added an additional server solution choice. A server could assign a new
> prefix and not mention the old prefix in the Reply message.
>
>
>
> 5. In the solution part of section 3.3.  Receipt of Advertise Message,
> added reference to RFC7550 for the situation where the client requested for
> both IA_NA and IA_PD options, and the server could not honor the
> prefix-length hint of the IA_PD option.
>
>
>
> Comments and reviews are appreciated.
>
>
>
> Regards,
>
> Tianxiang Li
>
>
>
> ---------- Forwarded message ----------
> From: <[e-mail]>
> Date: 2015-11-14 13:54 GMT+08:00
> Subject: New Version Notification for
> draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt
> To: Tianxiang Li <[e-mail]>, Yong Cui <
> [e-mail]>, Cong Liu <[e-mail]>
>
>
>
> A new version of I-D, draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt
> has been successfully submitted by Tianxiang Li and posted to the
> IETF repository.
>
> Name:           draft-cui-dhc-dhcpv6-prefix-length-hint-issue
> Revision:       02
> Title:          DHCPv6 Prefix Length Hint Issues
> Document date:  2015-11-13
> Group:          Individual Submission
> Pages:          9
> URL:
> https://www.ietf.org/internet-drafts/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-cui-dhc-dhcpv6-prefix-length-hint-issue/
> Htmlized:
> https://tools.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02
>
> Abstract:
>    DHCPv6 Prefix Delegation [RFC3633] allows a requesting router to
>    include a prefix-length hint value in the IA_PD option to indicate a
>    preference for the size of the prefix to be delegated, but is unclear
>    about how the requesting router and delegating router should act in
>    different situations involving the prefix-length hint.  This document
>    provides a summary of the existing problems with the prefix-length
>    hint and guidance on what the requesting router and delegating router
>    could do in different situations.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>