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

[神明達哉 <[e-mail]>]

At Thu, 21 Apr 2016 16:45:17 +0000,
"Bernie Volz (volz)" <[e-mail]> 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:

[...]

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

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