RE: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt

[Morizot Timothy S <[e-mail]>]

Brian E Carpenter [[e-mail]] wrote:
> On 17/07/2017 03:36, Morizot Timothy S wrote:
> > I’ve commented on this topic in the past, but will simply make one more
> observation on this specific point. The RFC is informational
> 
> That's our choice. I think that with IPv6 being at Full Standard,
> it's time to open the debate about whether 6434bis should be a BCP.
> 
> > so isn’t a matter of huge concern as it has no impact on product selection or
> the procurement process.
> 
> Only for customers who treat RFC status as holy writ. Many people are
> more realistic and will use an RFC called "Node Requirements" as
> a requirements checklist.

Sorry, I realized that comment didn't clearly state what I was thinking. I meant if it were a standards document specifying that DHCPv6 only networks, a perfectly valid configuration in the standards to date, were not recommended (in any context) or a standards document specifying that DHCPv6 as a protocol was not recommended, then I would have more concerns over the state of the document. It wouldn't change anything in operational configuration or practice, but would clearly be a more significant issue. Given that this is an information recommendation for host developers, it has no direct impact on those purchasing or otherwise electing to use said hosts. Even if it were a BCP (which would be odd to call something a "common practice" of any sort if it didn't recommend host developers consider DHCPv6 support since many hosts do support it today), that would have little impact since as those purchasing or electing to use "hosts", we write our own requirements for them. So I was really just trying to note that I was commenting from the perspective of those who specify requirements for procuring host devices, not from the perspective of those who develop said devices.

From that perspective, since hosts may very well find themselves excluded from consideration by some sorts of large enterprises if they do not support DHCPv6, a document aimed at their developers makes more sense if it notes they should consider supporting DHCPv6. The developer may decide it doesn't fit their model or the host may be a very special purpose IOT sort of host which in a large enterprise may be segregated into its own network anyway. Given that, the change to SHOULD seems to make a lot more sense than what people may have thought when 4294 was written. (Again, from the appendix of this bis, it looks like that's what is actually be updated in the revision.) Doing anything else looks like pretty poor advice to developers of hosts, again from my perspective. And from my operational experience, many hosts support DHCPv6 and DHCPv6 only networks just fine today, whatever the current recommendations might say. Updating the recommendations to reflect reality seems reasonable.

Scott