Re: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

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

On 2018-10-22 09:25, Nick Hilliard wrote:
> Ole Troan wrote on 17/10/2018 22:48:
>> If you believe there are comments within the scope of the draft that
>> hasn’t been addressed I suggest you bring them back to the list.
> Ole,
> 
> Almost the entire discussion surrounding the ipv6only-flag draft and its 
> predecessors has been notable in that the authors either fully ignored 
> the technical feedback on the wg mailing list, or acknowledged feedback 
> but left it either partly or wholly unaddressed in the document.
> 
> Here's an example.  Drafts -00 to -02 contained the following:
> 
>>    o  In particular, this may overload switches in multi-segment
>>       wireless networks because it will create IPv4 state for every dual
>>       stack host.
> 
> I posted an analysis on Sep 8 
> (https://mailarchive.ietf.org/arch/msg/ipv6/Yoy1Bo8A6WiRryqogTfr_R7FH9I) 
> which went into some nuances about how switches work in the context of 
> forwarding ipv4 frames, but the summary was:
> 
> "...layer 2 switches do not carry ipv4 state in any meaningful sense. 
> It is technically misleading, bordering on flat-out incorrect, to 
> suggest otherwise."
> 
> The draft was then updated from:
> 
>  > this may overload switches [...] because it will create IPv4 state
> 
> to:
> 
>  > this may overload switches [...] if the switches create IPv4 state
> 
> I'm at a loss as to how to respond to this other than to say that 
> switches don't create ipv4 state 

Wait, are you saying that no switches contain ARP caches? That would
truly surprise me.

> and that it is disturbing to have to 
> explicitly state something so fundamental in an IETF working group, 
> particularly in the context of statements like: "the authors think that 
> all your points are in fact dealt with in the text".
> 
> This is just one example from the draft, but there are several others, 
> some as egregious as this.
> 
> What's happened now is that a new revision of the draft has been posted, 
> and the process of posting it seems to have white-washed all the 
> outstanding technical issues.

If by "white-wash" you mean "observe that they are side-issues for
the proposed mechanism", you'd be right. This isn't about the best way
to ensure IPv6-onlyness of a link; it's about one particular mechanism
towards that goal. We could say less, or nothing at all, about other
such mechanisms.

The WG may of course conclude that the mechanism isn't worth the bother.
If that's the conclusion, the draft will not advance.

> The onus of bringing these issues back to 
> the working group has been piled on the plate of those who made the 
> arguments in the first place, after having had them repeatedly dismissed 
> any time they were brought up before.  This is not ok.
> 
> None of the issues I've brought up have been addressed properly.  

IMO this draft is not the place to do so. Some other (v6ops?) document
about how to operate a v6only link would be the place for that.

   Brian

> As far 
> as I'm concerned, they all remain open and the onus should be on the 
> authors to address them.  There's a mailing list archive and it's 
> searchable.  They need to do the work on this one.
> 
> Nick
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>