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

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

Comment at the end...

On 07-Dec-19 14:31, Fernando Gont wrote:
> 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

Well, 6man has no current work item on EH... except draft-voyer- or
draft-smith-, if we choose to adopt one or both. (In case it isn't
obvious, where we are right now is in a discussion *before* considering
WG adoption, since there's been no adoption call from the chairs.)

>  -- or for instance, existing standard.

The rules for independent submissions don't forbid that, but they do
require that it is stated:
https://tools.ietf.org/html/rfc4846#section-2
"Any submission that constitutes an alternative to, or is in conflict
with, an IETF Standard or proposal for Standards-Track adoption must
clearly indicate that relationship."
And of course the IESG is given a chance to review the draft according
to RFC5742.

   Brian