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

"Joel M. Halpern" <> Thu, 27 February 2020 13:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94D763A0905; Thu, 27 Feb 2020 05:43:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MYTBFLSU80N9; Thu, 27 Feb 2020 05:43:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2E1A3A0932; Thu, 27 Feb 2020 05:43:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 48Sv5k6KbyzVldP; Thu, 27 Feb 2020 05:43:54 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48Sv5k64Wmz6G8tp; Thu, 27 Feb 2020 05:43:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1582811034; bh=6l2Nb7nmMfGmI7+apRTPGlz0q2YhuhXen4DsnHc2grE=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=WKN5FIwjF1h07kZ5EQsHv0bT8aor2yQdYv42m6unQV3Rj0WIoDG41JtQHA1WwQXu0 DJKf4AwjV0G0QRZc/5cmymUFupgHBNi5slM/xoMLcLmEfRUoDMRSQ+4kuC6QzQH7Tk FSMuBpbUjKhDBVDm6tnGKuvlsy1Wc/7HWcZLf7Dc=
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 48Sv5j4VqZz6G84R; Thu, 27 Feb 2020 05:43:53 -0800 (PST)
From: "Joel M. Halpern" <>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: "Eric Vyncke (evyncke)" <>
Cc: SPRING WG List <>, "" <>
References: <> <> <> <>
Message-ID: <>
Date: Thu, 27 Feb 2020 08:43:51 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Feb 2020 13:44:01 -0000

Even if one assumes that the violation has not been proven, I think it 
has been shown clearly that PSP pushes the limits of 8200.  If there is 
a strong reason for PSP, then pushing those limits is sensible.  But the 
vast majority of the response we are getting to the issue on this list 
is either:
1) It does not actually violate, so we can do what we want, even if the 
value is marginal
2) the limits do not apply

Neither of those seem to address the question.  And that gap is a 
concern with closing the last call.


On 2/26/2020 6:18 PM, Eric Vyncke (evyncke) wrote:
> Writing this without any hat,
> Please note that on the logical side, it still have to be "proven" that this idea is strictly forbidden by RFC 8200. Moreover, this 'proof' can technically wait until the IETF last call or even until the IESG ballot. I see little point in postponing the closing of the WGLC and advancing the document (of course, the document shepherd will need to carefully write the section about the rough WG consensus).
> Finally, as far as I know, at the IETF we have no religion... else we would still be running NCP or IPv4 :-)
> -éric
> -----Original Message-----
> From: ipv6 <> on behalf of Warren Kumari <>
> ...%<...%<....
>      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...
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------