Thank you for your reply, Tony! The RFC has now been announced. Thank you!
> On Feb 14, 2025, at 3:13 PM, Tony Li <tony...@tony.li> wrote: > > > Hi Sandy, > > I’m fine with that. > > T > > >> On Feb 14, 2025, at 2:12 PM, Sandy Ginoza - sginoza at staff.rfc-editor.org >> <mailforwa...@cloudmails.net> wrote: >> >> Greetings all, >> >> Thank you for the explanations - with that in mind, we make a last attempt >> to improve the clarity of this paragraph. The last sentence clarifies who >> agreed that the document should be moved to Historic (which also clarifies >> some process implications for the RPC). Please consider whether the >> following update is acceptable. >> >> Original: >> Note that in parallel to the work of this document, there is ongoing >> work on MPLS Network Actions (MNA) [RFC9613]. The MPLS performance >> measurement with the Alternate-Marking method can also be achieved by >> MNA encapsulation. In addition, MNA will provide a broader use case >> applicability. That means the MNA encapsulation is expected to >> provide a more advanced solution, when published as an RFC and it is >> agreed that this document will be made Historic at that time. >> >> >> Perhaps: >> Note that, at the time of writing, there is ongoing >> work on MPLS Network Actions (MNAs) [RFC9613]. The MPLS performance >> measurement with the Alternate-Marking method can also be achieved by >> MNA encapsulation. In addition, MNA will provide a broader use case >> applicability. That means the MNA encapsulation is expected to >> provide a more advanced solution. The MPLS Working Group has agreed >> that this document will be made Historic when that solution is published as >> an RFC. >> >> Thank you, >> RFC Editor/sg >> >> >>> On Feb 10, 2025, at 2:10 PM, Tony Li <tony...@tony.li> wrote: >>> >>> >>> Hi, >>> >>> Jim’s memory is correct and the original text is exactly what is intended. >>> >>> The proposed text is a bit over-ambitious. [MNA-PM-with-AMM] is still very >>> much a draft and has not been accepted by the working group, and it is not >>> at all clear that it will eventually become an RFC. Other proposals may >>> happen and may overtake [MNA-PM-with-AMM], so the original text was a bit >>> more open to account for that kind of outcome. >>> >>> When there is a successor, yes, there will need to be a separate status >>> change, following normal procedures. We are trying to let the reader know >>> that this change is planned, so that they may adapt accordingly. >>> >>> Regards, >>> Tony >>> >>> >>> >>>> On Feb 10, 2025, at 1:54 PM, Alice Russo - arusso at staff.rfc-editor.org >>>> <mailforwa...@cloudmails.net> wrote: >>>> >>>> Jim (as AD), Tony (as WG chair), >>>> >>>> Re: Section 1 of https://www.rfc-editor.org/authors/rfc9714.txt (details >>>> below). >>>> >>>> Jim wrote: >>>>> Yes, a separate status change would need to take place. By agreed it >>>>> means the WG agreed to it and the expectation is that at some point in >>>>> the future it will become historic and that will be once MNA becomes an >>>>> RFC. >>>> >>>> Is the following text accurate? We'd like to avoid confusion that the >>>> decision is already complete (i.e., without a status change expected or >>>> needed) that RFC 9714 would be moved to Historic when [MNA-PM-with-AMM] is >>>> published. >>>> >>>> Original: >>>> That means the MNA encapsulation is expected to >>>> provide a more advanced solution, when published as an RFC and it is >>>> agreed that this document will be made Historic at that time. >>>> >>>> Perhaps: >>>> That means the MNA encapsulation is expected to >>>> provide a more advanced solution. The MPLS Working Group >>>> expects that this RFC will be changed to Historic once >>>> [MNA-PM-with-AMM] is published as an RFC. >>>> >>>> >>>> Thank you. >>>> RFC Editor/ar >>>> >>>>> On Feb 7, 2025, at 9:52 AM, James Guichard >>>>> <james.n.guich...@futurewei.com> wrote: >>>>> >>>>> Further, I would like for the mpls-chairs to confirm my >>>>> understanding/recollection of that text. Tony? >>>>> >>>>> Jim >>>> >>>> >>>> >>>>> On Feb 7, 2025, at 10:38 AM, Alice Russo <aru...@staff.rfc-editor.org> >>>>> wrote: >>>>> >>>>> Hi Jim, >>>>> >>>>> Thanks for your reply. For clarity, the issues with the original sentence >>>>> (pasted below) are because it is about a status change (e.g., a potential >>>>> future change from Proposed Standard to Historic) within the RFC series. >>>>> >>>>> Original: >>>>>> That means the MNA encapsulation is expected to >>>>>> provide a more advanced solution, when published as an RFC and it is >>>>>> agreed that this document will be made Historic at that time. >>>>> >>>>> >>>>> Specifically, the issues are: >>>>> 1) Unclear when what exactly is "published as an RFC". >>>>> 2) Stating it is already "agreed" that the current document "will be made >>>>> Historic". We understand that a separate status change process would need >>>>> to take place. Please correct us if we've misunderstood. >>>>> >>>>> Thank you. >>>>> RFC Editor/ar >>>> >>>>> On Feb 7, 2025, at 9:50 AM, James Guichard >>>>> <james.n.guich...@futurewei.com> wrote: >>>>> >>>>> Hi Alice, >>>>> >>>>> No, I am not okay with this change but more specifically the last >>>>> sentence. The introduction of “possibly” is not what was agreed to during >>>>> review. The original text for the last sentence should stay as-is. I am >>>>> okay with the other changes. >>>>> >>>>> Jim >>>>> >>>>> From: Alice Russo <aru...@staff.rfc-editor.org> >>>>> Date: Friday, February 7, 2025 at 12:46 PM >>>>> To: James Guichard <james.n.guich...@futurewei.com> >>>>> Cc: xiao.m...@zte.com.cn <xiao.m...@zte.com.cn>, 程伟强 >>>>> <chengweiqi...@chinamobile.com>, >>>>> zhoutian...@huawei.com<zhoutian...@huawei.com>, 戴锦友 <d...@fiberhome.com>, >>>>> yoav.peleg <yoav.pe...@broadcom.com>, mpls-ads <mpls-...@ietf.org>, >>>>> mpls-chairs <mpls-cha...@ietf.org>, Tony Li <tony...@tony.li>, >>>>> auth48archive@rfc-ed <auth48archive@rfc-editor.org>, RFC Editor >>>>> <rfc-edi...@rfc-editor.org> >>>>> Subject: AD - Re: AUTH48: RFC-to-be 9714 >>>>> <draft-ietf-mpls-inband-pm-encapsulation-18> for your review >>>>> >>>>> Jim, >>>>> As AD, please review and let us know if you approve the change in Section >>>>> 1 detailed below. >>>>> >>>>> Thank you. >>>>> RFC Editor/ar >>>>> >>>>> On Feb 6, 2025, at 10:16 AM, Alice Russo <aru...@staff.rfc-editor.org> >>>>> wrote: >>>>> >>>>>> Xiao Min, >>>>>> >>>>>> Thank you for your reply. Please review whether the NEW text (based on >>>>>> your reply) is accurate. To view it in context, please see the files >>>>>> listed below. >>>>>> >>>>>> ORIGINAL (the approved I-D): >>>>>> Note that in parallel to the work of this document, there is ongoing >>>>>> work on MPLS Network Actions (MNA) [RFC9613]. The MPLS performance >>>>>> measurement with the Alternate-Marking method can also be achieved by >>>>>> MNA encapsulation. In addition, MNA will provide a broader use case >>>>>> applicability. That means the MNA encapsulation is expected to >>>>>> provide a more advanced solution, when published as an RFC and it is >>>>>> agreed that this document will be made Historic at that time. >>>>>> >>>>>> NEW: >>>>>> Note that in parallel to the work of this document, there is ongoing >>>>>> work, e.g., [MNA-PM-with-AMM], regarding MPLS Network Actions (MNAs) >>>>>> [RFC9613]. The MPLS performance measurement with the Alternate- >>>>>> Marking Method can also be achieved by MNA encapsulation. In >>>>>> addition, MNA will provide a broader use-case applicability. That >>>>>> means the MNA encapsulation is expected to provide a more advanced >>>>>> solution. If [MNA-PM-with-AMM] is published as an RFC, the status of >>>>>> this RFC will be reviewed and possibly changed to Historic. >>>>>> >>>>>> Added informative reference >>>>>> >>>>>> [MNA-PM-with-AMM] >>>>>> Cheng, W., Min, X., Gandhi, R., and G. Mirsky, "MNA for >>>>>> Performance Measurement with Alternate Marking Method", >>>>>> Work in Progress, Internet-Draft, draft-cx-mpls-mna- >>>>>> inband-pm-05, 21 October 2024, >>>>>> <https://datatracker.ietf.org/doc/html/draft-cx-mpls-mna- >>>>>> inband-pm-05>. >>>>>> >>>>>> Files available: >>>>>> https://www.rfc-editor.org/authors/rfc9714.txt >>>>>> https://www.rfc-editor.org/authors/rfc9714.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9714.html >>>>>> https://www.rfc-editor.org/authors/rfc9714.xml >>>>>> https://www.rfc-editor.org/authors/rfc9714-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9714-rfcdiff.html (side by side) >>>>>> >>>>>> Diff of only the most recent changes: >>>>>> https://www.rfc-editor.org/authors/rfc9714-lastdiff.html >>>>>> https://www.rfc-editor.org/authors/rfc9714-lastrfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> Thank you. >>>>>> RFC Editor/ar >>>>>> >>>>>>> On Feb 6, 2025, at 12:02 AM, xiao.m...@zte.com.cn wrote: >>>>>>> >>>>>>> Hi Alice, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thank you for the questions. >>>>>>> >>>>>>> Please see inline. >>>>>>> >>>>>>> Original >>>>>>> From: AliceRusso <aru...@staff.rfc-editor.org> >>>>>>> To: 程伟强 >>>>>>> <chengweiqi...@chinamobile.com>;肖敏10093570;zhoutian...@huawei.com >>>>>>> <zhoutian...@huawei.com>;戴锦友 <d...@fiberhome.com>;yoav.peleg >>>>>>> <yoav.pe...@broadcom.com>; >>>>>>> Cc: mpls-ads <mpls-...@ietf.org>;mpls-chairs >>>>>>> <mpls-cha...@ietf.org>;Tony Li <tony...@tony.li>;james.n.guichard >>>>>>> <james.n.guich...@futurewei.com>;auth48archive@rfc-editor.org >>>>>>> <auth48archive@rfc-editor.org>;RFC Editor <rfc-edi...@rfc-editor.org>; >>>>>>> Date: 2025年02月06日 11:13 >>>>>>> Subject: question - Re: AUTH48: RFC-to-be 9714 >>>>>>> <draft-ietf-mpls-inband-pm-encapsulation-18> for your review >>>>>>> Authors, >>>>>>> >>>>>>> As we prepare your document [1] for publication, we have additional >>>>>>> questions regarding this text. >>>>>>> >>>>>>> Section 1: >>>>>>> Note that in parallel to the work of this document, there is ongoing >>>>>>> work on MPLS Network Actions (MNAs) [RFC9613]. The MPLS performance >>>>>>> measurement with the Alternate-Marking Method can also be achieved by >>>>>>> MNA encapsulation. In addition, MNA will provide a broader use-case >>>>>>> applicability. That means the MNA encapsulation is expected to >>>>>>> provide a more advanced solution. Once published as an RFC, it is >>>>>>> agreed that this document will be made Historic. >>>>>>> >>>>>>> Please clarify this paragraph, specifically: >>>>>>> >>>>>>> a) Does "ongoing work" refer to draft-ietf-mpls-mna-fwk [2] or RFC >>>>>>> 9613? The latter seems odd to refer to as "ongoing work". We note that >>>>>>> until version 17 [3], this sentence cited draft-ietf-mpls-mna-fwk >>>>>>> rather than RFC 9613 (which was draft-ietf-mpls-mna-requirements): >>>>>>> >>>>>>> Note that in parallel to the work of this document, there is ongoing >>>>>>> work on MPLS Network Actions (MNA) [I-D.ietf-mpls-mna-fwk]. >>>>>>> [XM]>>> No. The "ongoing work" refers to MNA encapsulation for MPLS PM >>>>>>> with AMM (e.g., draft-cx-mpls-mna-inband-pm) , neither >>>>>>> draft-ietf-mpls-mna-fwk nor RFC 9613. Here the reference to RFC 9613 or >>>>>>> draft-ietf-mpls-mna-fwk is used to clarify what's MNA. >>>>>>> >>>>>>> >>>>>>> >>>>>>> b) Does "Once published as an RFC" refer to the "ongoing work"? >>>>>>> Depending on your answer above, perhaps "Once [MNA-FRAMEWORK] is >>>>>>> published as an RFC". >>>>>>> [XM]>>> Yes. However, as I said above, the "ongoing work" is neither >>>>>>> [MNA-FRAMEWORK] nor [MNA-REQUIREMENTS]. >>>>>>> >>>>>>> >>>>>>> >>>>>>> c) Regarding "this document will be made Historic", is it accurate that >>>>>>> you are assuming there will be a Status Change for the present document >>>>>>> (RFC 9714)? If so, then perhaps it's more clear to say "the status of >>>>>>> this RFC will be reviewed and possibly changed to Historic"? >>>>>>> [XM]>>> Yes. I agree the new text you wrote is more clear. >>>>>>> >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Xiao Min >>>>>>> >>>>>>> >>>>>>> >>>>>>> [1] https://www.rfc-editor.org/authors/rfc9714.txt [and html and pdf] >>>>>>> [2] https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-fwk/ >>>>>>> (in the RFC Editor queue in EDIT state) >>>>>>> [3] >>>>>>> https://www.ietf.org/archive/id/draft-ietf-mpls-inband-pm-encapsulation-17...txt >>>>>>> >>>>>>> Thank you. >>>>>>> RFC Editor/ar >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
