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

Bob Briscoe <ietf@bobbriscoe.net> Thu, 20 October 2022 22:48 UTC

Return-Path: <ietf@bobbriscoe.net>
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 65CE2C1522D1; Thu, 20 Oct 2022 15:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 T6CGyi3st7CE; Thu, 20 Oct 2022 15:48:17 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701F1C1522CA; Thu, 20 Oct 2022 15:48:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7vsG3kVHRc0ExXOHKl9P9nwaUHHjcsS7DAXkNE/GSgs=; b=yCUrDapm+MN/AnMKRVACiHERor w7LSjld+MwQJDLWbXjhbMM1eNevgOJnh2TxRRZ01oz4IOqFYFIlDCa1maLGpGzygb9lX8eC2iye4e Vas/y4JB6u+sZifbjVJaBbKdL4zaMNJxHL2nu+gN2H1KlJmO7sqsm594wsYSp9WpFoVzjRL13982F DULbHoAGCi/V+u6vQZrDZhfS7KjGxIpojsdOsOcMHSOKRvgh7TW+Fq98oI/JuaQKUPrJAhwxcUk2W /dQYxsM1PI1HUST5/XJQy1NP10ZLHB1L9+D8823uSCcsFxP9LnYUzUnJtSHtDRcD0lvwkqZu9reDK w9FIfQaw==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:54506 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <ietf@bobbriscoe.net>) id 1oleKo-000hhL-VN; Thu, 20 Oct 2022 23:48:10 +0100
Message-ID: <9f661bba-a032-6c72-f83c-0b6ba607e464@bobbriscoe.net>
Date: Thu, 20 Oct 2022 23:48:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Content-Language: en-GB
To: Alice Russo <arusso@amsl.com>
Cc: koen.de_schepper@nokia.com, marcelo@it.uc3m.es, g.white@cablelabs.com, tsvwg-ads@ietf.org, tsvwg-chairs@ietf.org, wes@mti-systems.com, auth48archive@rfc-editor.org, RFC Editor <rfc-editor@rfc-editor.org>
References: <20221007211253.DA9DD5BFC54@rfcpa.amsl.com> <626f77f5-1de0-2e06-29cf-48642883112b@bobbriscoe.net> <E14D3546-6EF1-4190-8160-652E7E1C2DB0@amsl.com> <0d9009a6-abee-14fc-37cd-abcdb76b00bc@bobbriscoe.net> <CF4544EA-D89E-4644-B1A6-7A2E0CA4FD74@amsl.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
In-Reply-To: <CF4544EA-D89E-4644-B1A6-7A2E0CA4FD74@amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - rfc-editor.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/1Um1vwZD3xZHkZrSylYTK-BVtII>
Subject: Re: [auth48] changed to RFC-to-be 9330 - Re: AUTH48: RFC-to-be 9324 <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: Thu, 20 Oct 2022 22:48:21 -0000

Alice,

All understood and thank you.

1) Status of my review of l4s-arch AUTH48
I'm nearly done on reviewing all the changes to l4s-arch. But mañana now 
(UK time).

2) Looking ahead to ecn-l4s-id and aqm-dualq-coupled
You might recall that I pointed to XML with minor updates from those 
submitted (item 3 in my email to rfc-editor of 12 Sep 2022).
Would you rather I submitted those XML files formally as new revisions, 
before you start each one? Or would that cause some sort of reset on the 
IESG approval?


Bob

On 20/10/2022 21:48, Alice Russo wrote:
> Bob,
> Thanks for your reply; yes, this helps.
>
> A new RFC number has been assigned (and the files have been renamed) because of the request for contiguous RFC numbers. Authors and relevant parties will receive a separate AUTH48 notification mail.
>
> Changes made thus far during AUTH48 have been retained; see the new AUTH48 status page [2].
>
> We have added draft-ietf-tsvwg-l4s-arch to Cluster 350 [1] because of your request that it be published with the other documents.  (FYI, the only way to do this within the RPC’s current workflow is to add data that says it has as normative reference (or vice versa) for a document within that cluster, so it now appears as having a reference to draft-ietf-tsvwg-ecn-l4s-id.)
>
> Just let us know if you have questions.
>
> [1] https://www.rfc-editor.org/cluster_info.php?cid=C350
> [2] https://www.rfc-editor.org/auth48/rfc9330
>
> Thank you.
> RFC Editor/ar
>
>> On Oct 20, 2022, at 11:26 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>
>> Alice,
>>
>> On 20/10/2022 18:38, Alice Russo wrote:
>>> Bob,
>>>
>>> You wrote:
>>>> One question that might clear up a misunderstanding on my part:
>>>> Your Q11 ask for our preferences for the [ECN-L4S] short name, but I would have thought this would use the RFC-to-be short-name, given I would hope the three L4S drafts that were all approved together will all be published together.
>>> Regarding:
>>> A) draft-ietf-tsvwg-l4s-arch   (AUTH48 state as RFC-to-be 9324)
>>> B) draft-ietf-tsvwg-ecn-l4s-id (RFC-EDITOR state)  - informative ref to A.
>>> C) draft-ietf-tsvwg-aqm-dualq-coupled (EDIT*R state) - informative ref to A.
>>>
>>>
>>> On Sep 12, 2022, at 5:21 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>>> • Each is intended to be comprehensible stand-alone
>>> We understood that statement — and the lack of normative references to or from draft-ietf-tsvwg-l4s-arch — to mean that to mean that document could proceed to publication on its own.
>> [BB] No, no. Sorry. That was from a reader's perspective. Not about publication grouping.
>>
>>> At this point, is it accurate that you want these 3 documents to be published at the same time? And that you want them to be assigned contiguous RFC numbers?
>> [BB] Yes. Sorry, I thought that was the reason they all went through the IESG together. I didn't understand that that was not the publication plan (I've only published single RFCs before).
>>
>> They all refer to each other dozens of times, so it would seem crazy for the first one to refer to the others as drafts, when a few days later it could refer to them as RFCs.
>> They've been 7 years in the brew, a few more days is nothing.
>>
>>> Essentially, it seems that you would like draft-ietf-tsvwg-l4s-arch to be part of cluster 350.
>>>
>>> For background, a cluster of documents is typically formed by normative references, or sometimes by specific request. https://www.rfc-editor.org/about/clusters/ has more info.
>> [BB] I would suggest that only these three get published together:
>> * l4s-arch
>> * ecn-l4s-is
>> * aqm-dualq-coupled
>>
>> These two have other normative dependencies, so we wouldn't want to have to wait for them:
>> * trill-ecn-support
>> * docsis-q-protection
>>
>> Is that clearer now?
>>
>> Cheers
>>
>>
>> Bob
>>
>>
>>> Thank you.
>>> RFC Editor/ar
>>>
>>>> On Oct 19, 2022, at 10:28 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I thought I had better let you know that I've been working on this.
>>>> I missed the email at first, and it's taking much longer than expected to check through all the changes (2 days now).
>>>> Hopefully, my response will be with you tomorrow.
>>>>
>>>> One question that might clear up a misunderstanding on my part:
>>>> Your Q11 ask for our preferences for the [ECN-L4S] short name, but I would have thought this would use the RFC-to-be short-name, given I would hope the three L4S drafts that were all approved together will all be published together.
>>>>
>>>> Regards
>>>>
>>>>
>>>> Bob
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/