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
