Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-rfc6040update-shim-21: (with COMMENT)

Bob Briscoe <ietf@bobbriscoe.net> Fri, 01 December 2023 23:31 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588C1C14F5EA; Fri, 1 Dec 2023 15:31:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th3SH6IijSx0; Fri, 1 Dec 2023 15:31:02 -0800 (PST)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA09BC14F60D; Fri, 1 Dec 2023 15:31:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2L5gbbxapjSlYSttR0bc7Q11ECltY7LuUaeaGjKrEvA=; b=wyIEjTIlv8HrqO29KT3CqFc0Eq 21tnfJiwhSLTBPBKr589ROdIr+FN9ZckSi4nMDTXYjhqmX70FPJzlFjL8IEdoy4C/oqraCL05rLM5 axulPRzr6La9NnT3qlUingOUaiVmpDCDtqd0prvyt9Pdd8+llhOvsN3LfQLzMwanSMu2li6eJ7JsD GC47vbU8UxBsj9zA5bGTaoZGy7esYqedYloAP8yCmSveU+gKkmif3uS/CONJaxzQTlkLlmNhsKYPJ bld7AimZrtK5Hb/rzeVmLsXl6wdQv/hf0mJ5HX9YMB2be9JT26YgHWk+sEqCoIQ3SA9j0eY85BafU bopj54Ig==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:41714 helo=[192.168.1.29]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96.2) (envelope-from <ietf@bobbriscoe.net>) id 1r9CyS-0008NX-0E; Fri, 01 Dec 2023 23:30:57 +0000
Content-Type: multipart/alternative; boundary="------------rwSmp7KKBvUvZvfmF6BQh7qO"
Message-ID: <cd0b649c-5566-4a8f-8540-c1eb066b0f0a@bobbriscoe.net>
Date: Fri, 01 Dec 2023 23:30:57 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: Robert Wilton <rwilton@cisco.com>, The IESG <iesg@ietf.org>
Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, tsvwg-chairs@ietf.org, draft-ietf-tsvwg-rfc6040update-shim@ietf.org
References: <170083120422.39897.10773838518629428052@ietfa.amsl.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
In-Reply-To: <170083120422.39897.10773838518629428052@ietfa.amsl.com>
X-MagicSpam-TUUID: ab76f5cf-075f-427d-99cb-5f013738c7a8
X-MagicSpam-SUUID: 940d2fac-60a4-4253-b6fb-042052ba0dd7
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/lJ3BlyU33shRzqshhlSykk7TA-Q>
Subject: Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-rfc6040update-shim-21: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Dec 2023 23:31:07 -0000

Robert, Thank you for these thoughts. Pls see [BB]

On 24/11/2023 13:06, Robert Wilton via Datatracker wrote:
> Robert Wilton has entered the following ballot position for
> draft-ietf-tsvwg-rfc6040update-shim-21: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Hi,
>
> Thanks for this document, I found it interesting to read.  A couple of minor
> comments for you to consider:
>
> (1) p 5, sec 4.  Making a non-ECN Tunnel Ingress Safe by Configuration
>
>        Whether or not an ingress implementation claims compliance with
>        RFC 6040, RFC 4301 or RFC3168, when the outer tunnel header is IP
>        (v4 or v6), if possible, the operator MUST configure the ingress
>        to zero the outer ECN field in any of the following cases:
>
> As a minor comment, I wonder whether RFCs should be specifying requirements on
> people (i.e., operators), or whether it would be better to place the
> requirement on the deployment.

[BB] We (the WG) had to work out how to navigate this particularly 
tricky balancing act. The following paras at the end of §3 were intended 
to explain:

    However, the ECN field is a non-optional part of the IP header (v4
    and v6). So any implementation that creates an outer IP header has
    to give the ECN field some value. There is only one safe value a
    tunnel ingress can use if it does not know whether the egress
    supports propagation of the ECN field; it has to clear the ECN field
    in any outer IP header to 0b00.

    However, an RFC has no jurisdiction over implementations that choose
    not to comply with it or cannot comply with it, including all those
    implementations that predated the RFC. Therefore it would have been
    unreasonable to add such a requirement to RFC 6040. Nonetheless, to
    ensure safe propagation of the ECN field over tunnels, it is
    reasonable to add requirements on operators, to ensure they
    configure their tunnels safely (where possible).


Perhaps your suggestion has taken this all into account, so you're 
suggesting that placing the requirement on the deployment would be 
better than on the operator (of the deployment). Perhaps, but I always 
prefer the active to the passive. "A deployment of an ingress SHOULD be 
configured to zero the outer," is less clear than, "The operator SHOULD 
configure the ingress to zero the outer."

FWIW, I'm not sure what the problem is with placing requirements on 
people. I've seen drafts 'corrected' when they place requirements on 
implementers, rather than implementations. But is this practice actually 
documented anywhere, or is there any rationale to support it? I'm always 
willing to learn if there is.


>
> (2) p 10, sec 6.1.1.  L2TP (v2 and v3) ECN Extension
>
>     L2TP maintainers are RECOMMENDED to implement the ECN extension to
>     L2TPv2 and L2TPv3 defined in Section 6.1.1.2 below, in order to
>     provide the benefits of ECN [RFC8087], whenever a node within an L2TP
>     tunnel becomes the bottleneck for an end-to-end traffic flow.
>
> Similarly to my previous comment, should the RFC 2119 requirement be placed on
> the maintainers, or should it be placed on an updated versions of L2TP?

[BB] Here, I agree with you. Proposed replacement text:

    Implementation of the ECN extension to L2TPv2 and L2TPv3 defined in Section
    6.1.1.2 below is RECOMMENDED, in order to provide the benefits of ECN...


Similarly, with the identically structured requirements in the GRE and 
AMT sections.

Thank you.


Bob

>
> Regards,
> Rob
>
>
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/