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

Brian E Carpenter <> Wed, 26 February 2020 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B51703A144E; Wed, 26 Feb 2020 12:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UfgOJe4lauM3; Wed, 26 Feb 2020 12:57:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A8963A144C; Wed, 26 Feb 2020 12:57:14 -0800 (PST)
Received: by with SMTP id p14so390426pfn.4; Wed, 26 Feb 2020 12:57:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MH2oeWi7cT3abETvN9nfoXd76g5FN1IQZxhypvG6VUY=; b=MG7FdWkcd5NouuBszexFQZn1LoeCqC2n6X3w6IKpHnRS11H0Z3DYo/HIcH1SBKwxip l0DwnUp1Nx55FeSsOuK9gX6a5cMDfWmkCRNQxWC58boA3AQJBlZDiptXrT7Wu/H5CTOW MY9m7p+RFzvR33jqz6y+uUYyeAVRKfiiwlxLcrooK7fNqqa+4JzQpj7gSDfLkLEkOACU ZdZvQgIg4eJw9kJP3Z4p/MJgYTyduAtT0z/yHPGD26GeREf32binEx7li/R/GH7PRorQ xlmoaH0k/Yyfv38npqEpjZWyKJ1GvDr/5WaIVV7HwZRbfNd/25HEs3vSpZDAJxjGWL+e DpkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MH2oeWi7cT3abETvN9nfoXd76g5FN1IQZxhypvG6VUY=; b=fxqzL/DdaxsG+YU2uEmNq+Bt+QIfviLhEp92jLHpBKLj58ayx75dNFQ/Eig0/s0CEf 5iNM+ygxMglDA8IdccmiVQVI0qM7AoCstOLvAk1av20O1fqBG7ru8NIAIrxjSG5vl+2O g75PoNOnROwrxsLxcbzDh5aC10dS58Xhrv2oaOrpFP+OmtN6JcU413oBlj5MUZDUvoST BnN+y0WrjKqArTB6kClHLoBFBhxs1h0+CH94gmYPU8NzgQYzrOKHbgK1i6amdaPxkUQh rieC2zDfbCfnHPJKNheXemHkMjzQSE5BvkQK6KRXOmNSyZS1KnWr4p/0oZvvfCMCs3P+ hB/Q==
X-Gm-Message-State: APjAAAUKgRpdJIp5zwq5g7vWDhnPp+jpxEz11dE+W/lvywYgPoWp4fI9 UjgKMbNRnIHvf75qgQLYvA++exBb
X-Google-Smtp-Source: APXvYqwfXGZJqDDT7MFO06KLZQTqUTCQlf6ggHTvaY2D16OurdAoYcdM+9y7MCwbGiaDUmjqMdECSQ==
X-Received: by 2002:a63:441e:: with SMTP id r30mr653985pga.51.1582750633712; Wed, 26 Feb 2020 12:57:13 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id s124sm4479268pfc.57.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 12:57:13 -0800 (PST)
Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: Lizhenbin <>, "" <>, 'SPRING WG List' <>
Cc: "" <>, draft-ietf-spring-srv6-network-programming <>
References: <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 27 Feb 2020 09:57:09 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Wed, 26 Feb 2020 20:57:16 -0000

>  In the process all the comments have been resolved 

Unfortunately, this is not true.

For example, the word "pop" is used but still not defined. In computer science, it generally refers to popping a stack. I understand that in the MPLS context (a label stack) but not in the IPv6 context, where there is no stack in the header.

The text explaining penultimate segment pop, quite apart from using "pop" in this undefined way, still does not explain how it is compatible with the RFC8200 interdiction of inserting or removing headers en route. It explicitly describes removing a header before the final routing hop, which is explicitly against RFC8200.

As far as I'm concerned, these comments have been brushed aside.

The fact that there's running code is good, but it doesn't resolve anything in the text.

   Brian Carpenter