Hi Rebecca, thank you for your help in improving this document. Please find my notes below tagged GIM>>.
Regards, Greg On Wed, May 14, 2025 at 10:09 AM Rebecca VanRheenen < rvanrhee...@staff.rfc-editor.org> wrote: > Hi Greg, > > The AUTH48 announcement and questions were sent yesterday. I’ve pasted the > questions below. > > You can also see the messages in the AUTH48 mail archive: > https://mailarchive.ietf.org/arch/browse/auth48archive/?q=9791. > > Thank you for checking in! > > Best regards, > RFC Editor/rv > > > 1) <!-- [rfced] *AD: We see that consensus is set to "Unknown" > for this document in the datatracker. See > <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>. > > This document was sent to Last Call, so we have used the > consensus Status of This Memo. Please confirm that this is correct. > --> > > > 2) <!-- [rfced] The document title includes two instances of "MPLS". Are > both needed? > > Original: > Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data > > Perhaps: > Use Cases for MPLS Network Action Indicators and Ancillary Data > GIM>> I don't strongly prefer either version, and I can live with any decision other authors will support. > --> > > > 3) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > GIM>> Perhaps Special Purpose Label MPLS data plane > > > 4) <!-- [rfced] We see that "MPLS Ancillary Data" appears in Section 1.1 > ("Terminology"). We see instances of "ancillary data" (no "MPLS") in the > document, but we only see "MPLS Ancillary Data" used in the document > title. Are any updates needed? > GIM>> Perhaps we can note the equivalence between "MPLS Ancillary Data" and "ancillary data" as is done for terms related to a network slice. Might the following update be acceptable (using the proposed text below): OLD TEXT: MPLS Ancillary Data: NEW TEXT: MPLS Ancillary Data (also referred to in this document as "ancillary data"): > > Also, note that we slightly updated the definition list as follows. > > Original: > RFC 9543 Network Slice > is interpreted as defined in [RFC9543]. Furthermore, this > document uses "network slice" interchangeably as a shorter version > of the RFC 9543 Network Slice term. > > The MPLS Ancillary Data is classified as: > * residing within the MPLS label stack and referred to as In- > Stack Data, and > > * residing after the Bottom of Stack (BoS) and referred to as > Post-Stack Data. > > Updated: > RFC 9543 Network Slice: > Interpreted as defined in [RFC9543]. This document > uses "network slice" interchangeably as a shorter version of the > term "RFC 9543 Network Slice". > > MPLS Ancillary Data: > Data that can be classified as: > > * residing within the MPLS label stack (referred to as "in-stack > data"), and > > * residing after the Bottom of Stack (BoS) (referred to as "post- > stack data"). > GIM>> I agree with the proposed update. > --> > > > 5) <!-- [rfced] Would you like for the abbreviations listed in Section 1.2 > ("Abbreviations") to be alphabetized? Or do you prefer the current order? > GIM>> Yes, please alphabetize it; thank you. > --> > > > 6) <!-- [rfced] Please review "Policy as a policy construct". May we > update as > follows (i.e., remove "policy")? > > Original: > Section 5 of > [I-D.ietf-teas-ns-ip-mpls] defines a Network Resource Partition (NRP) > Policy as a policy construct that enables the instantiation of > mechanisms to support one or more network slice services. > > Perhaps: > Section 5 of [NS-IP-MPLS] > defines a Network Resource Partition (NRP) Policy as a > construct that enables the instantiation of mechanisms to support one > or more network slice services. GIM>> I prefer the current form because "NRP Policy" is a term, and "policy construct" emphasizes that it is a rule that governs the instantiation of a network slice. > > --> > > > 7) <!-- [rfced] We believe that "label stack elements" here should be > updated to > "label stack entries", which is used earlier in this document and in RFC > 8595. > Please confirm. Also note that "label stack element" has not been > used in the RFC Series. > > Original: > [RFC8595] describes how Service Function Chaining can be realized in > an MPLS network by emulating the Network Service Header (NSH) > [RFC8300] using only MPLS label stack elements. > GIM>> You are correct. Please update as s/elements/entries/ > --> > > > 8) <!-- [rfced] Please confirm that "FUNC::ARG" is correct here. We ask > because > we see "LOC:FUNCT:ARG" in RFC 8986. > > Original: > MNA can be used to encode > the FUNC::ARGs to support the functional equivalent of FUNC::ARG in > SRv6 as described in [RFC8986]. > GIM>> I believe that FUNC::ARG is correct for SR-MPLS, as it does not require the locator part of SRv6. > --> > > > 9) <!-- [rfced] Would you like to update "bottom of the label stack" here > to > "BoS" or leave as is? > > Original: > In this case, BIER has defined 0b0101 as the > value for the first nibble in the data that immediately appears after > the bottom of the label stack for any BIER-encapsulated packet over > MPLS. > > Perhaps: > In this case, BIER has defined 0b0101 as the > value for the first nibble in the data that immediately appears after > the BoS for any BIER-encapsulated packet over > MPLS. > GIM>> I agree to the proposed update, thank you. > --> > > > 10) <!-- [rfced] Please confirm that the citation is correct here. We ask > because > we do not see the specific wording "non-protocol specifying document" in > RFC-to-be 9789 (ietf-mpls-mna-fwk). > > Also, to improve readability, we upddated "non-protocol specifying > documents" > as follows. Let us know any concerns. > > Original: > Section 7 of "MPLS Network Action (MNA) Framework", > [I-D.ietf-mpls-mna-fwk] outlines security considerations for non- > protocol specifying documents. > > Updated: > Section 7 of the MNA framework [RFC9789] outlines security > considerations for documents that do not specify protocols. > GIM>> AFAICS, the full title of RFC 9789-to-be is MPLS Network Action (MNA) Framework. Perhaps we can omit the full title altogether, making this sentence as follows: NEW TEXT: Section 7 of [RFC9789] outlines security considerations for documents that do not specify protocols. > --> > > > 11) <!-- [rfced] FYI - We lowercased "post-stack data" and "in-stack data" > per > usage in RFC-to-be 9789 (ietf-mpls-mna-fwk). > GIM>> Thank you for your thorough review of both drafts, ensuring consistency of terminology. > --> > > > 12) <!-- [rfced] Abbreviations > > a) This document uses "Ingress to Edge" as the expansion for I2E, but > RFC-to-be 9789 (ietf-mpls-mna-fwk) and other documents in the RFC Series > use "Ingress to Egress". If no objections, we will update this document > accordingly. > > Current: > Ingress to Edge > > Perhaps: > Ingress to Egress > GIM>> Thank you for catching this. Agreed > > > b) FYI - We have added expansions for the following abbreviations > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > expansion in the document carefully to ensure correctness. > > Deterministic Networking (DetNet) > Segment Routing over IPv6 (SRv6) > Segment Routing over MPLS (SR-MPLS) > Service Level Objectives (SLOs) > GIM>> All are correct; thank you > --> > > > 13) <!-- [rfced] Please review the "Inclusive Language" portion of the > online > Style Guide < > https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature > typically > result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > GIM>> I don't find any red flags. > --> > > > Thank you. > > RFC Editor/rv > > > On May 13, 2025, at 9:31 PM, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2025/05/13 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-edi...@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9791.xml > https://www.rfc-editor.org/authors/rfc9791.html > https://www.rfc-editor.org/authors/rfc9791.pdf > https://www.rfc-editor.org/authors/rfc9791.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9791-diff.html > https://www.rfc-editor.org/authors/rfc9791-rfcdiff.html (side by side) > > Alt-diff of the text (allows you to more easily view changes > where text has been deleted or moved): > https://www.rfc-editor.org/authors/rfc9791-alt-diff.html > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9791-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9791 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9791 (draft-ietf-mpls-mna-usecases-15) > > Title : Use Cases for MPLS Network Action Indicators and MPLS > Ancillary Data > Author(s) : T. Saad, K. Makhijani, H. Song, G. Mirsky > WG Chair(s) : Tarek Saad, Tony Li, Adrian Farrel > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > > On May 14, 2025, at 9:25 AM, Greg Mirsky <gregimir...@gmail.com> wrote: > > > > Dear RFC Editor, > > for some reason I didn't receive the note from the RFC Editor. If there > are any questions to the authors, please let me know and I will work on > addressing them. > > > > Regards, > > Greg > > > > On Wed, May 14, 2025 at 4:03 AM James Guichard < > james.n.guich...@futurewei.com> wrote: > > > > > > 1) <!-- [rfced] *AD: We see that consensus is set to "Unknown" > > for this document in the datatracker. See > > < > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-mpls-mna-usecases%2F&data=05%7C02%7Cjames.n.guichard%40futurewei.com%7C7b9c8f9adca54238640508dd92a0d426%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638827941655234908%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1%2FHihWNAtbyi%2FuoeToIOkzsvg0ee0ekc4sImPiWZowQ%3D&reserved=0 > >. > > > > This document was sent to Last Call, so we have used the > > consensus Status of This Memo. Please confirm that this is correct. > > --> > > > > Jim> Confirmed. > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
