Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

[Fernando Gont <[e-mail]>]

On 6/12/19 21:07, Brian E Carpenter wrote:
> On 07-Dec-19 12:22, Tom Herbert wrote:
>> On Fri, Dec 6, 2019 at 2:57 PM Brian E Carpenter
>> <[e-mail]> wrote:
>>>
>>> On 07-Dec-19 10:22, Fernando Gont wrote:
>>>> On 6/12/19 17:55, Brian E Carpenter wrote:
>>>>> Joel,
>>>>>
>>>>> On 07-Dec-19 04:09, Joel M. Halpern wrote:
>>>>>> Ole, there is no IETF accepted definition of "limited domain".
>>>>>> There is no IETF rough consensus that it is sensible for us to
>>>>>> standardize things for "limtied domains".
>>>>>
>>>>> That's correct, and that's exactly why the "limited domains" draft
>>>>> was submitted to the Independent Stream. It is a fact, documented in
>>>>> that draft, that quite a lot of chartered IETF work is directed at
>>>>> limited domains.
>>>>
>>>> I'm not necessarily arguing against your point. But I'd note that, when
>>>> it comes to IETF consensus, there's no such a thing as "limited
>>>> domains", and IPv6 is IPv6 -- we don't have any concept of "IPv6 for the
>>>> capital 'I' Internet" and "Modifications for closed domains".
>>>>
>>>> IIRC, I did support your document on int-area (?). So it is not that I'm
>>>> against the concept of limited domains. Just noting that, as
>>>> IETF-conseusns, there's no such a thing.
>>>>
>>>> That said (and without re-looking at your document right now), there's a
>>>> difference between a protocol being effectively employed in a limited
>>>> domain (mDNS, if you wish), vs something like this, in which you are
>>>> *hoping* that your changes don't leak out of your domain... but in fact
>>>> you are not really operating in a limited domain if the src/dst
>>>> addresses of packets span past your "limited domain".
>>>>
>>>>
>>>>
>>>>
>>>>>> While there are standards that are designed for specific deployments,
>>>>>> they do not to date use that as an excuse to violate existing RFCs.
>>>>>
>>>>> I'm not sure that statement is literally 100% correct, because some instances
>>>>> may well have passed unnoticed or without controversy. SRH insertion
>>>>> has not tried to pass unnoticed, and has become controversial.
>>>>
>>>> My own impression is that it did try to pass unnoticed.
>>>
>>> draft-voyer-6man-extension-header-insertion-00, a document that I strongly
>>> criticised, came out March 28, 2017 and its first sentence read "The network
>>> operator and vendor community has clearly indicated that IPv6 header insertion
>>> is useful and required." I *really* think that your impression is wrong. This
>>> has been public for almost 3 years now.
>>>
>>>> Even the latest
>>>> rev of the EH insertion draft doesn't even have a reference to RFC8200.
>>>
>>> Well, the current document editor already said that will be fixed.
>>>
>>>> And if you've read the initial exchange that triggered all other
>>>> comments, an author (?) was kind of trying to educate Ron about the
>>>> document not doing eh insertion/removal.
>>>>
>>>>
>>>>
>>>>
>>>>>> Hence, as far as I can tell, the assertion that SRv6 is for limited
>>>>>> domains does not justify or excuse violating RFC 8200.  And "I want to
>>>>>> save some bytes", while very nice, is not a sufficient reason to violate
>>>>>> an approved RFC, must less a Full Standard.
>>>>>
>>>>> On the other hand, running code in a variety of real and deployed
>>>>> products is something that we have a long tradition of documenting forEven the latest rev of the
>>>>> informational purposes. RFC1094 or RFC3954 for example.
>>>>
>>>> Major difference: None of the two protocols you've reference do an
>>>> outright violation of an IETF standard --- even less an Internet Standard.
>>>
>>> That wasn't my point. (If you want an example that does violate an IS, try RFC1631.)
>>>
>>> My point is that we have often document reality.
>>>
>> Brian,
>>
>> This would seem to establish the blueprint as to how a large vendor
>> can do whatever they want: simply write your protocols however you
>> wish, put it into products and get some deployment, and then take it
>> to IETF to publish as being a "de facto" standard that can't be undone
>> since it's already a reality. What a great way to circumvent the
>> standards process!
> 
> As Joel pointed out, many of the historical cases would be Independent
> Stream submissions today. But yes, the mechanism you describe was invented
> about 30 years ago as far as I can tell. In the end, running code wins.
> We got TLS that way, for example.
> 
> If draft-voyer- ends up published in the Independent Stream, that
> would be fine by me.

I wonder how the EH insertion document does *not* conflict with the work
of any existing WG -- or for instance, existing standard.

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