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

[[e-mail]]

Hi Brian,

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

I _think_ I would be happier if that paragraph was deleted.
And replaced or pointing to text describing the behaviour.
(The reason for that is that I don't want that particular reading of the 8200 paragraph to set precedence.)

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

And we also say (cut and pasted): "are not processed, inserted, or deleted by any node along a packet's delivery path".
But regardless of that, my suggestion was that it shouldnt' matter if it contravened or not. As long as the proposed solution was technically sound standing on it's own feet.

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

As long as it states that, and there are no other technical objections I think that is fine.

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

You might be right. Although I think that we cannot modify our documents on every occasion someone wants to do something.
In that case they must go off and write a document. And if there is consensus on that, well so be it.
(Even if that is MPLS labels in the flow label field, or semantic addressing. :-))

>> Is is possible to come to some agreement and consensus on the above points?
> 
> That beats me ;-)

Well, you didn't sound like you disagreed too much. That's a start. ;-)

Have a nice weekend!
Ole