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

Yuchung Cheng <ycheng@google.com> Mon, 28 February 2022 20:07 UTC

Return-Path: <ycheng@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECE93A1308 for <tcpm@ietfa.amsl.com>; Mon, 28 Feb 2022 12:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.61
X-Spam-Level:
X-Spam-Status: No, score=-17.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTTCE8jxBxVd for <tcpm@ietfa.amsl.com>; Mon, 28 Feb 2022 12:07:53 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9256A3A1304 for <tcpm@ietf.org>; Mon, 28 Feb 2022 12:07:53 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id d17so17158247wrc.9 for <tcpm@ietf.org>; Mon, 28 Feb 2022 12:07:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=r7a9p1iH7r672DzK9pbHKecNgcCJcqBdhP1X9FV3q0A=; b=qhdEJcILmy4QekaHhFBa5te4QxB2rE86LNTXIp6sW5kELXLm41Uszrk03xiIQkqbWr n2N3+5vWhzme9swyjZFOJ4QvrmFvWL1W3cT97/JsHdH98OcznkPgXVTU9Bz+EiDozk7P R/GfTLKyhhz7z950YXaStaCSAxfy3xTNRk6uyDsVWQR2FmrlRb6IMdjsDOKixYvh/mu3 SsikL+pjCti4l/PIKY4rcIMi2Lub8ruefFTNOdje/l4+APURr87uZklKS/ObfCA5aLEx sNmbMENF3krDUbtX95sILPQcEmQRbnXvI/2X/lIKOE369VtdYPJ2YISQWSL7LVTTZnfO dqYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=r7a9p1iH7r672DzK9pbHKecNgcCJcqBdhP1X9FV3q0A=; b=1Mk95P9aRafY5w75pnVEVXUaE2sfZKC5rJaz5lYjuaR6mUO84CMP4qlZ9SzlNRnUiT nPQT0HRlygbudbJeZECJKcExsbHFqsep89Hax4cea7fn6gShUf63Bo3r+PUXBUvAHs2t YdqsU5xAKRkGD0Q8Bgd4GsVyJpesOm5ldCUHeSU8xwGsXBe8dxr5Hj/q8l//LRoEdTeR t6v2sX/1WN9wMRUD7wOqmHvLVltZ8oTR2b3R/XXZ2IkK9GW0rCmihaeO+m6sYL5oECXw 3rnnrQ44ZN6mnHQYczowql6L06WgV08fhs8aITlVJLnCFdgI4ct2cI4Gb0SVtrXc489J P3sA==
X-Gm-Message-State: AOAM530vw7UKqpK/y0l5we2HkD1UGOvgW/mcTcUW19pC+C2YOdUXbrXo bNjwG8TuysMC2gRUFyzHsYFpyk1g+R+01kY/VfOGYeKvtDuGsQ==
X-Google-Smtp-Source: ABdhPJzU6562HdNu3PJXgn9SmNxG3BVKiAFlcsOqEr86GHdIYknAWMVDRBfT/GAMTt9Ym/G2u9T2ZSjv0HkHimvHwKM=
X-Received: by 2002:adf:d212:0:b0:1ef:6e7a:b04c with SMTP id j18-20020adfd212000000b001ef6e7ab04cmr12620858wrh.412.1646078871445; Mon, 28 Feb 2022 12:07:51 -0800 (PST)
MIME-Version: 1.0
References: <164318837039.21788.17451980682651967578@ietfa.amsl.com> <EEA435EC-AAAC-4899-8E94-2D54EDE5F72E@eggert.org> <CAAK044S9HQXvfvgM6mBuvOWJPHtCaa6xo6CoP2r8Vq61tKaY5g@mail.gmail.com> <CAAK044Q5Lv175T6RcVp+XKEfqZ=Z_+TfjJ5Q9NzzA6wVerMkSw@mail.gmail.com> <CADVnQykqf5zU-or7VbjcaU8ARTv1AOt0zR+xVquBG8ck5SqyRA@mail.gmail.com> <C0D01F76-5519-49AF-8AEE-93A04E723F86@apple.com>
In-Reply-To: <C0D01F76-5519-49AF-8AEE-93A04E723F86@apple.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Mon, 28 Feb 2022 12:07:14 -0800
Message-ID: <CAK6E8=dkJrw0Vv6du-CMASjydSTXxzDXM4z=O191R4t+NeE7dg@mail.gmail.com>
To: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>
Cc: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/GJdxuMlogsEwB2HaYPpHob9Q7b0>
Subject: Re: [tcpm] Proceeding 8312bis draft (Re: 2nd WGLC for draft-ietf-tcpm-rfc8312bis)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Feb 2022 20:07:57 -0000

+1 to Neal and Vidhi's comments.

On Mon, Feb 28, 2022 at 11:23 AM Vidhi Goel
<vidhi_goel=40apple.com@dmarc.ietf.org> wrote:
>
> 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:
>
>
> 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=40google.com@dmarc.ietf.org> wrote:
>
>
>
> On Mon, Feb 28, 2022 at 5:07 AM Yoshifumi Nishida <nsd.ietf@gmail.com> 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
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm