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

Bob Hinden <bob.hinden@gmail.com> Wed, 26 February 2020 21:56 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01F63A0863; Wed, 26 Feb 2020 13:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mMhtuBd1Gw2b; Wed, 26 Feb 2020 13:55:58 -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 766273A085A; Wed, 26 Feb 2020 13:55:58 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id j7so647226wrp.13; Wed, 26 Feb 2020 13:55:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=SgCkhcTmZK1T8/r9ZrP0S2nJF532ZuC8dlOtj1AkhZw=; b=bHAGirTRZNcergCqEOemT6ELII6P7LoiWRQ8r+7kqGD5jvpE9ATzvqSZTp7R1FuJNo sELkHB4LbVY9B2ysVqPjMJoKBSnTtwFCdMpK6La+dFiwyCnnyaB0AfI6z5+I84SyHdJK d2CEpdYfEEeUoTJLzcV3PP/fFdJkFcjx/jWQRHE1Kpe51NjfUjjwPQOuDqp040UzK6/Q pGgQ1jUoN9onGBpyuONEnA+bNeqjokMNVdhf8qc4kitPZrMFWRtMgu6lBy1x9GiCvBJE PgCf+DwcIst/+N8OtmucDHdyNRTiTlAkmvRqnp6LVHAu/Hi1dCE/u3p2kQCVw8jA9lLG rDkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=SgCkhcTmZK1T8/r9ZrP0S2nJF532ZuC8dlOtj1AkhZw=; b=t0scTU50Vd/Ix18K3Nq0ONQd5aBNJA1w7hXX5IXA4wlrz09rw35kGWGbPVwVyaH5gY J7e1wGP/c1GH7XCe0F7Q12Jn1645Gb22cdyTRLeEIStIvwriGLaHGCrKmqIHT857S99N 5dx22E9xdIlvdnmTG+DhWPqZkqNJRuCihtl3SNjHq0PCJcsZS8O2cij85uLxYJrofrc0 JM7ygeMDoHKrSE1o2skK0jkqq1eFXUkP1xqx7Ro6maXz+Z9y4k4smaGUPu3efSu1tgrV RBxL5QQW4vHqnJRedZowDNfQZJ+PEPvYDWSycnxMmgYf1fiRDxh9sAyB3v1FnA8E4R3w XFXA==
X-Gm-Message-State: APjAAAV9STOucBFHnCp5SFdaYhLSb5jDXmjhVX0WFOiKHF3w2VQJzo5a dsCM7oo9YFy8gMnyelW2e/M=
X-Google-Smtp-Source: APXvYqz4RCZRCCJ9q2LIgTtvEM1/+6qgGLCabjrlimWWis4SKhRsUvbSMg3cka2YiK+xUIw6ZGvSMw==
X-Received: by 2002:adf:f244:: with SMTP id b4mr686969wrp.413.1582754156946; Wed, 26 Feb 2020 13:55:56 -0800 (PST)
Received: from ?IPv6:2607:fb90:2840:5533:9944:8b77:3f24:2c03? ([2607:fb90:2840:5533:9944:8b77:3f24:2c03]) by smtp.gmail.com with ESMTPSA id h3sm5209829wrb.23.2020.02.26.13.55.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 13:55:55 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_9E676767-B7A6-488F-9DC4-6871CE6D59DF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
From: Bob Hinden <bob.hinden@gmail.com>
X-Priority: 3
In-Reply-To: <907734565.529015.1582747778596@webmail.networksolutionsemail.com>
Date: Wed, 26 Feb 2020 13:55:46 -0800
Cc: Bob Hinden <bob.hinden@gmail.com>, Warren Kumari <warren@kumari.net>, SPRING WG List <spring@ietf.org>, 6man@ietf.org, "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>
Message-Id: <DE53ECEF-14E5-4D9D-A239-6A13E2574E74@gmail.com>
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>
To: "john leddy.net" <john@leddy.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/daU-gBjoIynfadZ4YAO0_iuXgWM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 21:56:04 -0000

John,

> On Feb 26, 2020, at 12:09 PM, john leddy.net <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.

To repeat what has been said before, the way to do this is to write a draft that defines how these constraints could be relaxed and build a consensus around that.  This has not been completed.

We had a constructive discussion on this topic at IETF 106, it’s recorded in the minutes at:

https://datatracker.ietf.org/meeting/106/materials/minutes-106-6man-01.txt

I have not seen any further discussion after IETF 106.

Bob



> 
> 
>> On February 26, 2020 at 2:15 PM Warren Kumari <warren@kumari.net> wrote:
>> 
>> 
>> I would suggest that people read RFC 7282 - "On Consensus and Humming
>> in the IETF", especially Sections 3 & 6 (it is a short document, you
>> should read the whole thing, but pay special attention to these
>> sections).
>> 
>> It doesn't really matter how many people say +1 for moving it forwards
>> -- if there are valid technical objections these have to be dealt with
>> - and I think that the relationship with RFC8200 falling into this
>> category...
>> 
>> W
>> 
>> On Wed, Feb 26, 2020 at 2:01 PM John Leddy <john@leddy.net> wrote:
>>> 
>>> +1 in support of moving the document forward.
>>> 
>>> John Leddy
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Feb 26, 2020, at 10:22 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
>>>> 
>>>> Zafar,
>>>> 
>>>>> On Feb 26, 2020, at 9:43 AM, Zafar Ali (zali) <zali=40cisco.com@dmarc.ietf.org> wrote:
>>>>> 
>>>>> +1,
>>>>> 
>>>>> Just to add, in the spirit of IETF https://www.ietf.org/how/runningcode/ …
>>>>> implementation, commercial deployment and Inter-op status has been documented in https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/
>>>> 
>>>> I think the proper question is there a consensus to advance this document.
>>>> 
>>>> There seems to be questions about its relationship with RFC8200.  I am not seeing this as being resolved.
>>>> 
>>>> Bob
>>>> 
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> 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
>>> --------------------------------------------------------------------
>> 
>> 
>> 
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>   ---maf