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

[Marcin Siodelski <[e-mail]>]

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