Re: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)

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

Ole,

On 07-Mar-20 02:24, [e-mail] wrote:
> [spring cross posting deleted]
> 
>>> - Read the mailing list and you will see that everyone do not share your opinion. So at least one person is wrong. I think that it would help if everyone, including you, could consider that they/you _may_ be wrong, at least to better understand the comments been made by others.  And possibly the text from RFC 8200 is not clear, but this is what we have. And this is the text to use to support the claim that this text is violated.
>>
>> The final interpretation and intent of text in RFC8200 should be up to
>> 6man, not SPRING, when there is ambiguity and dispute, as 6man is the
>> ultimate design authority for IPv6.
>>
>> RFC5704, "Uncoordinated Protocol Development Considered Harmful":
>>
>> " In particular, the
>>   IAB considers it an essential principle of the protocol development
>>   process that only one SDO maintains design authority for a given
>>   protocol, with that SDO having ultimate authority over the allocation
>>   of protocol parameter code-points and over defining the intended
>>   semantics, interpretation, and actions associated with those code-
>>   points."
>>
>> IETF WGs would qualify as standards development organisations.
>>
>> Those of us in 6man during the clarifications in this area of RFC8200
>> know the intent. It was specifically about modification of the EH
>> chain, and was in response to the
>> 'draft-voyer-6man-extension-header-insertion' Internet Draft.
> 
> No, it is the IETF that is the SDO and has that authority through IETF consensus.
> Not the working group.

Absolutely. And that means: IETF consensus as judged by the IESG, subject to the RFC 2026 appeal process. 
> Let me summarize my take on this from a 6man perspective:
> 
> 1) PSP violates RFC8200.
> I also object to any statement in SR PGM that it is in "compliance with 8200". It specifies it's own unique EH handling.

It doesn't use the word "compliance" which is rather loaded in standards-speak. It now says:

  "This behavior does not contravene Section 4 of [RFC8200] because the
   current destination address of the incoming packet is the address of
   the node executing the PSP behavior."

Like it or not, that's what we published. Whether it's what we meant is another question.

> As I state below that's perfectly fine.
> 
> 2) A premise for the work on tightening extension header processing rules leading up to 8200, was that new specifications can specify different behaviour than what's defined in 8200.
> That is what the SR PGM document does. Any specification that changes EH processing must specify how that processing is done, and must be technically sound, in that it is shown not to break anything (interoperability, PMTUD, end to end security etc).
> The SR PGM document has been terse in it's description and how it deals with identified technical issues. But it is also clear, that it is specified to only work within a limited domain, where the source, destination and in-path nodes are all within the same domain of control.
> I see no outstanding technical issues with that mechanism.

After a lot of thought, I agree with that. It's known not to work with AH, but AH is optional. It cannot break PMTUD because it only makes the packet smaller. And I am told it doesn't break OAM.

> 3) It is also clear that what is specified in SR PGM does not work across administrative domain or on the general Internet.

In fact, the whole of SRH is intra-domain, as specified by RFC8402.

> For that reason I would object to any modification to 8200. Be it erratum, updated by pointer or bis document.

I think there's an established weakness in RFC 8200. We could decide to live with it, as we live with weaknesses in RFC 791. 
 
> Is is possible to come to some agreement and consensus on the above points?

That beats me ;-)

    Brian