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

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 01 October 2020 18:53 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935CA3A0E48; Thu, 1 Oct 2020 11:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIkCCQQI-wDB; Thu, 1 Oct 2020 11:53:34 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA483A0E45; Thu, 1 Oct 2020 11:53:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4C2Mhs5TT3z1nvmj; Thu, 1 Oct 2020 11:53:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1601578413; bh=lkgyuWKSBXGjWFMzNMFtR1ORcvK9NUpj39dxybZ7988=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GvCPD9TYkIy4EqpDnCvMUT+zy6rcm3GPQG6YS1hRUTQ5L6DaomnN4/lfi8GcsUSkC WZs+2ddPAgcNAFL8bpiwZiiCaESBtghXT6IOVaZEUL95zDNsTV5U/v2EbtPQt0MeAo Wdo0mqAWbFlbq1zX4/yj3PyQr66LApslWB2PtTjk=
X-Quarantine-ID: <c0Ta52d6HoXf>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4C2Mhr3Krsz1nsKM; Thu, 1 Oct 2020 11:53:32 -0700 (PDT)
To: Fernando Gont <fernando@gont.com.ar>, "Pablo Camarillo (pcamaril)" <pcamaril=40cisco.com@dmarc.ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: "spring@ietf.org" <spring@ietf.org>
References: <160089467694.11025.16329903730475278493@ietfa.amsl.com> <MWHPR11MB137441B3AF475B48CC89AAC9C9360@MWHPR11MB1374.namprd11.prod.outlook.com> <CAMMESsyw8ZV5_yuH1HdqHi222YvzbY7gzippZjnWPiceV9wpog@mail.gmail.com> <MWHPR11MB1374919BDD110601CB50FFDDC9330@MWHPR11MB1374.namprd11.prod.outlook.com> <d222e745-d7e2-3d03-26b1-c43241ca4dfc@gont.com.ar>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <b5ca1c7e-c776-c77f-c4a2-8b1bc86990df@joelhalpern.com>
Date: Thu, 01 Oct 2020 14:53:31 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <d222e745-d7e2-3d03-26b1-c43241ca4dfc@gont.com.ar>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/MCU_wo4q5mT4bNwrEcliE1iujAQ>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming-20: and updating 8754?
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2020 18:53:36 -0000

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