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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 28 February 2020 01:51 UTC

Return-Path: <brian.e.carpenter@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 821753A0C18; Thu, 27 Feb 2020 17:51:22 -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 eDs0Bt9lXvRp; Thu, 27 Feb 2020 17:51:20 -0800 (PST)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 A674E3A0BD1; Thu, 27 Feb 2020 17:51:20 -0800 (PST)
Received: by mail-pj1-x1036.google.com with SMTP id m13so588410pjb.2; Thu, 27 Feb 2020 17:51:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GtPWphB/oEGpz0vOUlOKfaP4wtY+a7jRLGWIACoevZw=; b=GgkluLuTCWqJkpec0wygD2PnV0lk3nCjDEgjjmEAyIUq7VrWSd2OztqIb2pAzWTGal n+gXANDJvDpbK5dlvIVZEq0qXUw03BsmATH6T60kNDCP1w/eW3O+PgnnNeH+h7cus3vO WrrCOdUtOBlziWwq1rQW3QvseGC6TcnWLKA+zIHV5E0M9m8KesFRtCVKO4bpSSg20rQc cRXPibOVpU77U/qsS73Ek8H6gAMXJsCnM7Xyz3iUHStYvc6B+v7TdSh0XKSM967kYxN1 BQY5dDrxJYbfvmMvKQ5NSW3nwSTlPAFHVc72LrhxxABp+4CGFp5GNkY0oRcw+YhBrUAc /N3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=GtPWphB/oEGpz0vOUlOKfaP4wtY+a7jRLGWIACoevZw=; b=s0REBeaZ11ZKxQhSI6oMsOXlibHRwfSUuCkkcmS/FIbTPv4n8KQ0Wtz47pyvF5cXB8 YdLLKSQoDcW7/V3U8JPSvEoKANSTdK+UD07ChQHVEj/2Dv5M6XhrG8qld8hyPEbf7B8e k71XpfrAAgxJaUGBhoXUMYFsMn/WRd2PJWEyVbq5pMrth1EZcU0EH/NA8Z63ahsTt9wO RRqaUZrr7b8ni9/KPEwkBaPFn0r78jD+2yP9/E5/hwFjyjLK69dD5z+vAP1DrXw14uca LXodzZMlq9dh0LYqCN8b/XlRtalHBNLQzLbI9jzzOv1YHSTAfhGMX2tK0eEJ3mlGyj+O iAtA==
X-Gm-Message-State: APjAAAVF2uTT0mn0Bg8RfVYaoCSTqc7kotTHYPsp1Tkf3vq6r6XH3Xqd HApc1V1aF/RA4viozzhEoynmG/4U
X-Google-Smtp-Source: APXvYqy8sdpzExX2LD751P0DXKl4oEG9e2qwZgriLQHPYcUbNxiRIVOFnODsZK5/UV6R919nlHxewA==
X-Received: by 2002:a17:90a:8043:: with SMTP id e3mr1966008pjw.24.1582854679822; Thu, 27 Feb 2020 17:51:19 -0800 (PST)
Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id i68sm8626930pfe.173.2020.02.27.17.51.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 17:51:19 -0800 (PST)
Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
Cc: Lizhenbin <lizhenbin@huawei.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D9364A1C2@DGGEMM532-MBX.china.huawei.com> <a93c23e5-eb65-f84a-6289-6f1221c68f2d@gmail.com> <67ECB7F5-86E5-4AE9-B8EB-B06203978B35@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <6b395f68-678c-8bec-9cd5-0f29d3b3f8fd@gmail.com>
Date: Fri, 28 Feb 2020 14:51:15 +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: <67ECB7F5-86E5-4AE9-B8EB-B06203978B35@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6W1D58rWrsFMa8h75WUeCiEzoG0>
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: Fri, 28 Feb 2020 01:51:28 -0000

Pablo,

I have been looking at the latest version. See my previous note to Stefano Salsano. I really think that the problem here is that certain things are obvious to SRH experts but not to others, and they simply need more explanation in elementary terms.

Regards
   Brian Carpenter

On 28-Feb-20 09:38, Pablo Camarillo (pcamaril) wrote:
>  Brian,
> 
>>     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.
> 
> You raised such comment on December 7th 2020 at the mailer with respect to draft-ietf-spring-srv6-network-programming-05.
> We iterated throughout December publishing the clarifications that you requested in rev06 and 07.
> https://mailarchive.ietf.org/arch/msg/spring/Y7XKvgshM8ces-HbkT2uQa37a_w/
> https://mailarchive.ietf.org/arch/msg/spring/VpLfcUvDXHzMOU6fTE1_XPzhd68/
> https://mailarchive.ietf.org/arch/msg/spring/mXcsWXaISqjzs7g_fJZYhcKabgY/
> 
> Also, the word pop is still used in the section title, but it has been removed from the definition of the behavior.
> 
> Could you please see the latest version of the draft?
> 
> Thanks,
> Pablo.
> 
> -----Original Message-----
> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> Date: Wednesday, 26 February 2020 at 21:57
> To: Lizhenbin <lizhenbin@huawei.com>om>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>om>, 'SPRING WG List' <spring@ietf.org>
> Cc: "6man@ietf.org" <6man@ietf.org>rg>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
> Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
> Resent from: <alias-bounces@ietf.org>
> Resent to: <cf@cisco.com>om>, <pcamaril@cisco.com>om>, <john@leddy.net>et>, <daniel.voyer@bell.ca>ca>, <satoru.matsushima@g.softbank.co.jp>jp>, <lizhenbin@huawei.com>
> Resent date: Wednesday, 26 February 2020 at 21:57
> 
>     >  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.
>     
>     Regards
>        Brian Carpenter
>     
>