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

[Vidhi Goel <[e-mail]>]

> 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/ <https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/> ) by simply quoting a definition of PS from RFC 7127:
> 

I agree with Neal’s suggestion based on PS status definition from the above RFC.


Thanks,
Vidhi

> On Feb 28, 2022, at 6:29 AM, Neal Cardwell <ncardwell=[e-mail]> wrote:
> 
> 
> 
> On Mon, Feb 28, 2022 at 5:07 AM Yoshifumi Nishida <[e-mail] <mailto:[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/ <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
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>