Re: [v6ops] Making RDNSS a MUST?

[Brian E Carpenter <[e-mail]>]

Doug,

A few points, on three of your messages:

On 03/04/2017 08:02, Doug Barton wrote:
> On 04/01/2017 09:02 AM, Brian E Carpenter wrote:
>> I was actually arguing that making them both a MUST implement is "more"
>> valid because it increases that chance that an arbitrary host will work
>> on an arbitrary network.
> 
> No, it wouldn't, because "MUST support" is not the same as "MUST 
> provide." And people are going to continue configuring their network the 
> way they want to in any case.

Your understanding of statistics and probability seems to be a bit different
from mine. What we have out there is, in practice, a random mixture of hosts
of all ages connected to a random mixture of better or worse managed networks
using routers of all ages. All I'm saying is that the more implementers are
chivvied in the direction of implementing both solutions, the more
interoperability we will get, statistically, over the next decades. That is
true precisely *because* operators will configure their networks the way
they want to, not the way some RFC says.

On 03/04/2017 08:05, Doug Barton wrote:> On 03/31/2017 12:18 AM, Simon Hobson wrote:
>> Doug Barton <[e-mail]> wrote:
>>
>>> People who like it can implement it, people who don't, shouldn't
>>> have to.
>>
>> But that is the whole problem ! As referenced some time ago, in the
>> real world there is a problem where there are two ways of providing
>> the information, and two ways of getting it. If router only does A
>> and device only does B then device doesn't get DNS info; similarly if
>> router only does B and device only does A then device doesn't get DNS
>> info; in either case the problem is that you've connected a device to
>> an IPv6 network and "it doesn't work".
> 
> Yes. That was the completely predictable result of the introduction of 
> new options to SLAAC beyond RA, and the core objection made by those of 
> us who have been opposing additional such options for over a decade.
> 
> I've snipped the rest of your message because we all know how we got 
> here. We have created this mess by allowing the anti-DHCP crowd to run 
> the asylum. We need to stop letting that happen.

That is grossly unfair. My recollection is that RDNSS was added not as
an anti-DHCP provocation, but because we have always had a target "market"
for IPv6 that we referred to in the early days as the "dentist's office
scenario" where people with zero skill could plug stuff together and
it would work. Given SLAAC, the only missing link for that sceanrio was
DNS server configuration, and that is why RDNSS was specified. And it
works.
On 03/04/2017 08:52, Doug Barton wrote:
> On 03/31/2017 05:28 AM, Brian E Carpenter wrote:
>> Doug,
>> On 31/03/2017 16:17, Doug Barton wrote:
>>> On 3/29/2017 4:08 PM, Lorenzo Colitti wrote:
>>>> Given the discussion today on draft-gont-v6ops-host-configuration and
>>>> draft-ali-ipv6rtr-reqs , I'm wondering if we might find consensus to say
>>>> that host and router implementations MUST implement RDNSS.
>>>
>>> No.
>>>
>>> People who like it can implement it, people who don't, shouldn't have to.
>>
>> The word "implement" is hopelessly ambiguous.
> 
> No, it's a term of art, that I chose with great care. Completely aside 
> from my long experience in the IETF, my term as GM of the IANA (which 
> partially overlapped your term as IETF chair), and my 17+ years as a 
> FreeBSD developer; frankly I'm a little bit insulted that you didn't 
> assume that I was using it both correctly, and intentionally. OTOH I 
> can't expect everyone to keep everyone's resumes in mind all the time, 
> so I forgive you. :)

My observation is that the word "implement" is ambiguous. I have often
heard or seen it used such that it was impossible to know whether
it meant "write the code" or "switch it on."

>> As far as a vendor or open source developer is concerned, the suggestion
>> is that they MUST include code for both methods. I'd be a bit more precise
>> and add that they MUST both be enabled by default in hosts, and at least one
>> MUST be enabled by default in routers, and they MUST be individually configurable
>> on or off in all nodes.
> 
> This is a terrible idea, for all of the reasons that I have expressed 
> already today. Most importantly for the reason that the IETF should not 
> be pushing the cost of its own inability to get its act together onto 
> vendors.

We've specified doing the same thing in two different ways. What we haven't
done, evidently, is describe the scenarios in which the two solutions are
more, or less, appropriate. That's a gap.

    Brian