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

["Bernie Volz (volz)" <[e-mail]>]

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:[e-mail]] On Behalf Of Marcin Siodelski
Sent: Wednesday, December 09, 2015 4:02 AM
To: tianxiang li <[e-mail]>
Cc: dhcwg <[e-mail]>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt

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

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg