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

[tianxiang li <[e-mail]>]

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

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