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

[Marcin Siodelski <[e-mail]>]

Thanks for addressing my earlier comments. In my opinion this is ready
for adoption.

A couple quick comments below. Sorry for not sending this earlier, but I
was off for a few days.

Even though it is an informational document, some parts may deserve use
of normative language. For example:

Section 3.1
"When the requesting router prefers a prefix of specific length from
   the delegating router, the requesting router should send a Solicit
   message including the preferred prefix-length value in the "prefix-
   length" field of the OPTION_IAPREFIX option, and set the "IPv6
   prefix" field to zero.  This is an indiction to the delegating router
   that the requesting router prefers a prefix of specific length,
   regardless of what it had gotten before.

   When the requesting router wants the same prefix back from the
   delegating router, it should include the prefix value in the "IPv6
   prefix" field of the OPTION_IAPREFIX option, and the length of the
   prefix in the "prefix-length" field.  This is an indication to the
   delegating router that the requesting router wants the same prefix
   back."

If the requesting router is interested in getting a different prefix
than it has, this is important that the requesting router places the
hint for the new prefix length and if it doesn't it will likely get
previous prefix which will cause a requesting router to not function or
repeatedly fall back to Solicit hoping to get a prefix of desired length
eventually. Isn't it an example of a need to use normative language to
avoid repeated "retransmissions" as stated in RFC2119, section 6?

This is more of a question, because I don't feel like being an expert in
this gray area when the normative must or must not be used.



Throughout the document there are several occurrences of: "prefix
matching the prefix-length hint..." or similar. The word "matching" is
ambiguous and it doesn't convey the information that the requesting
router could as well accept the prefix with a shorter prefix-length.
Perhaps say: "prefix with a length equal or shorter than prefix-length
hint". Alternatively, explain in the terminology or introduction what it
means that the prefix lengths "match".



" There are
   certain situations where the requesting router would fail if it used
   a prefix which length is different from what it requested in the
   prefix-length hint. "

Perhaps replace "fail" with "could not (properly) operate" or something
like that. To me "fail" sounds like fatal failure. :-)


Section 3.5.

OLD:
"1.  Renew just the original delegated prefix."

NEW:
"1.  Renew original delegated prefix and ignore the hint" ??


Also, this section (per its title) is about Renew & Rebind message
processing. The "Solution" seem to only focus on Renew:

"Upon the receipt of Renew message..."


Then descriptions of different possible behaviors start with "Renew",
e.g. "Renew just the original delegated prefix". Even though I realize
that by "Renew" you mean "extend lifetime" it may be generally perceived
as confusing. So, I'd suggest:

"1. Extend lifetime of the original delegated prefix."

rather than

"1. Renew just the original delegated prefix."


Also, the following:
"The delegating router could do one of the following depending on
   server policy:"

is probably based on the assumption that the delegating router knows the
requesting router's binding (original delegated prefix)? For the Rebind
case, it may be a different delegating router that receives this
message. In that case:
- 1, 2 and 4 are not feasible because another server assigned the prefix
- 3. is not really feasible unless the server can authoritatively say
that original prefix shouldn't be used anymore.
- 5. is probably best

In case the server responding to a Rebind is the same server that
delegated original prefix, the list remains the same.

I wonder if it would be better to say:

"If the delegating router assigned the prefix included in IA_PD to the
requesting router, the delegating router can do one of the following,
depending on its policy:".

Marcin


On 14.11.2015 06:57, tianxiang li wrote:
> 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] <mailto:[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] <mailto:[e-mail]>>,
> Yong Cui <[e-mail]
> <mailto:[e-mail]>>, Cong Liu <[e-mail]
> <mailto:[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
> <http://tools.ietf.org>.
> 
> The IETF Secretariat
> 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>