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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 21 Apr 2016 16:45:17 +0000

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Apr 2016 12:49:15 -0400

I think it's normative.

On Thu, Apr 21, 2016 at 12:45 PM, Bernie Volz (volz) <[email-masked]> 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:
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Apr 2016 18:48:20 +0200

In your previous mail you wrote:

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

=> from the subject (in particular the term "hint") and the wording
I am more for Informational. Note BTW this is not an answer to Marcin's
concern as he proposed first to change the wording for a normative one.

Regards

[email-masked]

---

From: Marcin Siodelski <[email-masked]>
Date: Thu, 21 Apr 2016 10:08:19 -0700

> concern as he proposed first to change the wording for a normative one.

In this case, can you answer the actual question? Should the document
become Standards Track and (as consequence) the wording should be
changed to normative?

Marcin

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Apr 2016 19:23:18 +0200

In your previous mail you wrote:

>  In this case, can you answer the actual question?

=> argh! (:-)

> Should the document become Standards Track and (as consequence) the
> wording should be changed to normative?

=> as the long term plan should be to merge this clarification into
the RFC3633 successor a normative wording makes sense so (as consequence)
Normative status too. I know my answer is more to the "publish as
Informational as it vs. rewrite and publish as Standard" question.

Regards

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Apr 2016 13:35:55 -0400

If it's normative, it's standards track.   Informational can't be
normative.   Of course, we sometimes treat informational documents as
normative, but this is usually because they become standard practice over
time through repeated use.   Since we know that we mean this advice to be
normative now, it doesn't make any sense for us to say that the document
should be informational.

---

From: [email-masked]
Date: Thu, 21 Apr 2016 20:28:02 +0200

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) <[email-masked]> wrote:
> 
> Hi:
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Apr 2016 14:32:47 -0400

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!

On Thu, Apr 21, 2016 at 2:28 PM, <[email-masked]> wrote:

> that's clearly policy, and a matter of the possible commercial
> arrangement, seems strange if the IETF should try to codify that.
>
> 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
>
>
>

---

From: [email-masked]
Date: Thu, 21 Apr 2016 20:59:58 +0200

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 21 Apr 2016 20:02:12 +0000

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: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 21, 2016 3:00 PM
To: Ted Lemon <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

Ted,

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Apr 2016 16:28:01 -0400

Ole's suggestion is correct except that if we have normative language in
the document, the iesg is going to ask why it's informative. There isn't
any question to debate here. Either it's normative, iwc PS, or it's not
normative, iwc informative. I feel like Ole may just be resisting
publishing it at all, iwc we should do that, not confuse the iesg. But I
think that would be the wrong move, because we don't know when 3315bis will
get consensus.
On Apr 21, 2016 4:02 PM, "Bernie Volz (volz)" <[email-masked]> wrote:

> 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:
>
> Subject: Re: [dhcwg] Follow up from IETF-95 -
> > 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
> 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.
>
> > 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
> >
> >
> >
> be Informational or Standards Track by May 5th, 2016. Of course, any other

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 21 Apr 2016 21:13:39 +0000

Ted … if we put normative text in, it will be Standards Track.

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, April 21, 2016 4:28 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

Ole's suggestion is correct except that if we have normative language in the document, the iesg is going to ask why it's informative. There isn't any question to debate here. Either it's normative, iwc PS, or it's not normative, iwc informative. I feel like Ole may just be resisting publishing it at all, iwc we should do that, not confuse the iesg. But I think that would be the wrong move, because we don't know when 3315bis will get consensus.
On Apr 21, 2016 4:02 PM, "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>> wrote:
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.

- Bernie

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

Ted,

cheers,
Ole

>
> On Thu, Apr 21, 2016 at 2:28 PM, <[email-masked]<mailto:[email-masked]>> wrote:
> > On 21 Apr 2016, at 18:45, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi:
> >
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Apr 2016 21:52:02 -0400

Right.   Sorry, was I packet-storming?   Maybe I misunderstood what Ole was
suggesting.

On Thu, Apr 21, 2016 at 5:13 PM, Bernie Volz (volz) <[email-masked]> wrote:

> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Thursday, April 21, 2016 4:28 PM
> *To:* Bernie Volz (volz) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* RE: [dhcwg] Follow up from IETF-95 -

---

From: Ian Farrer <[email-masked]>
Date: Fri, 22 Apr 2016 11:20:26 +0200

Hi,

I think seeing the changes that adding normative text would make is the best way forward.

I also would like to see the outcome of this rolled up into the 3315-bis as it’s directly applicable and one of the motivations for writing it is that 3633 didn’t cover it. But, publishing this as informational without normative language and then putting it into 3315-bis with normative seems a bit like a 'bait-and-switch’:-)

So, if it needs normative text in 3315-bis, then it should be progressed as Standards track in this version.

Cheers,
Ian

> On 21 Apr 2016, at 20:59, [email-masked] wrote:
> 
> Ted,
>

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Apr 2016 17:28:14 +0200

In your previous mail you wrote:

>  I also would like to see the outcome of this rolled up into the 3315-bis as 
>  it’s directly applicable and one of the motivations for writing it is that 36
>  33 didn’t cover it. But, publishing this as informational without normative l
>  anguage and then putting it into 3315-bis with normative seems a bit like a 
>  'bait-and-switch’:-)
>  

+1 (with a different (and surely better :-) wording Ian expressed the
same idea than me)

Regards

---

From: yogendra pal <[email-masked]>
Date: Fri, 22 Apr 2016 22:28:33 +0530

Hints are meaningful in CPE deployments, I would like to support for
Standards Track.

Regards,
Yogendra Pal
Cisco systems, Inc.

On Fri, Apr 22, 2016 at 8:58 PM, Francis Dupont <[email-masked]>
wrote:

> >  I think seeing the changes that adding normative text would make is the
> best
> >   way forward.
> >
> >  So, if it needs normative text in 3315-bis, then it should be
> progressed as
> >  Standards track in this version.
>

-- 
Thanks and Regards,
Yogendra Pal
+919686202644

---

From: tianxiang li <[email-masked]>
Date: Mon, 25 Apr 2016 11:12:16 +0800

Hi,

I think it is a good idea to first add normative text into the document. We
will update a new version of the prefix-length hint issues draft soon, and
determine which parts should be normative.
We really appreciate your comments.

Thank you,
Tianxiang

2016-04-22 17:20 GMT+08:00 Ian Farrer <[email-masked]>:

> best way forward.
> I also would like to see the outcome of this rolled up into the 3315-bis
> as it’s directly applicable and one of the motivations for writing it is
> that 3633 didn’t cover it. But, publishing this as informational without
> normative language and then putting it into 3315-bis with normative seems a
> bit like a 'bait-and-switch’:-)
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 28 Apr 2016 11:22:51 -0700

At Thu, 21 Apr 2016 16:45:17 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

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

[...]

> other comments are welcome as well!

On re-reading dhc-dhcpv6-prefix-length-hint-issue-00 to answer the
call (just noticed 01 was submitted today; haven't read it yet), I
have even more fundamental question than standards track vs
informational: what's the problem/is it worth addressing/solving in
the first place?

In general, I always thought hints from a client is literary a hint,
and the client can't expect anything specific from the server or rely
on such an expectation by sending a hint.  In my view, if there's such
a client implementation, it'd simply be a bug of it and should be
fixed.

Also, it's not clear to me what's special in the case of prefix length
hint.  The draft shows an example:

   If the requesting router is asking for a /56 and the delegating
   router returns a /64, the functionality of the requesting router
   might be limited because it might not be able to split the prefix for
   all its interfaces.

It might be a "problem", but it doesn't necessarily seem to me to be a
protocol level problem.  Realistically, the (minimum) size of the
delegated prefix would be determined by some operational policy of the
delegating side (such as an ISP) and included in some kind of contract
between the delegating side and the requesting side.  If the
requesting side needs to rely on a wider prefix, it should ensure that
it can at least get the necessary size of prefix at that level, rather
than hoping that the requirement is met in the protocol level using
the hint value.

We could also come up with a "problem" for other kind of hints, for
example:

   If a DHCPv6 client is asking for a specific IPv6 address as a hint
   in IA_NA because the client used that particular address before and
   some long-standing application relies on it, and the DHCPv6 server
   returns a different address than that, then the functionality of
   the client is limited because this long-standing application might
   not be able to work correctly.

Still, we are not trying to introduce a new requirement for the server
so that "it should honor the hint whenever possible", right?  There
might be a special reason in the case the prefix length hint, but at
the moment I don't see it in draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
beyond some imaginary problem.

So, I'd first like to see what's actually the problem and be convinced
that's certainly a practical operational problem specific to hints for
the prefix length (but not for other types of hints) that has to be
solved at the protocol level.  Otherwise, I'd not even see the need
for publishing this document in the first place, let alone whether
it's standards track or informational.

--
jinmei

---

From: tianxiang li <[email-masked]>
Date: Sat, 30 Apr 2016 09:51:02 +0800

Hi jinmei，

Thank you reviewing the document and providing your comments. Unlike other
hints such as T1 T2 lifetimes, which could be easily ignored by the server,
completely ignoring the prefix-length hint would cause some functional
issues for the client, how the prefix-length hint should be handled is a
bit more complicated, and it should be given more considerations. We
believe there is actual requirement for some ISPs to clarify how it should
work, and understand the expectations of the client and server. E.g. If a
server has an existing binding for a prefix length different from what the
client is currently requesting, what should it do? This is the case when
the client changed its home router configuration and it needs a shorter
prefix. Also, if a client didn’t get the prefix it wanted, should it
continue to ask for the preferred prefix (during Renew/Rebind)? Or should
the server remember what the client originally requested, and assign it a
new prefix if it should become available? These are some issues we are
trying to clarify in the document, so that servers which DO want to
understand the client’s actual prefix requirement, would know how the
prefix-length hint should be handled, to make it work well. I'm not sure
whether there is the same problem for addresses, it might be something
worth discussing.

Best regards,
Tianxiang