Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim

[Sebastian Moeller <[e-mail]>]

Dear All,

a request for clarification from the chairs below.


> On Mar 8, 2020, at 15:18, Bob Briscoe <[e-mail]> wrote:
> 
> Steve,
> 
> Exec summary: 
> If you hobble an experiment too much unnecessarily, you make it fail.

Reading this makes me wonder what experimental RFCs are designed for.
What is the scope/rationale for granting an RFC experimental status? According to https://www.ietf.org/standards/process/informational-vs-experimental/:
"4.2.1 Experimental

The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution.
[...]
	• If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental. This is the typical case of not being able to decide which protocol is "better" before we have experience of dealing with them from a stable specification. Case in point: "PGM Reliable Transport Protocol Specification" (RFC 3208)
	• If the document contains implicit or explicit success/failure criteria, and it's clear that the outcome can be used as the basis for a recommendation to the IETF community, it's Experimental. Case in point: RFC 1797 "Class A Subnet Experiment" which led to RFC 1879 "Class A Subnet Experiment Results and Recommendations"

"

I fail to see how "ease of deployment" fits into this framework as rationale for granting experimental status (IMHO if an experiment is successful deployment issues are worth discussing, if elevation into a full internet standard seems merited). However, safe coexistence with the existing internet, and proper test of functionality under diverse/adverse real-world conditions seem good arguments for granting experimental status. But for this testing requiring an abundance of caution and additional safety features and a big fat kill-switch for something with as many known side-effects as L4S is just good engineering practice. 

QUESTION @Chairs: What are the conditions and aims for the TSVW WG in deciding to grant an RFC like L4S experimental status? I would love to get a clarification please.

Many Thanks in advance

Regards
	Sebastian


[snipped text]