Re: [ippm] WG adoption call for RFC8321bis and 8889bis

Aijun Wang <wangaijun@tsinghua.org.cn> Mon, 18 April 2022 04:04 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79363A1BC7 for <ippm@ietfa.amsl.com>; Sun, 17 Apr 2022 21:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 iXkaInWvvLpO for <ippm@ietfa.amsl.com>; Sun, 17 Apr 2022 21:04:31 -0700 (PDT)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF843A1BC3 for <ippm@ietf.org>; Sun, 17 Apr 2022 21:04:29 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id C537A1C01D5; Mon, 18 Apr 2022 12:04:26 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Giuseppe Fioccola' <giuseppe.fioccola=40huawei.com@dmarc.ietf.org>, 't petch' <ietfa@btconnect.com>, 'Tommy Pauly' <tpauly=40apple.com@dmarc.ietf.org>, 'IETF IPPM WG' <ippm@ietf.org>
References: <CAM4esxQHrH7onttT6MV+DGuM24cQW99pZ83wOAK_88BcAP43Rw@mail.gmail.com> <17AA8D9D-CDEC-4CF3-938A-4280CE08A51A@apple.com> <624FF58D.1050407@btconnect.com> <624FFFEB.2010606@btconnect.com> <8a76022b687c42d9a165d40440ef0374@huawei.com> <6250567F.1080905@btconnect.com> <09050b84e7f248b6864739cd609266f1@huawei.com>
In-Reply-To: <09050b84e7f248b6864739cd609266f1@huawei.com>
Date: Mon, 18 Apr 2022 12:04:25 +0800
Message-ID: <01c501d852d9$64d7e140$2e87a3c0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ3ZU9VHfE21JYG8M9EbKOxNxYBtwHsdHnfAb6HnrsBncGtgAJhv8r6Aosq3w4CsSZy+qtPrbXw
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZCBgUCR5ZQVlLVUtZV1 kWDxoPAgseWUFZKDYvK1lXWShZQUpMS0tKN1dZLVlBSVdZDwkaFQgSH1lBWUMZTB9WHhpOH0hNTk sfHx1NVRMBExYaEhckFA4PWVdZFhoPEhUdFFlBWU9LSFVKSktITUpVS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PRg6Khw4PT08TTYxLw0BOk0c ESJPCRdVSlVKTU5LSU5PTU1MSE5KVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpLSkJNNwY+
X-HM-Tid: 0a803ad7dcc7d993kuwsc537a1c01d5
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ABR4fQpxRZAxB0ngm9mE7zTrYj8>
Subject: Re: [ippm] WG adoption call for RFC8321bis and 8889bis
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2022 04:04:38 -0000

Hi, All:
I support these two documents' adoptions.
And I also concur with the discussion conclusion, that there should be one
summary of the changes at the begin of the documents.

And, once it is adopted ,should the contents in
https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-13 be
simplified? It seems that that document describes also all the methodologies
again?


Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: ippm-bounces@ietf.org <ippm-bounces@ietf.org> On Behalf Of Giuseppe
Fioccola
Sent: Saturday, April 9, 2022 2:05 AM
To: t petch <ietfa@btconnect.com>; Tommy Pauly
<tpauly=40apple.com@dmarc.ietf.org>; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] WG adoption call for RFC8321bis and 8889bis

Hi Tom,
Please see my replies inline tagged as [GF].

Regards,

Giuseppe 

-----Original Message-----
From: t petch <ietfa@btconnect.com>
Sent: Friday, April 8, 2022 5:37 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; Tommy Pauly
<tpauly=40apple.com@dmarc.ietf.org>; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] WG adoption call for RFC8321bis and 8889bis

On 08/04/2022 10:52, Giuseppe Fioccola wrote:
> Hi Tom,
> Thank you for your feedback.
> Please find my answers inline tagged as [GF].
>
> Regards,
>
> Giuseppe
>
> -----Original Message-----
> From: ippm <ippm-bounces@ietf.org> On Behalf Of t petch
> Sent: Friday, April 8, 2022 11:27 AM
> To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>; IETF IPPM WG 
> <ippm@ietf.org>
> Subject: Re: [ippm] WG adoption call for RFC8321bis and 8889bis
>
> On 08/04/2022 09:42, t petch wrote:
>> On 08/04/2022 01:03, Tommy Pauly wrote:
>>> Hello IPPM,
<snip>
>>
>> 'this document'
>> Which document?
>>
>> Please post subsequent e-mails about one I-D only with the subject 
>> line indicating which, else I will get confused (and may well confuse 
>> others with my comments).
>
> I note that 'this document' fails to give any explanation of why it exists
(beyond the boiler-plate that tells me it is obsoleting)?
>
> Why?  I may know the answer but think it wrong to assume that others will.
>
> This should be in the Introduction and there should also be a 'Changes
from ...'
>
> [GF]: Sure. I will add the explanation in the introduction of both
RFC8321bis and RFC8889bis. It is to elevate the Experimental RFCs to
Standard Track. There are several implementations (e.g.
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/  that need a
normative reference for the methodology. Our initial approach was to use the
informative reference but it was not accepted by the IESG. Therefore it was
suggested to obsolete the experimental docs with new standard docs.

Yes.  I have followed the thread and did voice my support for new RFC which
I am glad to see.  And below ...

[GF]: Thank you for the support.

> Please note that, for both drafts, you can find the Changes Log in
Appendix with all the modifications from the original RFCs for each version.
  ... Yes but that is not quite what I had in mind.   Think of an 
implementor who has accurately implemented RFC8321; they need to know if and
how to change the code, they do not want a blow-by-blow account of every
text change, how the RFC-to-be came to be what it is, just a statement of
what needs changing where (if anything); and an Appendix labelled 'Changes
Log', while helpful for the WG, is a candidate for excision by the RFC
Editor whereas I am thinking of an Informative appendix that is referenced
by the Introduction - 'Appendix X contains a list of technical changes from
RFC8321'. Look at RFC7950; this lists the changes from RFC6020 and, at the
insistence of the AD, the list was split into NBC and BC and was put up
front.  Your changes are likely minor but I think that RFC7950 is a template
of how to format a new version of a protocol.

[GF]: Thanks for the suggestion. We can surely consider to follow the
template of RFC7950. We are elevating the experimental RFCs to standard
track so all the changes are just about the structure, further clarification
and the use of a standard wording. No new additions to the methodology have
been made. I can write a summary of the changes after the Introduction and
it can be a short section that reports the recommendations for the
implementation included in the standard track draft.

Tom Petch

> Tom Petch
>
>>
>> Tom Petch
>>
>>> Best,
>>> Tommy & Marcus
>>>
>>>> On Apr 7, 2022, at 1:16 PM, Martin Duke <martin.h.duke@gmail.com>
wrote:
>>>>
>>>> Hello IPPM,
>>>>
>>>> You may recall that there was a need to progress RFC8321 and
>>>> RFC8889 from Experimental to Proposed Standard. There was a feeling 
>>>> that the update would be trivial and we could therefore do it as an 
>>>> AD sponsored document.
>>>>
>>>> I've done 3 rounds of AD review and I've seen the need to 
>>>> substantially adjust the scope of these documents and tweak the 
>>>> design in places. The changes are not revolutionary, but I'm a 
>>>> non-practitioner and have driven some design changes with minimal 
>>>> review. At this point I think it's important to get good IPPM 
>>>> review; if we're going to do that anyway, we might as well do the
>>>> (expedited) working group process so that there's no confusion as 
>>>> to why IPPM didn't formally review an update to its own documents.
>>>>
>>>> So, as first step, I invite the working group to adopt these two
drafts:
>>>> https://datatracker.ietf.org/doc/draft-fioccola-rfc8321bis/
>>>> <https://datatracker.ietf.org/doc/draft-fioccola-rfc8321bis/>
>>>> https://datatracker.ietf.org/doc/draft-fioccola-rfc8889bis/
>>>> <https://datatracker.ietf.org/doc/draft-fioccola-rfc8889bis/>
>>>> Any objections to adoption, as always, should be to the value of 
>>>> doing the work at all, and the general direction of the drafts. I 
>>>> hope to follow up the adoption call with an immediate WGLC to shake 
>>>> out any detailed objections, though we will take as long as we need 
>>>> to address concerns that people have.
>>>>
>>>> I invite you to consult the changelogs on both of these documents, 
>>>> which are not long, to get a sense of what we've done.
>>>>
>>>> For those of you who like diffs, there was a big reorganization 
>>>> between draft-02 and -03 that is hard to follow in a diff. So here 
>>>> is a set of diffs that exclude the -02 to -03 transition:
>>>> https://www.ietf.org/rfcdiff?url1=rfc8321.txt&url2=draft-fioccola-r
>>>> f
>>>> c8321bis-02.txt
>>>> <https://www.ietf.org/rfcdiff?url1=rfc8321.txt&url2=draft-fioccola-
>>>> r
>>>> fc8321bis-02.txt>
>>>>
>>>> https://www.ietf.org/rfcdiff?url1=draft-fioccola-rfc8321bis-03.txt&
>>>> u rl2=draft-fioccola-rfc8321bis-04.txt
>>>> <https://www.ietf.org/rfcdiff?url1=draft-fioccola-rfc8321bis-03.txt
>>>> & url2=draft-fioccola-rfc8321bis-04.txt>
>>>>
>>>>
>>>> https://www.ietf.org/rfcdiff?url1=rfc8889.txt&url2=draft-fioccola-r
>>>> f
>>>> c8889bis-02.txt
>>>> <https://www.ietf.org/rfcdiff?url1=rfc8889.txt&url2=draft-fioccola-
>>>> r
>>>> fc8889bis-02.txt>
>>>>
>>>> https://www.ietf.org/rfcdiff?url1=draft-fioccola-rfc8889bis-03.txt&
>>>> u rl2=draft-fioccola-rfc8889bis-04.txt
>>>> <https://www.ietf.org/rfcdiff?url1=draft-fioccola-rfc8889bis-03.txt
>>>> & url2=draft-fioccola-rfc8889bis-04.txt>
>>>>
>>>>
>>>> I believe it's up to the chairs to start the adoption call. If 
>>>> people are good about reading the document during WGLC, I would 
>>>> like to think we could be done before IETF 114.
>>>>
>>>> Your friendly Area Director,
>>>> Martin
>>>>
>>>> _______________________________________________
>>>> ippm mailing list
>>>> ippm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ippm
>>>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
> .
>

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm