Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

While https://tools.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-01 was standards track and had RFC2119 "requirements language", it was never used. So, the draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was changed to informational. However, The RFC2119 requirements language section wasn't removed until draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00 was published.

So, perhaps Ole's suggestion for the authors to propose what they think should be normative (there was a suggestion that section 2.5 be) is a good one. And, from that we can see if Standards Track is more appropriate.

BTW: The text about assigning a /48 was in an "e.g." (for example) section. And that would not be normative and was never intended to be:

                                E.g.  If the delegating router could only
   provide prefixes of lengths /30, /48, and /56, and the requesting
   router is requesting for a /50 in the prefix-length hint, then the
   delegating router should provide the /48 to the requesting router

- Bernie

-----Original Message-----
From: otroan@employees.org [mailto:otroan@employees.org] 
Sent: Thursday, April 21, 2016 3:00 PM
To: Ted Lemon <mellon@fugue.com>
Cc: Bernie Volz (volz) <volz@cisco.com>; dhcwg@ietf.org
Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

Ted,

> Ole, the point is that if the document makes any normative statements, it's got to be standards-track.   You are quite right that the particular statements you call out should not be made normatively, though!

Agree, one option if we can identify what's normative in the document would be to add that text to the 3315bis and leave this informational.

RFC2119-ifying the text the authors think should be normative would be a good start.

cheers,
Ole

> 
> On Thu, Apr 21, 2016 at 2:28 PM, <otroan@employees.org> wrote:
> there are some parts that could be made normative, like section 2.5.
> but most of the document appears informational in nature.
> paraphrased example: "the server should delegates a /48 if the client requests it".
> that's clearly policy, and a matter of the possible commercial arrangement, seems strange if the IETF should try to codify that.
> 
> I lean towards informational.
> 
> the document also does not say anything about _how_ the client is supposed to figure out what sized address block to request.
> if the answer to that is manual configuration, then there are tens of ways that could be done differently out of band.
> 
> cheers,
> Ole
> 
> 
> 
> > On 21 Apr 2016, at 18:45, Bernie Volz (volz) <volz@cisco.com> wrote:
> >
> > Hi:
> >
> > One item that was raised at the IETF-95 DHC WG session was the recent change (suggested by me before draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to Informational rather than Standards Track. Marcin Siodelski suggested that the document be Standards Track:
> >
> > The brief (draft) minutes for this discuss are:
> >
> > ---
> > 5. DHCPv6 Prefix Length Hint Issues, Bernie Volz (for Tianxiang Li) - 10 minutes, 14:50
> >     draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
> >
> >     The authors believe work is ready for WGLC.
> >
> >     Ian: Is this now informational? "This is the suggested way to do it"?
> >     Bernie: Correct. There were some discussions and the conclusion was to not
> >        enforce it.
> >     Marcin (on jabber): I'd suggest this is standards track doc with normative language
> >        in. Otherwise implementations will ignore hints.
> > ---
> >
> > Once we resolve this open question (and after a possible update to the document), we intend to start a WGLC on the document.
> >
> > Please respond with your comments as to whether this document should be Informational or Standards Track by May 5th, 2016. Of course, any other comments are welcome as well!
> >
> > Thanks!
> >
> > -          Tomek & Bernie
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> 