Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Fernando Gont <fgont@si6networks.com> Wed, 26 February 2020 20:26 UTC

Return-Path: <fgont@si6networks.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 B478C3A13A6; Wed, 26 Feb 2020 12:26:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 5dHTIk6_-6qM; Wed, 26 Feb 2020 12:26:17 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471543A13DA; Wed, 26 Feb 2020 12:26:17 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8BFA2807A3; Wed, 26 Feb 2020 21:26:11 +0100 (CET)
To: "john leddy.net" <john@leddy.net>, Warren Kumari <warren@kumari.net>
Cc: SPRING WG List <spring@ietf.org>, 6man@ietf.org, Bob Hinden <bob.hinden@gmail.com>, "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>
References: <F88E3F76-DD4B-4807-A458-85FABFF20D96@gmail.com> <5D218BFB-0D6F-4F7D-858F-B571A67DC47F@leddy.net> <CAHw9_iJ_ipEvU0NUx44XbK0_DrLe_GRw6G=m+chK4wZcRP8BMg@mail.gmail.com> <907734565.529015.1582747778596@webmail.networksolutionsemail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <7b23ba9e-54d9-d8ff-51b4-3cd5e6c8c0a1@si6networks.com>
Date: Wed, 26 Feb 2020 17:25:44 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <907734565.529015.1582747778596@webmail.networksolutionsemail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/pjU4WTrfF26Q0idGlJAiKjYCbkE>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
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: Wed, 26 Feb 2020 20:26:25 -0000

On 26/2/20 17:09, john leddy.net wrote:
> The understanding at IETF98 with rfc2460 moving to rfc8200 was that any tightening in header processing language was to get to an adopted standard and NOT to be used as club to bludgeon innovation by a small group of loud hummers.

1) My understanding is that decisions are taken on the mailing-list.

2) There is a reason for the different maturity levels, and a reason 
why, given a standard, you have to do a formal update if you want to 
change it. And the onus to get consensus is on the folks proposing the 
changes, as opposed to the folks asking for existing specs to be respected.

Rather than wasting our time trying to explain why or how existing specs 
don't apply to you, as well as lecturing folks that spend their time 
helping RFC8200 and previous efforts, you should have probably tried to 
make a case for updating RFC8200.

Nobody is stopping you from coming up with a proposal. We're simply 
kindly asking that you stop trying to violate existing specs, and 
circumvent IETF process.

This whole thing (including previous similar issues while working on 
rfc2460bis), is the perfect example of how individual participation 
(i.e., outside of a small group of big vendors) are highly discouraged 
from participating at the IETF.

It is a shame we have had to insist on this so much.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492