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

["Joel M. Halpern" <[e-mail]>]

Mark, it has been approved by the IESG for publication.  We had a WG 
last call.  An IETF last call.  An IESG review.  It is in the RFC EDitor 
queue for publication.  While we could theoretically call it back, there 
would have to be an overwhelming reason.

Yours,
Joel

On 3/6/2020 9:17 PM, Mark Smith wrote:
> Hi Joel,
> 
> On Sat, 7 Mar 2020 at 13:12, Joel M. Halpern <[e-mail]> wrote:
>>
>> I think there is a difference between
>> AH Is optional in all IPv6 implementations and deployments
>>       and
>> A standard may be incompatible with AH.
>>
>> Having said ath, we approved SRH knowing it was incompatible with AH.
> 
> I don't think 6man or the IETF have "approved" it. It's still a 6man
> WG Internet Draft.
> 
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26
> 
> 6man could abandon it just like "IPv6 Router Advertisement IPv6-Only
> Flag" was, due to lack of consensus during WG last call.
> 
> Regards,
> Mark.
> 
> 
>> So whether I think that makes sense or not, we live with it.  (In this
>> context, we is both 6man and the IETF as a whole.)
>>
>> Yours,
>> Joel
>>
>> On 3/6/2020 9:04 PM, Brian E Carpenter wrote:
>>> Tom,
>>>
>>>> I don't understand what you mean by "AH is optional" in this context.
>>>
>>> AH is optional in *every* context. So it's completely legitimate for
>>> the SRH architecture to state that AH is not used in SRH domains. It
>>> might be used in packets that are encapsulated for transit across an
>>> SRH domain, but that's fine.
>>>
>>> I thought this was clear when we persuaded the SRH community to drop
>>> insertion and specify encapsulation.
>>>
>>>       Brian
>>> On 07-Mar-20 10:00, Tom Herbert wrote:
>>>> On Fri, Mar 6, 2020 at 12:17 PM Brian E Carpenter
>>>> <[e-mail]> wrote:
>>>>>
>>>>> 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.
>>>>
>>>> Brian,
>>>>
>>>> I don't understand what you mean by "AH is optional" in this context.
>>>> AH is certainly optional to send by source nodes, however if it is in
>>>> a packet then I don't see how intermediate nodes have the option to
>>>> knowingly break AH. This is precisely why declaring what data in
>>>> header fields is mutable in flight is so important. This isn't just to
>>>> make AH work, but enforcing that the network doesn't arbitrarily
>>>> modify packets in random ways is one of the reasons why AH is needed.
>>>>
>>>> (If you were to say that AH isn't a problem because it will never be
>>>> in the same packet as and SRH, then I will have to point that SRH does
>>>> not preclude that possibility. IMO, until the combination is expressly
>>>> prohibited, intermediate nodes are subject to "be liberal in what you
>>>> receive" in this regard)
>>>>
>>>> Tom
>>>>
>>>>>
>>>>>> 3) It is also clear that what is specified in SR PGM does not work across administrative domain or on the general Internet.
>>>>>
>>>> That's the limited domain argument which as pointed out several times
>>>> is not a normatively defined construct in IETF. Without such a
>>>> definition I don't see how requirements pertaining to IPv6 can take
>>>> this into account (i.e. we can't update RFC8200 with requirements that
>>>> would only be applicable in a limited domain without defining limited
>>>> domain).
>>>>
>>>>> 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
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> [e-mail]
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------