Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 07 December 2019 02:48 UTC

Return-Path: <brian.e.carpenter@gmail.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 B856D120110; Fri, 6 Dec 2019 18:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 T843JRLCs4HV; Fri, 6 Dec 2019 18:48:01 -0800 (PST)
Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F511200C4; Fri, 6 Dec 2019 18:48:01 -0800 (PST)
Received: by mail-pf1-x442.google.com with SMTP id q8so4310031pfh.7; Fri, 06 Dec 2019 18:48:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XV3Zh/6r+8DS4/js0lrj0K2qNwUGkz3zRYHUAdX8QWA=; b=TQ5xYN1qE5aS+h+kVVL0cTCVrEP9L+x04mpgUMPYPcWCQbC2CAvUstEz6ZRx8+xaW0 6Ts5YospyejUZfZGhG7E94Ewx77djNqerODWvMxmPEnUgC+wvB3qPI1/nUfxQplfED1h vgJJWdR0uUSPchRwp7TiNQ4qLQSINGkRP3cX8q2gcy5QESuQeUVi3hlIQnxGKw3ZOT32 /kyQpnbJdtu7Lhr++KZIUazqvTHKOilB1FLjdHjcUTFNO+jwfxYZYfQ/qlhZZhF1kPBl PZoFXpAipUBcOrE/k12ZzyQ8O5IBPkXKRB3Zu8iuz9/OuxdjiKZ1OHu2cawnfO2FYhBh Wmxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XV3Zh/6r+8DS4/js0lrj0K2qNwUGkz3zRYHUAdX8QWA=; b=nqf4R8pNn6erRa0Jl3mMSwGzyOFW1Rmf0MmwyjksClKRx10TfD5gBcoa7tgvD9MPHh nroAKaEAktRKy383HMY8hYwW0XCx2RSGVwHdEcFnPFgbPsqWs4Jz+9WPUArPBFUuxUIw PBTUjl60INWzxIQNrXX8Nf7DBYZ0BCl2JTtkhOgbLwtLIJUBNL+UKetTtlQb7AuR+AaY lTUrYapU1QnyiCdxaw+EnjloKAktW7d5Ky2HZDsBOpHxw6T0BCPCEIl60Y2lqBT7D+82 KddCMcZSNCzVWT+azEFDTc2/OGMWL+RLQkC3/sdacV5dXXdrQh9QEWxJ43WB3hkpZ2MX 7W2Q==
X-Gm-Message-State: APjAAAUXViZIM/W/eh5kIxiz8+IVJc/Rwi8KjadUcsgmoBcFOOZVumPU 91nwBymdKoSVqgk5PNJs44W01tHO
X-Google-Smtp-Source: APXvYqy6Vxe7ZdldNvmg7+rer3+kBMZ08mW3JriyUu4M+ptloXaq5alH4KyFqypL9LPU4VNtL6H6eA==
X-Received: by 2002:a62:e30f:: with SMTP id g15mr17553770pfh.124.1575686881383; Fri, 06 Dec 2019 18:48:01 -0800 (PST)
Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id p24sm17368501pff.69.2019.12.06.18.47.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Dec 2019 18:48:00 -0800 (PST)
To: Fernando Gont <fgont@si6networks.com>, Andrew Alston <Andrew.Alston@liquidtelecom.com>, Ole Troan <otroan@employees.org>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, rtg-ads <rtg-ads@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
References: <f2a0ad13-0eba-6f5a-1d3c-e45e2780f201@si6networks.com> <D666EA6E-E8E9-439A-9CDE-20857F03CB65@employees.org> <4255AD3B-379C-45BF-96E1-D3D9141A684F@liquidtelecom.com> <d59de54e-c7f8-be67-1e77-b051735d40a6@gmail.com> <3bce7b18-ea45-d29f-5dfb-1d3258b07d1e@si6networks.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <c6e1f690-b0bf-9f45-8fa7-92ed182c5b04@gmail.com>
Date: Sat, 7 Dec 2019 15:47:53 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <3bce7b18-ea45-d29f-5dfb-1d3258b07d1e@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/nJtw0wyrp4Eqb5Fa3JG_oVA40bs>
Subject: Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)
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: Sat, 07 Dec 2019 02:48:04 -0000

Again, comment at the end...
On 07-Dec-19 14:37, Fernando Gont wrote:
> On 6/12/19 22:15, Brian E Carpenter wrote:
> [...]
>>
>>> and if such a thing is required, an update to RFC8200 should be done.
>>
>> Why does that follow? Alternatively, draft-ietf-spring-srv6-network-programming could acknowledge that it deviates from RFC8200.
> 
> You can deviate from s "should", not from a "must". This is an outright
> violation of a spec, rather than a mere "deviation".
> 
> 
>> Whether that's acceptable would be a question for the IETF Last Call rather than any single WG.
> 
> I would expect that a WG cannot ship a document that is violating an
> existing spec, where the wg shipping the document is not in a position
> of making decisions regarding the spec being violated.
> 
> That would be like a waste of energy and time for all.
> 
> 
> 
>> At the moment, the draft only mentions RFC8200 in a context that discusses neither insertion nor removal of extension headers, which is beside the point. Like draft-voyer, if it describes a violation of RFC8200, shouldn't that be explicit in the text?
>>
>> There's a lot of jargon in draft-ietf-spring-srv6-network-programming. I can't tell from the jargon whether "insert" means "insert on the fly" and whether "Pop the SRH" means "delete on the fly". Should those terms be clarified before the draft advances?
> 
> Well, if it's not clear to you, it would seem to me that the simple
> answer would be "yes".

But if "insert" refers to the encapsulating node at the SR domain ingress, it's no problem, and if "pop" simply means doing normal routing header processing, it's no problem. It simply isn't clear in the text, at least not clear to me.

   Brian