Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)
Tom Herbert <tom@herbertland.com> Thu, 05 December 2019 22:03 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 768421201A3 for <spring@ietfa.amsl.com>; Thu, 5 Dec 2019 14:03:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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] 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 ab3MSBF5QgAx for <spring@ietfa.amsl.com>; Thu, 5 Dec 2019 14:03:12 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 D20D6120168 for <spring@ietf.org>; Thu, 5 Dec 2019 14:03:11 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id cm12so4050020edb.11 for <spring@ietf.org>; Thu, 05 Dec 2019 14:03:11 -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=wIzv0+iMVfrjNMaBM1eK/F5RK1hShXGawpPL9xcEHNU=; b=XJR3NSDLdtCogmZEfQAOUhy5ePVVJoFQzy2pBDvemNsz+S7alTSlD54uS0zcwruP0b r9SVgmTWP2OTFVherBd0Xm9qMrKTbl7DKdgjA53E9pvGFFccAMcktCajgw3hiYTyU80Z lwudG8aeavabQHbTFQzb9UdhmMjhx9H9CUSltN+l7ZEmyWHsRfZSb4OonVnxxzOYSdvQ ind49Rqkleb8rH5dTty5ZzO2jIaUkmZtJybt+HinEg1GlBr1I+A1tjjxSWkJG91DdANu 3DvbCLuyB7oupRjY2C8I69mwGF85Bf0aLHqzGPqTOkqUiZvbZFFNf8ENNNHuYz1dnzHQ 0RDQ==
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=wIzv0+iMVfrjNMaBM1eK/F5RK1hShXGawpPL9xcEHNU=; b=FgD/d0oG2FtyStXGUs5bw/tW/t4R7+qofx59Y0pFQ2Yh4Pzl5grzSX3T0e3h4NV004 m8QbTmo3f3IsQ1fuAZKN+UzXeRf0lNTdjqD9eh2UDf+fWgPPoSkk10yI0m10CJTnV70Z 6wT/O/nEXgZglP+oUxfBPXIZZqld01NARyZQc39M2ltY/HzaT1N2Y2FQGkObKGgqiibI 3I3B5imZAEmh/rFogkbMFg43Eby8+mfZZEeI7b5WahD4DG25GTqsaSxuwDPoPlRW/Sks j68fUvRFX/NdaymoS0mDTqKtGNJds45UGgedcdlXbbXQ3N8iAY11kuCfCehpbZajXfhH canQ==
X-Gm-Message-State: APjAAAWTs1U8eNCIgxIr6OtE8j392wMgKIJoGB8XwHDnC0dLTTS3MJPD 4fobC7lH6Qj9gSQ+HEsK/cP33Bi3zEf7UmYkNwAE4Q==
X-Google-Smtp-Source: APXvYqx9Op8UnqQtoOe7GXX3T/sERkIL9QasOIYj8FNOBQLNQCMFAYBvMv4ryZhwBCP0Ed0pfSZ2Yx0s3XAu4H3riSY=
X-Received: by 2002:a05:6402:a48:: with SMTP id bt8mr13071382edb.62.1575583390207; Thu, 05 Dec 2019 14:03:10 -0800 (PST)
MIME-Version: 1.0
References: <BN7PR05MB56998A05469327E759B5B671AE5D0@BN7PR05MB5699.namprd05.prod.outlook.com> <3AD3BD11-8C34-41FE-B88F-49A9F2561D78@cisco.com> <BN7PR05MB569946D6AA5C6B78AFC05F6BAE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <8DEDE597-B7B0-48F5-959E-69757315C2AC@employees.org> <BN7PR05MB56996FFC117F512EEA04AFC8AE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <4FAB68A3-C533-471D-94D0-3F6EB1F32FC1@employees.org> <1e36a492-5931-02de-cf85-63339522b13a@si6networks.com> <F6DD2C7C-DBBF-4B48-B890-3C86005FB9CF@employees.org>
In-Reply-To: <F6DD2C7C-DBBF-4B48-B890-3C86005FB9CF@employees.org>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 05 Dec 2019 14:02:59 -0800
Message-ID: <CALx6S36hgFH2WpVze+estdWWHkss5UVfnh+R2UgFTHYWutSGqA@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: Fernando Gont <fgont@si6networks.com>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, rtg-ads <rtg-ads@tools.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/x3MYjfRW15K-m0q9MLeTtaS0OXU>
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: Thu, 05 Dec 2019 22:03:15 -0000
On Thu, Dec 5, 2019 at 1:41 PM <otroan@employees.org> wrote: > > 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://mailarchive.ietf.org/arch/msg/ipv6/12Qwp_eeQT2EmbUrSxBLL5HTcnM), and > > you never responded. > > Sorry, which decision is that supposed to be? > > > Suresh (INT AD) clarified this one list, here: > > https://mailarchive.ietf.org/arch/msg/ipv6/Db6_SGfmeIDzaE56Ps5kUDCYEzY > > > > 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". > Ole, I'm not sure what the outcome to the working group session means in terms of the process. Basically, we have two documents that almost directly contradict each other (the EH insertion is bad one was in fact written in response to the EH insertion is good document). They both can't be right, and Network programming is still assuming the outcome that EH insertion/intermediate node removal is correct. So to continue to work on both documents seems to be akin to punting the disagreement without clarity on how this will ever be resolved. Also, I'd point out that the EH insertion document is over a year old and has already been reviewed, I don't see what new information could be provided at this point that would change the fundamental arguments against it. Can we ask for call for working group adoption call on these? Tom > > 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://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