Re: [tcpm] Proceeding 8312bis draft (Re: 2nd WGLC for draft-ietf-tcpm-rfc8312bis)

[Neal Cardwell <[e-mail]>]

On Mon, Feb 28, 2022 at 5:07 AM Yoshifumi Nishida <[e-mail]>
wrote:

> Hi,
>
> We've been discussing how to proceed 8312bis draft, but I think we still
> haven't settled yet.
> In my understanding, there seems to be the following options so far.
> if you have some thoughts on them or you have other options for this,
> please share.
> BTW, please note that this discussion might affect our future drafts
> because we want to apply the same bar for all standard docs as much as
> possible.
>
> 1: Publish the draft as a non-standard doc
>     a: publish as an informational doc
>
>     b: publish as an experimental doc
>         * we might need to describe what experiments are expected.
>
> 2: Publish the draft as a PS doc
>     a: do additional experiments to make sure there's no concern as a PS
> doc.
>         * we will need to decide what kinds of experiments are required,
> what would be the expected results before the experiments.
>         * we need to delay the publication of the doc until the validation
> of the experiments has finished
>
>     b: publish an additional doc that describes the checking points on the
> doc (and other related docs) for long term analysis.
>

I would argue for:

  (2) publish the 8312bis draft as a PS doc, and

  (2b) publish an additional doc that describes any aspects of CUBIC where
the community would like to see further experiments or improvements.

IMHO Michael Scharf made an excellent argument for PS status for CUBIC on
Feb 22 (
https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/ )
by simply quoting a definition of PS from RFC 7127:

   A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.  Proposed Standards are
   of such quality that implementations can be deployed in the Internet.
   However, as with all technical specifications, Proposed Standards may
   be revised if problems are found or better solutions are identified,
   when experiences with deploying implementations of such technologies
   at scale is gathered.


It seems clear, IMHO, that CUBIC meets those criteria for being named a PS.

best regards,
neal