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

Bob Hinden <bob.hinden@gmail.com> Fri, 06 December 2019 16:53 UTC

Return-Path: <bob.hinden@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 161541209B7; Fri, 6 Dec 2019 08:53:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 CPYu8XGFpfpt; Fri, 6 Dec 2019 08:53:05 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 A657F1209AF; Fri, 6 Dec 2019 08:53:04 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id z3so8546638wru.3; Fri, 06 Dec 2019 08:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=B/4fuulpj6CvhTi0O8I1HsA4TVUCtNpsXk6uJ9D4wXI=; b=ASrxZnyPgluqDkgkK0QTdpTQ90alKiqgmEj6RW2YLIn3cGZJv5OfwIo0RHbSMtwHIr Ek3/pzaNAPbOj6ZATqIgWjNJ2h02S38l0IIE8dNphzUFM3vqy2tmSoeO5hWhUtJdfsIZ H9g4UlDsx1dpGi2gVPYZnhefcrqiZmK5zBgLIMSc27tsLv/vesRPoVVefJL7+HpyPxiU J8uFc2JRMPxlArg19OpB9sjs2/hfnDP7ygYJHh3RhTIk5IcqLekmZYzIFWgZZhs3jHav wto414qCCr2b/lxqmiJjwI2ghnG0DeAcsufZXGZT1llgrZvodjFAeamnbhfVXhyqwJov ESIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=B/4fuulpj6CvhTi0O8I1HsA4TVUCtNpsXk6uJ9D4wXI=; b=Kz1IvnJ8rU/VVXysgcTX6ssW44V08lVZJxijTzz9cYsS/nnbJx991hkPBXct+7XBmf XI0iQz022rg+zZ9m4UvIrf8j87SS5hBL1uypZwYbRMVLRRzT1so2t9OXkByP245pyaER UEUMUfyBbskYsdZoNYiJaA9apvdhk81iWi3+9wOBo1Lax7mi5T6oIVocgknNCx2DXHdd uo1uxV1alHkBcD8h2qB97mUwrxJvOQItW/WQTrf0DW6tYEbFumRLvbw4E89X4xyURZeh 2A+Bq8yr7Y+A+v7OulXYDiNbNO1FMOZkCZhnTw/2c7B0Ysckuww4O9S9FG8Z3f15fF1K QsbA==
X-Gm-Message-State: APjAAAWZoVbBQILbZxBfOeu+pvCBgWYy6sN7HteTbCxiNkhjs6EXYyTc 5Kx99YyZdKo5MtuV6CoGaEY=
X-Google-Smtp-Source: APXvYqy+KuxcIH+/xRdzv9tZDJMDNAGbQfSsQwGCD4aqg+KI7ffnPXpQIU8gmXODSpahyN7daqnyHA==
X-Received: by 2002:a5d:4d4a:: with SMTP id a10mr16896939wru.220.1575651183024; Fri, 06 Dec 2019 08:53:03 -0800 (PST)
Received: from [10.246.31.194] ([96.47.52.153]) by smtp.gmail.com with ESMTPSA id q15sm16778769wrr.11.2019.12.06.08.52.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Dec 2019 08:53:01 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <F84E8F46-38FD-465A-BC6C-A655B5221FC8@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_2C0DAB48-5C9E-4093-AAB7-4B846B8C11A9"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 6 Dec 2019 08:52:55 -0800
In-Reply-To: <CALx6S37r2JYbrMpN-qR3bD3kaOMj3xEceQC5JhVb8dqVzfq=5A@mail.gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, 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@tools.ietf.org>, Fernando Gont <fgont@si6networks.com>
To: Tom Herbert <tom@herbertland.com>
References: <BN7PR05MB5699EA5F4C041538560282A6AE5F0@BN7PR05MB5699.namprd05.prod.outlook.com> <52132FA9-669E-4B32-BDC8-6F06C98315F3@gmail.com> <CALx6S37r2JYbrMpN-qR3bD3kaOMj3xEceQC5JhVb8dqVzfq=5A@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ST591VxD6Bye8YgtY4GuiapHKrA>
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: Fri, 06 Dec 2019 16:53:07 -0000

Hi Tom,

> On Dec 6, 2019, at 7:58 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
> On Thu, Dec 5, 2019 at 4:30 PM Bob Hinden <bob.hinden@gmail.com> wrote:
>> 
>> Hi,
>> 
>>> On Dec 5, 2019, at 16:20, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
>>> 
>>> Enno,
>>> 
>>> That is how I parse Ole's message. But we can let Ole speak for himself.
>> 
>> To clarify, the current consensus is the text in RFC8200.
>> 
>> There is discussion ongoing in 6man on this topic, but it is impossible to say how that will turn out, or when.
>> 
> Bob,
> 
> The advice from the chairs seems to be continue discussion. The
> problem with that is that EH insertion has been discussed ad nauseum
> over the past two years since the draft first appeared. It seems like
> we are at the point where the same arguments on the topic are just
> being rehashed on the list. As you mention above, the current
> consensus is that the EH insertion conflicts with RFC8200. Right now
> it seems like further discussion is open ended and without any
> constraints a likely outcome will be attrition and eventual
> acquiescence to accepting yet another non-conformant protocol that
> became so widely deployed so that it can be fixed.

I think the difference in what is happening now, is that we have two drafts that are being discussed instead of just volumes of email.   This is the process that should allow us to see if there is a consensus beyond what is in RFC8200.   I won’t speculate what the outcome of this will be.

IETF standards are voluntary, and are designed to create interoperability between different implementations.   Since we don’t have IETF Protocol Police we can’t do anything about other approaches.   However, I note that many customers prefer products that support interoperability between different implementations and vendors.

> In light of this, can the chairs or AD provide some guidance or
> expectations on framing any further discussion on the topic to ensure
> that it's productive and the process is moving forward.

My take is that the discussion of the two drafts in 6man should continue.   Any work that wants to rely an outcome of that discussion, should wait.   As I said earlier, it’s hard to say when that will be done.   Otherwise, I think the other work should be compatible with what is in RFC8200.

Bob


> 
> Thanks,
> Tom
> 
>> Bob
>> over the
>> 
>>> 
>>>                                          Ron
>>> 
>>> 
>>> 
>>> Juniper Business Use Only
>>> 
>>> -----Original Message-----
>>> From: Enno Rey <erey@ernw.de>
>>> Sent: Thursday, December 5, 2019 5:48 PM
>>> To: Ron Bonica <rbonica@juniper.net>
>>> Cc: otroan@employees.org; Fernando Gont <fgont@si6networks.com>om>; SPRING WG <spring@ietf.org>rg>; 6man <6man@ietf.org>rg>; int-ads@ietf.org; rtg-ads <rtg-ads@tools.ietf.org>
>>> Subject: Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)
>>> 
>>> Hi Ron,
>>> 
>>>> On Thu, Dec 05, 2019 at 10:08:53PM +0000, Ron Bonica wrote:
>>>> Peace Gentlemen,
>>>> 
>>>> For the purpose of this thread, I think that we have all of the information that we need. Consensus regarding header insertion and removal is "evolving".
>>> 
>>> not meaning to nitpick and admittedly I'm not super-familiar with all nuances of IETF processes but this means that no type of consensus has been reached yet, correct?
>>> 
>>> thanks
>>> 
>>> Enno
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> We need to let that evolution progress, and not make any assumptions regarding its outcome.
>>>> 
>>>>                                                       Ron
>>>> 
>>>> 
>>>> Juniper Business Use Only
>>>> 
>>>> -----Original Message-----
>>>> From: otroan@employees.org <otroan@employees.org>
>>>> Sent: Thursday, December 5, 2019 4:42 PM
>>>> To: Fernando Gont <fgont@si6networks.com>
>>>> Cc: Ron Bonica <rbonica@juniper.net>et>; SPRING WG <spring@ietf.org>rg>;
>>>> 6man <6man@ietf.org>rg>; int-ads@ietf.org; rtg-ads
>>>> <rtg-ads@tools.ietf.org>
>>>> Subject: Re: We don't seem to be following our processes (Re: Network
>>>> Programming - Penultimate Segment Popping)
>>>> 
>>>> Fernando,
>>>> 
>>>>>>> Point taken. Could you comment on the current state of WG consensus?
>>>>>> 
>>>>>> The working group session in Singapore ended with what appeared to be a view that we should continue work on both documents (Mark's and the Voyer draft).
>>>>>> For the state of the wg consensus, I haven't checked with Bob, but I think he will agree with it being classified as "evolving".
>>>>> 
>>>>> I polled you about this decision
>>>>> (https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/i
>>>>> pv
>>>>> 6/12Qwp_eeQT2EmbUrSxBLL5HTcnM__;!8WoA6RjC81c!QH6T9eu4QEGAh1tVtPAiXW2SjsZMxfQdUYen3nv2CPDS4DWlFeKu7c4TwztzwnbH$ ), and you never responded.
>>>> 
>>>> Sorry, which decision is that supposed to be?
>>>> 
>>>>> Suresh (INT AD) clarified this one list, here:
>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ip
>>>>> v6
>>>>> /Db6_SGfmeIDzaE56Ps5kUDCYEzY__;!8WoA6RjC81c!QH6T9eu4QEGAh1tVtPAiXW2S
>>>>> js ZMxfQdUYen3nv2CPDS4DWlFeKu7c4Tw1iPjJAl$
>>>>> 
>>>>> Suresh noted that there wasn't consensus call, even at the f2f
>>>>> meeting (not to mention that the list was never polled in this respect).
>>>> 
>>>> Right, neither of these two documents are adopted as working group documents. And perhaps a more correct phrasing above would be that "The working group session in Singapore ended with what appeared to be a view that work could continue on both of these documents".
>>>> 
>>>>> I would say that it seems we have not been following the processes
>>>>> that should be followed. This has happened repeatedly over time, for
>>>>> this very same topic. The process seems to be biased, and thus
>>>>> unfair to the rest of the wg participants.
>>>> 
>>>> Which process are you talking about? Is that documented in an RFC?
>>>> You seem to take it on yourself to represent the "rest of the wg participants", but from my perspective it looks like a few very loud voices.
>>>> Perhaps we should let others speak up, if there is anything more to be said on this topic.
>>>> 
>>>> Ole
>>>> 
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests:
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
>>>> __;!8WoA6RjC81c!TjLEU67_JCgw5HSu4C7UhFOC61xLkOhpmW0Ev51wqvHbECMOysxK3t
>>>> 9RS5pxqO3g$
>>>> --------------------------------------------------------------------
>>> 
>>> --
>>> Enno Rey
>>> 
>>> Cell: +49 173 6745902
>>> Twitter: @Enno_Insinuator
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------