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

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

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.

Regards
   Brian