Re: [spring] draft-ietf-spring-srv6-network-programming-20: and updating 8754?

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

With regard to the 8200 issue, I consider that I am bound by the IESG 
decision on your appeal.  I understand you disagree with their 
conclusion.  That is between you and them.

With regard to the issue of behavioral change, 8754 is explicit that 
other documents can define other behaviors.  That does not change the 
behaviors defined in 8754.  As such, I am having trouble following your 
reasoning as to why the network programming draft changes 8754.  The NP 
draft does not change the processing rules for the behaviors defined in 
8754.
When one combines that apparent separation with the lack of specificity 
or community agreement on how to clarify "updates" tags, I do not see 
how you can insist that NP needs to be marked as updating 8754.  If the 
IESG decides that they think it should be marked as updating, then we 
will so mark it.

Yours,
Joel

On 10/1/2020 9:18 PM, Fernando Gont wrote:
> Hello, Joel,
> 
> If this document is specifying a behavior that deviates from RFC8754, 
> then it's hard for me to understand why this document should not be 
> updating RFC8754.
> 
> Otherwise, it essentially means that one can violate an existing 
> specification at will by simply packing the new behavior with other 
> things that comply with the spec.
> 
> One would expect that the behavior of a protocol can be explained and 
> understood by reading the core spec and all updating documents.
> 
> This document not only seems to go outside of Springs charter, but also 
> seems to be updating a bunch of core implications "under the hood", 
> creating not only an specification mess, but also a very bad precedent.
> 
> RFC8754 is one example. The this document also specifies behavior (PSP) 
> for nodes that fail to comply with a core spec (RFC8200) on which this 
> document is based. And the same is true for other core documents.
> 
> This seems to me like setting a really bad precendent.
> 
> Thanks,
> Fernando
> 
> 
> 
> 
> On 1/10/20 15:53, Joel M. Halpern wrote:
>> First, there is a lot of disagreement and vagueness about when one 
>> should mark an RFC as "updating" another RFC.  So it would be hard for 
>> me to claim that you are wrong.  But it would also be hard to claim 
>> that what you propose is necessary.
>>
>> In this particular case, my reading as shepherd is that the changes 
>> relative to 8754 apply only when this document is being implemented.  
>> If one is not implementing the behaviors in this document, one does 
>> not need to worry about it when implementing 8754.  Based on that and 
>> my understanding of "updates", I would not expect this document to 
>> assert that it updates 8754.
>>
>> Yours,
>> joel
>>
>> On 10/1/2020 3:10 AM, Fernando Gont wrote:
>>> Pablo & IESG,
>>>
>>> May I ask why, if you are going against RFC8754, you do it in this 
>>> documents as opposed to formally update RFC8754?
>>>
>>> Put another way: what was the point of 6man (and eventually the IETF) 
>>> of standardizing RFC8754 if then this document is going to change the 
>>> spec without formally updating it?
>>>
>>> Thanks,
>>> Fernando
>>>
>>>
>>>
>>>
>>> On 30/9/20 10:18, Pablo Camarillo (pcamaril) wrote:
>>> [....]
>>>> ...
>>>>> (1b) It would be nice if the behavior in §4.1.1 were also
>>>>> specified using pseudocode. As written, I am not sure if the intent
>>>>> is to process any upper-layer header or only specific ones. Is the
>>>>> objective for this operation to be similar to the one in
>>>>> §4.3.1.2/rfc8754? Please be specific on what is meant by "allowed
>>>>> by local configuration".
>>>>>
>>>> [PC] Yes, we can structure the text in 4.1.1 in pseudocode form. The
>>>> [PC] processing is not the same as RFC8754/Section 4.3.1.2. The
>>>> “allowed by [PC] local configuration” is to enable the processing of
>>>> only specific types [PC] of Upper-layer Headers for packets addressed
>>>> to an SRv6 SID of the [PC] specific behaviors. E.g. An operator may
>>>> not wish to have BGP sessions [PC] (or in general any TCP traffic)
>>>> destined to a local SID, but may want to [PC] enable ICMPv6 packet
>>>> processing for OAM purposes.
>>> [....]
>>>
>>>
>>>
>>
> 
>