Re: [tsvwg] Closing L4S issues in the tracker

Re: [tsvwg] Closing L4S issues in the tracker - what does it mean?

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Sat, 06 June 2020 02:17 UTC

From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202006060217.0562HKo0033592@gndrsh.dnsmgr.net>
In-Reply-To: <MN2PR19MB4045D3FE5E6D1EC8AF35D84483860@MN2PR19MB4045.namprd19.prod.outlook.com>
To: "Black, David" <David.Black@dell.com>
Date: Fri, 05 Jun 2020 19:17:20 -0700
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/jiEqzgvwWa67gUCOQea22BQGoOw>
Subject: Re: [tsvwg] Closing L4S issues in the tracker - what does it mean?
Precedence: list

> [writing as a WG chair this time]
> 
> This note is an attempt to provide more explanation about the current purpose of the L4S issues in the issue tracker.  Given the decision to focus on L4S work for now, we've returned to using the issue tracker to track L4S issues that need to be dealt with before Working Group Last Call (WGLC) on the L4S drafts.  In other words, the scope of the issues in the tracker is the L4S drafts, and the intended result of closing the issues will be to get to WGLC on L4S - that WGLC will be on all of L4S, not just whether the tracked issues have been addressed.
> 
> 
> 
> Hence, the impact of closing issue #20 on ECT(1) is "the L4S proposal will use ECT(1) as an input" - e.g., L4S will not be redesigned in the WG to use ECT(1) as an output.  The word "proposal" is crucial - this is far from the last word on ECT(1) usage, as that last word can't happen until the IANA actions that would follow IESG approval which would follow IETF Last Call, which would follow WGLC of the L4S drafts, all of which are in the future.  The latter three are technical steps at which any/all technical issues and objections can be raised (and this is not about voting - see RFC 7282, particularly sections 6 and 7).  Looking beyond WGLC is somewhat hypothetical at this point, as if a WGLC were started today on L4S, I would expect the WGLC to fail.

Issue #20 did not say to rework it as an output.
Issue #20 says in part:
--- begin top of issue #20 ---
   The current L4S ID proposal is to use ECT(1).

There are objections to this, and other proposals mentioned, including:

    DSCP
    new protocol number
    combination of DSCP and ECT(1)? 

All of these alternatives are discussed in the draft, and some time ago the working group converged on ECT(1) use (aka "Berlin consensus"). 
--- end top of issue #20 ---

This issue is not resolved, no consenses was reached on how to
classify the traffic, hence this issue should not be closed.

The items in this issue that discuss SCE could be removed as
I already mentioned, but that does not lessen the fact that
there are still active objections at this time to use of
ECT(1) as the classifier.

Further the draft itself says a choice was made,
that is also still in a non-consenses state and
was based on a what was a false claim that consenses
had been reached in Berlin.

I do not believe it is possible to get this draft past
WGLC without addressing this issue in the WG.  Hence for
me it makes no sense to close this issue and kick it
down the street to WGLC or even later to IESG or IANA,
that would seem to be a waste of a lot of time.

Respectfully,
Rod Grimes

> Thanks, --David
> ----------------------------------------------------------------
> David L. Black, Sr. Distinguished Engineer
> Dell Technologies, Infrastructure Systems Group
> 176 South St., Hopkinton, MA  01748
> +1 (774) 350-9323<tel:+17743509323>           Mobile: +1 (978) 394-7754<tel:+19783947754>
> David.Black@dell.com<mailto:David.Black@dell.com>
> ----------------------------------------------------------------
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org

[tsvwg] Closing L4S issues in the tracker - what … Black, David
Re: [tsvwg] Closing L4S issues in the tracker - w… Rodney W. Grimes