Re: [auth48] [C350] AUTH48: RFC-to-be 9330 <draft-ietf-tsvwg-l4s-arch-20> for your review

Alanna Paloma <apaloma@amsl.com> Sat, 14 January 2023 00:39 UTC

Return-Path: <apaloma@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E05C16FE4E; Fri, 13 Jan 2023 16:39:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31fAP-rj3jXr; Fri, 13 Jan 2023 16:39:35 -0800 (PST)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86BAC15E3FC; Fri, 13 Jan 2023 16:39:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 92E64424B44A; Fri, 13 Jan 2023 16:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZfBRtRrjNIl; Fri, 13 Jan 2023 16:39:34 -0800 (PST)
Received: from amss-mbp.attlocal.net (unknown [IPv6:2600:1700:bac0:1070:91c2:e383:ca95:12b1]) by c8a.amsl.com (Postfix) with ESMTPSA id 1223C424B440; Fri, 13 Jan 2023 16:39:34 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Alanna Paloma <apaloma@amsl.com>
In-Reply-To: <CAM4esxR9s6FkT=y1a4JvkYnAAfx1mDLqtSzPn69-apbm68EmsA@mail.gmail.com>
Date: Fri, 13 Jan 2023 16:39:33 -0800
Cc: Karen Moore <kmoore@amsl.com>, Alice Russo <arusso@amsl.com>, "tsvwg-ads@ietf.org" <tsvwg-ads@ietf.org>, Wesley Eddy <wes@mti-systems.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D306A4A4-A105-4CAB-B318-BDE33C142DE4@amsl.com>
References: <20221020205831.7354E15D30D@rfcpa.amsl.com> <CAM4esxQG7tRfyZRe46LHZYHO+1DDa=Me4W=417NRkRXiGX-+aw@mail.gmail.com> <96A41D8E-05C6-42FB-83CC-C32E9D35CF67@amsl.com> <14E7304B-A823-4B1D-AE74-1B6F97C5D55D@cablelabs.com> <b5a1c8b8-d531-03e6-2939-3cfbd3edba4a@it.uc3m.es> <963B4F4C-9ED8-4E22-B8D2-4786BE1D77E2@amsl.com> <6f9cf7a5-6637-3594-5767-28ed9272324b@bobbriscoe.net> <AM9PR07MB731362C123C84C35439AD9D1B90F9@AM9PR07MB7313.eurprd07.prod.outlook.com> <9FFDF6A1-714B-4537-B368-B308A343205F@amsl.com> <91f2b145-63fe-89b5-3e45-72e9bc0610ba@bobbriscoe.net> <4B9E6B47-35C3-41EA-AA69-D15A33EA53EA@amsl.com> <500fcfa9-d211-7420-5d06-c92fa42d4c70@bobbriscoe.net> <C93D9134-E7BC-44DB-A9A8-D6200BA2C700@amsl.com> <06fab222-2cd4-2d46-7d7e-a18f43a97977@bobbriscoe.net> <CAC103CA-C068-4B68-9EFE-820CD7A18139@amsl.com> <7cc1eefa-eb32-fba8-9a75-02d825851e4c@bobbriscoe.net> <5102a2c9-82bb-3a2b-cbd3-5e64edacf0a7@bobbriscoe.net> <E1C043DF-BC40-4F81-93F6-26C127CE4AC1@amsl.com> <65b902bf-1695-e439-d851-10c6914c02ea@bobbriscoe.net> <C5BAFF16-71E9-49AE-8B66-29562B2E2891@amsl.com> <CAM4esxR9s6FkT=y1a4JvkYnAAfx1mDLqtSzPn69-apbm68EmsA@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>, "Koen De Schepper (Nokia)" <koen.de_schepper@nokia-bell-labs.com>, marcelo bagnulo braun <marcelo@it.uc3m.es>, Greg White <g.white@cablelabs.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/4XuEnv-ILDdhWjh6EWQEDXGGnBM>
Subject: Re: [auth48] [C350] AUTH48: RFC-to-be 9330 <draft-ietf-tsvwg-l4s-arch-20> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jan 2023 00:39:39 -0000

Hi Martin and authors,

Thank you for your reply. We have noted you approval on the AUTH48 status page:
https://www.rfc-editor.org/auth48/rfc9330

We have now received all necessary approvals and consider AUTH48 complete. We will move this document forward in the publication process at this time. Thank you for your attention and guidance during the AUTH48 process.

Best regards,
RFC Editor/ap

> On Jan 13, 2023, at 4:28 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> LGTM
> 
> On Fri, Jan 13, 2023 at 4:00 PM Alanna Paloma <apaloma@amsl.com> wrote:
> Hi Bob,
> 
> We’ve updated the files accordingly. We will await Martin’s approval of the most recent changes before moving this document forward in the publication process. 
> 
> The updated files are here (please refresh):
> https://www.rfc-editor.org/authors/rfc9330.html
> https://www.rfc-editor.org/authors/rfc9330.txt
> https://www.rfc-editor.org/authors/rfc9330.pdf
> https://www.rfc-editor.org/authors/rfc9330.xml
> 
> This diff file shows all changes from the approved I-D:
> https://www.rfc-editor.org/authors/rfc9330-diff.html
> https://www.rfc-editor.org/authors/rfc9330-rfcdiff.html (side by side)
> 
> This diff file shows the changes made during AUTH48 thus far:
> https://www.rfc-editor.org/authors/rfc9330-auth48diff.html
> 
> This diff file shows only the changes since the last posted version:
> https://www.rfc-editor.org/authors/rfc9330-lastdiff.html
> 
> Thank you,
> RFC Editor/ap
> 
> > On Jan 13, 2023, at 3:28 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> > 
> > Alanna,
> > 
> > And now I notice that, to make the terminology section consistent with 9331, 9330 still needs the following change:
> > 
> > Current:
> >     e.g., Relentless TCP [RELENTLESS], Prague [PRAGUE-CC] [PragueLinux],
> > Proposed:
> >     e.g., Relentless TCP [RELENTLESS], Prague for TCP and QUIC [PRAGUE-CC] [PragueLinux],
> > 
> > .../then/ I think we're done.
> > 
> > 
> > 
> > Bob
> > 
> > 
> > On 13/01/2023 01:36, Alanna Paloma wrote:
> >> Hi Bob and *Martin,
> >> 
> >> Thank you for the updated XML file.  We notice that “BBRv2” and “BBR” are expanded in this document and RFC-to-be 9332, respectively; would you also like to expand “BBRv2” in Section 1.2 of RFC-to-be 9331?
> >> 
> >> *Martin - As the AD, please review and approve of the changes in the diff file below:
> >> 
> >> https://www.rfc-editor.org/authors/rfc9330-lastdiff.html
> >> 
> >> 
> >> Once we have received Martin’s approval, we will move this document forward in the publication process.
> >> 
> >> The updated files are here (please refresh):
> >> 
> >> https://www.rfc-editor.org/authors/rfc9330.html
> >> https://www.rfc-editor.org/authors/rfc9330.txt
> >> https://www.rfc-editor.org/authors/rfc9330.pdf
> >> https://www.rfc-editor.org/authors/rfc9330.xml
> >> 
> >> 
> >> This diff file shows all changes from the approved I-D:
> >> 
> >> https://www.rfc-editor.org/authors/rfc9330-diff.html
> >> https://www.rfc-editor.org/authors/rfc9330-rfcdiff.html
> >>  (side by side)
> >> 
> >> This diff file shows the changes made during AUTH48 thus far:
> >> 
> >> https://www.rfc-editor.org/authors/rfc9330-auth48diff.html
> >> 
> >> 
> >> This diff file shows only the changes since the last posted version:
> >> 
> >> https://www.rfc-editor.org/authors/rfc9330-lastdiff.html
> >> 
> >> 
> >> This page shows the AUTH48 status of your document:
> >> 
> >> https://www.rfc-editor.org/auth48/rfc9330
> >> 
> >> 
> >> Best regards,
> >> RFC Editor/ap
> >> 
> >> 
> >>> On Jan 12, 2023, at 3:51 PM, Bob Briscoe <ietf@bobbriscoe.net>
> >>>  wrote:
> >>> 
> >>> Alanna, Karen,
> >>> 
> >>> Are we done? Do you need our approvals again for anything. Or Martin's?
> >>> 
> >>> 
> >>> Bob
> >>> 
> >>> On 12/01/2023 01:31, Bob Briscoe wrote:
> >>> 
> >>>> Alanna,
> >>>> 
> >>>> Thank you for the corrections to your edits.
> >>>> I have now applied the expansions of abbreviations that Martin wanted from me, which are attached (denoted rfc9330l) (that's a lower-case 'el' at the end).
> >>>> I have also attached the diff relative to the latest version you made available (which I have denoted as rfc9330k).
> >>>> 
> >>>> Regards
> >>>> 
> >>>> 
> >>>> Bob
> >>>> 
> >>>> On 11/01/2023 23:38, Alanna Paloma wrote:
> >>>> 
> >>>>> Hi Bob,
> >>>>> 
> >>>>> Thank you for your reply. We have updated the files accordingly. Please note that the bug affecting the RFC reference entries has been fixed (i.e., “and RFC Publisher” is no longer present in the entries).
> >>>>> 
> >>>>> Per your note, we will await further changes to the abbreviation expansions before moving forward with publication.
> >>>>> 
> >>>>> 
> >>>>>> I think Martin is expecting you to give me the edit token to deal with the expansions of abbreviations, like he just asked me to do for 9331.
> >>>>>> 
> >>>>> The updated files are here (please refresh):
> >>>>> 
> >>>>> https://www.rfc-editor.org/authors/rfc9330.html
> >>>>> https://www.rfc-editor.org/authors/rfc9330.txt
> >>>>> https://www.rfc-editor.org/authors/rfc9330.pdf
> >>>>> https://www.rfc-editor.org/authors/rfc9330.xml
> >>>>> 
> >>>>> 
> >>>>> This diff file shows all changes from the approved I-D:
> >>>>> 
> >>>>> https://www.rfc-editor.org/authors/rfc9330-diff.html
> >>>>> https://www.rfc-editor.org/authors/rfc9330-rfcdiff.html
> >>>>>  (side by side)
> >>>>> 
> >>>>> This diff file shows the changes made during AUTH48 thus far:
> >>>>> 
> >>>>> https://www.rfc-editor.org/authors/rfc9330-auth48diff.html
> >>>>> 
> >>>>> 
> >>>>> This diff file shows only the changes since the last posted version:
> >>>>> 
> >>>>> https://www.rfc-editor.org/authors/rfc9330-lastdiff.html
> >>>>> 
> >>>>> 
> >>>>> Best regards,
> >>>>> RFC Editor/ap
> >>>>> 
> >>>>> 
> >>>>>> On Jan 10, 2023, at 3:06 PM, Bob Briscoe <ietf@bobbriscoe.net>
> >>>>>>  wrote:
> >>>>>> 
> >>>>>> Alanna,
> >>>>>> 
> >>>>>> #1 [the] flow rate
> >>>>>> 
> >>>>>> I'm afraid as well as reverting the additions of 'the' to 'flow rate', two instances of 'the flow rate' that were correct have incorrectly had 'the' removed:
> >>>>>> 
> >>>>>> 2. L4S Architecture Overview
> >>>>>> CURRENT:
> >>>>>>         This maintains the same degree of control over queuing and
> >>>>>>         utilization, whatever flow rate,
> >>>>>> PROPOSED:
> >>>>>>         This maintains the same degree of control over queuing and
> >>>>>>         utilization, whatever the flow rate,
> >>>>>> 
> >>>>>> 5.1 Why These Primary Components?
> >>>>>> CURRENT:
> >>>>>>        the host keeps the signalling frequency from the network high,
> >>>>>>        whatever flow rate,
> >>>>>> 
> >>>>>> PROPOSED:
> >>>>>>        the host keeps the signalling frequency from the network high,
> >>>>>>        whatever
> >>>>>> the
> >>>>>>   flow rate,
> >>>>>> 
> >>>>>> 
> >>>>>> #2 Hyphenation of Dual-Queue
> >>>>>> 
> >>>>>> Missed one at the end of  "4.2. Network Components" (I did say '5 occurrences'):
> >>>>>> CURRENT:
> >>>>>>        it means a dual queue AQM with per-queue marking
> >>>>>> PROPOSED:
> >>>>>>        it means a dual-queue AQM with per-queue marking
> >>>>>> Note: This is not capitalized deliberately, because it means just any AQM with two queues, not the name of the specific Dual-Queue Coupled AQM.
> >>>>>> 
> >>>>>> #3 RFCYYY1
> >>>>>> 
> >>>>>> Also, I assume RFCYYY1 can now become RFC9332
> >>>>>> 
> >>>>>> #4 The 'and RFC Publisher' bug
> >>>>>> 
> >>>>>> For completeness, I'll keep pointing this out until the bug is fixed.
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> Bob
> >>>>>> 
> >>>>>> On 09/01/2023 20:37, Alanna Paloma wrote:
> >>>>>> 
> >>>>>>> Hi Bob,
> >>>>>>> 
> >>>>>>> Apologies for the delay. We had made the changes internally, and they are now available for your review.
> >>>>>>> 
> >>>>>>> The updated files are here (please refresh):
> >>>>>>> 
> >>>>>>> 
> >>>>>>> https://www.rfc-editor.org/authors/rfc9330.html
> >>>>>>> https://www.rfc-editor.org/authors/rfc9330.txt
> >>>>>>> https://www.rfc-editor.org/authors/rfc9330.pdf
> >>>>>>> https://www.rfc-editor.org/authors/rfc9330.xml
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> This diff file shows all changes from the approved I-D:
> >>>>>>> 
> >>>>>>> 
> >>>>>>> https://www.rfc-editor.org/authors/rfc9330-diff.html
> >>>>>>> https://www.rfc-editor.org/authors/rfc9330-rfcdiff.html
> >>>>>>> 
> >>>>>>>   (side by side)
> >>>>>>> 
> >>>>>>> This diff file shows the changes made during AUTH48 thus far:
> >>>>>>> 
> >>>>>>> 
> >>>>>>> https://www.rfc-editor.org/authors/rfc9330-auth48diff.html
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> This diff file shows only the changes since the last posted version:
> >>>>>>> 
> >>>>>>> 
> >>>>>>> https://www.rfc-editor.org/authors/rfc9330-lastdiff.html
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> Best regards,
> >>>>>>> RFC Editor/ap
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>>> On Jan 7, 2023, at 8:50 AM, Bob Briscoe <ietf@bobbriscoe.net>
> >>>>>>>> 
> >>>>>>>>   wrote:
> >>>>>>>> 
> >>>>>>>> Alanna, Karen,
> >>>>>>>> 
> >>>>>>>> In the related thread Subject: "Re: [C350] AUTH48: RFC-to-be 9332 <draft-ietf-tsvwg-aqm-dualq-coupled-25> for your review"
> >>>>>>>> On 05/01/2023 19:54, Karen Moore wrote:
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>>> Notes:
> >>>>>>>>> 
> >>>>>>>>> 1) Hyphenated “Dual Queue” in RFCs-to-be 9330 and 9331.
> >>>>>>>>> 2) Removed “the” before “flow rate” in RFCs-to-be 9330 and 9331.
> >>>>>>>>> 3) Updated “[SCReAM]” to  “[SCReAM-L4S]”  to match RFCs-to-be 9330 and 9331.
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>> But under the https://www.rfc-editor.org/authors/
> >>>>>>>> 
> >>>>>>>>   area, only 9331 seems to have been updated recently, not 9330.
> >>>>>>>> I've tried refreshing the page etc.
> >>>>>>>> 
> >>>>>>>> I think Martin is expecting you to give me the edit token to deal with the expansions of abbreviations, like he just asked me to do for 9331.
> >>>>>>>> This is to clarify that I will not take the token for 9330 until you have made the above edits.
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> Bob
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> On 02/12/2022 00:18, Alanna Paloma wrote:
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>>> Hi Bob,
> >>>>>>>>> 
> >>>>>>>>> Apologies for not being clear. Once the terminology from RFCs-to-be 9331 and 9332 are finalized, we will update RFC-to-be 9330 accordingly. When these 3 documents have completed AUTH48, they will move forward in the publication process without waiting for the 2 documents currently in MISSREF.
> >>>>>>>>> 
> >>>>>>>>> Best regards,
> >>>>>>>>> RFC Editor/ap
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>>> On Nov 30, 2022, at 5:02 PM, Bob Briscoe <ietf@bobbriscoe.net>
> >>>>>>>>>> 
> >>>>>>>>>>   wrote:
> >>>>>>>>>> 
> >>>>>>>>>> Alanna, (and possibly Alice?)
> >>>>>>>>>> 
> >>>>>>>>>> On 29/11/2022 22:32, Alanna Paloma wrote:
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>>> Bob - We have reverted the change to the list of examples, and we will hold this document until the cluster terminology has been finalized.
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>> To clarify, do you believe "the cluster terminology will have been finalized" when
> >>>>>>>>>> 1) the terminology sections of l4s-arch (RFC-to-be-9330) and ecn-l4sid (RFC-to-be-9331) have both been finalized and made consistent with each other? Or
> >>>>>>>>>> 2) when all 5 drafts in the cluster have been finalized (2 of which are missref's, so this second option would hold back the other 3 for a long time)?
> >>>>>>>>>> 
> >>>>>>>>>> I think it would make sense to publish the three main L4S drafts in the cluster at the same time (RFCs-to-be 9330, 9331, 9332), but I don't see any need to wait for the other two.
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> Bob
> >>>>>>>>>> 
> >>>>>>>>>> -- 
> >>>>>>>>>> ________________________________________________________________
> >>>>>>>>>> Bob Briscoe
> >>>>>>>>>> 
> >>>>>>>>>> http://bobbriscoe.net/
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>> -- 
> >>>>>>>> ________________________________________________________________
> >>>>>>>> Bob Briscoe
> >>>>>>>> 
> >>>>>>>> http://bobbriscoe.net/
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> 
> >>>>>> -- 
> >>>>>> ________________________________________________________________
> >>>>>> Bob Briscoe
> >>>>>> 
> >>>>>> http://bobbriscoe.net/
> >>> -- 
> >>> ________________________________________________________________
> >>> Bob Briscoe                               
> >>> http://bobbriscoe.net/
> >>> 
> >>> 
> >>> 
> > 
> > -- 
> > ________________________________________________________________
> > Bob Briscoe                               
> > http://bobbriscoe.net/
>