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

From: Marcin Siodelski <[email-masked]>
Date: Tue, 8 Dec 2015 16:39:43 +0100

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: ** <[email-masked] <mailto:[email-masked]>>
> 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 <[email-masked] <mailto:[email-masked]>>,
> Yong Cui <[email-masked]
> <mailto:[email-masked]>>, Cong Liu <[email-masked]
> <mailto:[email-masked]>>
> 
> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: tianxiang li <[email-masked]>
Date: Wed, 9 Dec 2015 11:16:29 +0800

Hi Marcin,

Thank you for reviewing this draft. I do think some parts of the draft
require the use of normative language. I didn't notice this during the last
update, thanks for pointing that out. I will add your suggestions in the
next version.

Regarding the use of "MUST", since this is an informational document, some
client or server might not implement the feature, is it okay to use "MUST"
or should we stick with "SHOULD" instead? I'm also uncertain about this.

Regards,
Tianxiang

2015-12-08 23:39 GMT+08:00 Marcin Siodelski <[email-masked]>:

> > A new version of I-D,

---

From: Marcin Siodelski <[email-masked]>
Date: Wed, 9 Dec 2015 10:01:57 +0100

Whether to use "MUST" or "must" is really a non-existing issue because
this document doesn't include any occurrences of "must" except for
Copyright notice and "Requirements Language". So, you already use
"shoulds" all over the place. :-)

Marcin

On 09.12.2015 04:16, tianxiang li wrote:
> require the use of normative language. I didn't notice this during the
> last update, thanks for pointing that out. I will add your suggestions
> in the next version.
>
> Regarding the use of "MUST", since this is an informational document,
> some client or server might not implement the feature, is it okay to use
> "MUST" or should we stick with "SHOULD" instead? I'm also uncertain
> about this.
>
> Regards,
> Tianxiang
>
> 2015-12-08 23:39 GMT+08:00 Marcin Siodelski <[email-masked]
> <mailto:[email-masked]>>:
>
>     > From: ** <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     > To: Tianxiang Li <[email-masked]
> <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>,
> <mailto:[email-masked]>
>     > <mailto:[email-masked]
>     <mailto:[email-masked]>>>, Cong Liu
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     >
>     >
>     >
>     > A new version of I-D,
>     > until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>
>     > <http://tools.ietf.org>.
>     >
>     > The IETF Secretariat
>     >
>     >
>     >
>     >
>     > [email-masked] <mailto:[email-masked]>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 11 Dec 2015 14:55:59 +0000

Hi:

Probably best to remove reference to 2119 (section 2) from the next revision (it is still in 03) as it does not look like any of these (upper case) key words are used?

If we do intend to keep this document as informational, it may be best not to use 2119 key words.

This may be worth revisiting at a later time - perhaps the consensus will change to make this more normative instead of keeping it informative? It can always be stated that "if an implementation wants to support the prefix-length hint, then ..." (this is much like the "other configuration option" documents that use these (upper case) key works as they only apply if an implementation "supports" that option).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Marcin Siodelski
Sent: Wednesday, December 09, 2015 4:02 AM
To: tianxiang li <[email-masked]>
Cc: dhcwg <[email-masked]>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt

Marcin

---

From: Marcin Siodelski <[email-masked]>
Date: Fri, 11 Dec 2015 17:28:30 +0100

Does it mean that "Informational" type of document must not use
normative language from RFC2119, and use of this language implies that
the document should be standards track?

I don't know what is the right reference to find out? I just found some
draft from 8 years ago:
https://tools.ietf.org/html/draft-peterson-informational-normativity-00
which doesn't seem to preclude the use of normative language in
informational documents.

Overall, it seems odd to me that this particular document is marked as
Informational (though I realize it was discussed and agreed on). But, we
also considered including it in RFC3315bis in which case making it
standards track is somewhat natural.

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 11 Dec 2015 16:37:30 +0000

This is a complex issue and I’m not sure I have a good answer; but I
believe it is OK to use RFC 2119 key words in INFORMATIONAL (if the 2119
definition applies).

All I was trying to point out is:

- At present there is no use of the upper case key words in the document.
So, there is no point to include the 2119 reference. (This might have just
come from a “template” version used to create the file.)

- If the intent of the authors was to make use of the key words but use
them in lower case, then the text should change to specify the lower case
version (or upper case the usage).

If we do want to change the document to make use of those (upper case) key
words, then of course we should keep it in (or add it back at that time).

- Bernie

On 12/11/15, 11:28 AM, "Marcin Siodelski" <[email-masked]> wrote:

>> Probably best to remove reference to 2119 (section 2) from the next
>>revision (it is still in 03) as it does not look like any of these
>>(upper case) key words are used?
>> 
>> This may be worth revisiting at a later time - perhaps the consensus
>>will change to make this more normative instead of keeping it
>>informative? It can always be stated that "if an implementation wants to
>>support the prefix-length hint, then ..." (this is much like the "other
>>configuration option" documents that use these (upper case) key works as
>>they only apply if an implementation "supports" that option).
>> 
>> - Bernie
>> 
>> Subject: Re: [dhcwg] Fwd: New Version Notification for