Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt

The way this stuff works is that we (the IETF) make a recommendation based
on what the most common use case is, and make the recommendation open
enough that it covers the less common use cases, or else enumerate expected
use cases and make recommendations specific to each case.   In this case,
the text falls into the first category.   It would be totally inappropriate
to deprecate IA_NA on the basis of this text.   As far as I know, no such
plan is afoot in the DHC working group.   It would also be inappropriate to
make that change in this working group.   :)

On Tue, Jul 18, 2017 at 7:57 PM, Scott Morizot <tmorizot@gmail.com> wrote:

> On Tue, Jul 18, 2017 at 9:41 AM, james woodyatt <jhw@google.com> wrote:
>
>>
>> It’s not at all clear to me what is the purpose of this draft, but if I
>> understand correctly, then its objective is to propose that IETF Best
>> Current Practice include general purpose Internet networks where general
>> purpose hosts acquire IPv6 interface addresses only by using DHCPv6 IA_NA
>> requests to obtain addresses from a constrained pool one at a time. I have
>> a lot of difficulty seeing how that makes any sense given the clear
>> reasoning provided in RFC 7934 for the recommendation against it.
>>
>>
> I have no particular problem with that as a recommendation for general
> purpose Internet networks if the recommendation is intended to exclude a
> significant chunk of the enterprise network world. For a general purpose
> network meant to support devices controlled and operated by other parties
> from the network operators, it may even be a fine recommendation. (That's
> not really my world, so I can't say.)
>
> I think this came up, if I tracked discussions properly (a big if),
> because this recommendation for address assignment in general purpose
> networks was used as one of the reasons to fight against recommending that
> node developers should support DHCPv6 elsewhere. Again, not really a
> node/client developer except in the past for some limited in house things,
> but that strikes me as bad advice to that group depending on their target
> user. Of course, I don't really think such developers are going to rely on
> an IETF recommendation to decide which features they need to incorporate
> anyway. Or at least not solely. So that's why I don't feel too strongly
> about it either way.
>
> I would object more strenuously if someone were actually trying to change
> the actual DHCPv6 protocol standard to eliminate IA_NA/IA_TA, but I believe
> there would be a chorus of objections to such a move anyway, so I'm not
> particularly concerned about that.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>