Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

["Joel M. Halpern" <[e-mail]>]

I disagree with your interpretation of the bar the document must meet.
I believe I have clearly stated my concern.
I will leave that judgment to the relevant ADs and IESG when they review 
the last call results.

Yours,
Joel

On 2/17/17 12:39 PM, [e-mail] wrote:
> Joel,
>
>> I am not sure what youa re asking with either of your quesitons.
>>
>> With regard to question 1, you seem to be asking whether we have seen folks adding EHs, and whether it has been observed to cause difficulties.  We have seen folks trying to standardize exactly such additions.  So I presume they have already implemented them.  And we have seen folks explaining a range of cases where it causes problems.
>
> No, that's not what I'm asking.
> I'm asking if an implementor of the 2460 specification has interpreted the text as ambiguous and if that has led to interoperability issues.
> The answer to that is no.
>
> Do you see my point here? That this point is important for advancing RFC2460. There is no shown ambiguity that has had any consequence for 2460 implementors.
>
> Header insertion just doesn't exist in the context of implementing 2460.
>
>> With regard to 2, you seem to be you seem to be constructing a very odd reading of an RFC.  Some people have clearly said that they read the existing RFC as permitting additions of EHs.  That is not a matter of future RFCs, but of current readers.  Other people have said that they read the text as clearly prohibiting such behavior.  Which would at a minimum mean that any IETF effort to change it would be required to explain why it was acceptable and interoperable to change the rules.
>>
>> Given that the existing wording has been interpreted in different ways by different people, and that there is good reason to beileve that the differing interpretations will (if they have not already) cause interoperability issues, it seems to me incumbent on the WG to be clear about what it means.
>
> Can you please explain how that can create interoperability issues? An implementation of 2460 does not do header insertion.
> You must be talking about some future specification (there are drafts) that specify header insertion.
> _Those_ specifications will create interoperability problems. I think we should not standardise those.
>
> Sure you could ban NAT's, ECMP and header insertion, and whatever else you can imagine in 2460, but how exactly is that going to prohibit anyone from writing the above set of specs? We're not writing law, we're writing interoperable protocols.
>
> Cheers,
> Ole
>