Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

[Fernando Gont <[e-mail]>]

On 10/24/18 12:09 AM, Suresh Krishnan wrote:
> Hi Tim,
> 
>> On Oct 23, 2018, at 5:24 PM, Tim Chown <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>> On 23 Oct 2018, at 19:26, Suresh Krishnan <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>> On Oct 23, 2018, at 2:05 PM, Sander Steffann <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Changed the subject because this discussion is now moving away from
>>>> any specific draft.
>>>>
>>>>> That's kind of my take, as well However, I think that asking for an
>>>>> implementation of the ipv6-only flag is a requirement that I have never
>>>>> seen for taking new work or publishing it, so it would be unfair to ask
>>>>> that to the authors of this particular I-D.
>>>>
>>>> I'd like that to become the norm though. Having a running prototype
>>>> can help enormously when writing specifications. My preference would
>>>> be to move back to a base principle of running code and rough
>>>> consensus, instead of only rough consensus.
>>>
>>> If the WG decides to go on this path, I will be fully supportive of
>>> that. This model has worked out well for idr (see
>>> https://trac.ietf.org/trac/idr/wiki#ImplementationRequirement). What
>>> I am uncomfortable with is that criterion being *selectively* applied
>>> to this draft as a prerequisite for progress. 
>>
>> I think there are good grounds in this case.  There is (apparently) no
>> vendor interest, but it's also a very vague document, where if any
>> vendors do decide to implement, it's highly likely that those
>> implementations will result in different host behaviour.  
> 
> I think it would be better to clear up the vague pieces so that we can
> have a reasonable conversation about the draft. I personally think just
> the existence of an implementation is not a sufficient step to clear
> this up. Let me give you an example to show why I think so. I had an
> implementation of the M and O bit flags on the router side and I have
> seen several implementations of the flags on the host side, but the
> results were still a crapshoot. You could not tell up front for a given
> combination of the flags what a host would do. I have had customers ask
> me “I want the host to use stateless DHCPv6 to get config information
> but I do not want them to try to use stateful DHCPv6 (IA_NA)”. I told
> them to use M=0 and O=1 but the results were all over the place. 

Well, yes. A bit orthogonal, but: Automatic configuration is a bit of a
mess. That's why I asked about "architecture" in a different thread. It
all looks like many folks don't expect DHCPv6 to be actually used, and
whenever there's something DHCPv6 might be useful for, the functionality
is replicated  into SLAAC. Still, DHCPv6 continues to be actively
developed (and dhc wg operating).



>> Thus exploring interpretations of the draft on specific platforms, and
>> observing the resulting behaviours and interactions, seems a pretty
>> prudent step.  This may help refine the draft to be more specific, and
>> uncover perspectives that as yet have not been considered.  It's not
>> like the draft needs to be rushed through quickly.

That's why I noted that, in order for this to be of use, we should
expect all hosts to react in the same way, modulo some cornercases. BUt
many folks assume that in the short term, the "exceptions" to the
"SHOULD" in ipv6-onlyflag will rule, and that will eventually change in
the future. FWIW, that doesn't seem to be a good outcome.


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492