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 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.

Regards,
    Brian