Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)
Tom Herbert <tom@herbertland.com> Fri, 06 December 2019 15:58 UTC
Return-Path: <tom@herbertland.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 BF388120019 for <spring@ietfa.amsl.com>; Fri, 6 Dec 2019 07:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-com.20150623.gappssmtp.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 Y_AT08sk2hYF for <spring@ietfa.amsl.com>; Fri, 6 Dec 2019 07:58:53 -0800 (PST)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 A4FF31200D7 for <spring@ietf.org>; Fri, 6 Dec 2019 07:58:52 -0800 (PST)
Received: by mail-ed1-x52b.google.com with SMTP id c26so6165078eds.8 for <spring@ietf.org>; Fri, 06 Dec 2019 07:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5zD1XNjdSf74V5f1hR9KWpM/fUP/TVtf7UhBtJhKlAg=; b=mfA790kYO6nLhxSySEzxWd6IIgep0P2aplLpQTy3ZeD3xuweBi5AWYA3e5MYnyRysX 2cXjq8u/lg4Se8CfeGRsuh1YVUba1wvD5Ybdwa9iqZaQYH7vPNBDxTMIiIDfXtXyquB3 5VhxeZeBAIIFvTNaQQzHmzVaM+bwJJ6MjaOymcLehe/HtY1CmudaypQN06FIXCjU3LMy aa9Ojl2UPsXy3S/0DhXxw2J4ZnpptG1+Z9XOe8V4jkFqk1ynwYdgGmTubmRcWb0/Xl1V 6ClI4PQeRl/B9IMAVLkENqajf37MICGigPxxMvZr/iBESltuU+lLjp9z/31DCAAapFBY 7SBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5zD1XNjdSf74V5f1hR9KWpM/fUP/TVtf7UhBtJhKlAg=; b=H3FCIj0AUNTOt9+DSxRNnPNRAK9X5AFHPLjcQ5fmFf9/KLVayerJE7tiiO0Ke2/ogA X9Edg563S4prVwmer4tQHNqqPbAUHnB30/CQ5hjvp7exy3QzMIQTXenocRUekZLW/o7/ ex8xB6b5GtqRdohxU+JgvDJkQh3TYdtheINVzKl5J0hysZaqTO3B1y5xP2kAXduNvMQt eVI7+nPB+Z3rcBjspoxBmQOG0jyTiD+F/JnyIp4GaE9haV2HlgksL5mMUoeVk8sMjre1 kb10avma594Tx8hCX498EADwOXjLrJFN4enlJUliOKGG7X1e3E8/X2Z+rk/Qu83KrD59 xFfA==
X-Gm-Message-State: APjAAAUjMAiqsyuY7cHJ3dLHM6FOgj7kG81exP06VEj3A5lw9OxfV78f ubyVOYuY0beSk3JmvVHvdhcIcrVSW3KG/0Z9NxlsOw==
X-Google-Smtp-Source: APXvYqwJN7z1pGtKgQCtrJ0yaVh+wYrlqYAfuF92itq4BSwqNiL0j7b3xC43mLiQHzLLi3VQHMmeSNWxIgcG36TKIdQ=
X-Received: by 2002:a17:906:4e46:: with SMTP id g6mr15971016ejw.309.1575647930922; Fri, 06 Dec 2019 07:58:50 -0800 (PST)
MIME-Version: 1.0
References: <BN7PR05MB5699EA5F4C041538560282A6AE5F0@BN7PR05MB5699.namprd05.prod.outlook.com> <52132FA9-669E-4B32-BDC8-6F06C98315F3@gmail.com>
In-Reply-To: <52132FA9-669E-4B32-BDC8-6F06C98315F3@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 06 Dec 2019 07:58:39 -0800
Message-ID: <CALx6S37r2JYbrMpN-qR3bD3kaOMj3xEceQC5JhVb8dqVzfq=5A@mail.gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
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@tools.ietf.org>, Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/rIuElwFzTonzfGbltTNLW0-SZpg>
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 15:58:56 -0000
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. 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. 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>; SPRING WG <spring@ietf.org>; 6man <6man@ietf.org>; 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>; SPRING WG <spring@ietf.org>; > >> 6man <6man@ietf.org>; 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 > --------------------------------------------------------------------
- [spring] Network Programming - Penultimate Segmen… Ron Bonica
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… Darren Dukes (ddukes)
- Re: [spring] Network Programming - Penultimate Se… Ron Bonica
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… otroan
- Re: [spring] Network Programming - Penultimate Se… Ron Bonica
- Re: [spring] Network Programming - Penultimate Se… otroan
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- [spring] We don't seem to be following our proces… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Tom Herbert
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Enno Rey
- Re: [spring] We don't seem to be following our pr… Enno Rey
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Bob Hinden
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Joel M. Halpern
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Tom Herbert
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Bob Hinden
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Tom Herbert
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… Darren Dukes (ddukes)
- Re: [spring] Network Programming - Penultimate Se… Ron Bonica
- Re: [spring] We don't seem to be following our pr… Ole Troan
- Re: [spring] We don't seem to be following our pr… Andrew Alston
- Re: [spring] We don't seem to be following our pr… Sander Steffann
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… otroan
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- [spring] Separating issues (was Re: We don't seem… Suresh Krishnan
- [spring] Penultimate Segment Popping and RFC8200 … Suresh Krishnan
- Re: [spring] Separating issues (was Re: We don't … Ketan Talaulikar (ketant)
- Re: [spring] Penultimate Segment Popping and RFC8… Ketan Talaulikar (ketant)
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Alexandre Petrescu
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Network Programming - Penultimate Se… Darren Dukes (ddukes)
- Re: [spring] Network Programming - Penultimate Se… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Darren Dukes (ddukes)
- Re: [spring] We don't seem to be following our pr… Robert Raszuk
- Re: [spring] Network Programming - Penultimate Se… Tom Herbert
- Re: [spring] Network Programming - Penultimate Se… Robert Raszuk
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] We don't seem to be following our pr… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Brian E Carpenter
- Re: [spring] Penultimate Segment Popping and RFC8… Adrian Farrel
- Re: [spring] We don't seem to be following our pr… Brian E Carpenter
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] We don't seem to be following our pr… bruno.decraene
- Re: [spring] Penultimate Segment Popping and RFC8… bruno.decraene
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Mark Smith
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Brian E Carpenter
- Re: [spring] Penultimate Segment Popping and RFC8… bruno.decraene
- Re: [spring] Penultimate Segment Popping and RFC8… Pablo Camarillo (pcamaril)
- Re: [spring] Penultimate Segment Popping and RFC8… Robert Raszuk
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- Re: [spring] Penultimate Segment Popping and RFC8… Fernando Gont
- [spring] Non-final destination address (was Re: P… Suresh Krishnan
- Re: [spring] Non-final destination address (was R… Fernando Gont
- Re: [spring] Non-final destination address (was R… Suresh Krishnan
- Re: [spring] Non-final destination address (was R… Fernando Gont