Hi Bo, Thank you for your reply. We have updated the files accordingly.
Additionally, please note that 7 of our previously sent document-specific questions have not yet been addressed. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9833.xml https://www.rfc-editor.org/authors/rfc9833.txt https://www.rfc-editor.org/authors/rfc9833.html https://www.rfc-editor.org/authors/rfc9833.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9833-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9833-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9833-auth48rfcdiff.html (AUTH48 changes side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9833 Thank you, Alanna Paloma RFC Production Center > On Aug 26, 2025, at 5:14 AM, Wubo (lana) <[email protected]> wrote: > > Hi Alanna, > > As with the other AC drafts, I recommend this document align its use of > “Network Slice Service” with RFC 9543, as shown below: > > OLD: > (e.g., Network Slice Service [YANG-NSS])) > > NEW: > (e.g., RFC 9543 Network Slice Service [NSSM])) > > Thanks, > Bo > > -----Original Message----- > From: Alanna Paloma <[email protected]> > Sent: Friday, August 22, 2025 12:31 AM > To: mohamed.boucadair <[email protected]>; [email protected]; > OSCAR GONZALEZ DE DIOS <[email protected]>; > [email protected]; Wubo (lana) <[email protected]> > Cc: Mahesh Jethanandani <[email protected]>; RFC Editor > <[email protected]>; [email protected]; opsawg-chairs > <[email protected]>; [email protected]; auth48archive > <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9833 <draft-ietf-opsawg-teas-common-ac-15> for > your review > > Authors, > > This is a friendly reminder that we await your response to our previously > sent questions. > > We will wait to hear from you before continuing with the publication process. > > The AUTH48 status page for this document is located here: > https://www.rfc-editor.org/auth48/rfc9833 > > Thank you, > Alanna Paloma > RFC Production Center > >> On Aug 14, 2025, at 11:46 AM, Alanna Paloma <[email protected]> >> wrote: >> >> Hi Mahesh, >> >> Thank you for confirming. We’ve noted your approval: >> https://www.rfc-editor.org/auth48/rfc9833 >> >> Alanna Paloma >> RFC Production Center >> >>> On Aug 14, 2025, at 11:22 AM, Mahesh Jethanandani <[email protected]> >>> wrote: >>> >>> Hi Alanna, >>> >>> The changes look good to me. Thanks. >>> >>>> On Aug 14, 2025, at 9:35 AM, Alanna Paloma <[email protected]> >>>> wrote: >>>> >>>> Hi Mahesh, >>>> >>>> Thank you for your reply. We have removed the first sentence of the >>>> Security Considerations section as well as the informative reference entry >>>> for [YANG-GUIDELINES]. >>>> >>>> The files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9833.xml >>>> https://www.rfc-editor.org/authors/rfc9833.txt >>>> https://www.rfc-editor.org/authors/rfc9833.html >>>> https://www.rfc-editor.org/authors/rfc9833.pdf >>>> >>>> The relevant diff files have been posted here: >>>> https://www.rfc-editor.org/authors/rfc9833-diff.html (comprehensive >>>> diff) https://www.rfc-editor.org/authors/rfc9833-auth48diff.html >>>> (AUTH48 changes) >>>> https://www.rfc-editor.org/authors/rfc9833-auth48rfcdiff.html >>>> (AUTH48 changes side by side) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9833 >>>> >>>> Thank you, >>>> RFC Editor/ap >>>> >>>> >>>>> On Aug 13, 2025, at 4:48 PM, Mahesh Jethanandani >>>>> <[email protected]> wrote: >>>>> >>>>> Hi, >>>>> >>>>>> On Aug 11, 2025, at 10:46 PM, [email protected] wrote: >>>>>> >>>>>> Authors, AD, >>>>>> >>>>>> * Mahesh (as AD), please reply to #5. >>>>>> >>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>> necessary) the following questions, which are also in the XML file. >>>>>> >>>>>> 1) <!--[rfced] To avoid back-to-back use of "For example", may we >>>>>> update the second occurrence as follows? >>>>>> >>>>>> Original: >>>>>> For example, a >>>>>> server can be a network controller or a router in a provider >>>>>> network. >>>>>> >>>>>> For example, a bearer request is first created using a name which >>>>>> is assigned by the client, but if this feature is supported, the >>>>>> request will also include a server-generated reference. >>>>>> >>>>>> Perhaps: >>>>>> For example, a >>>>>> server can be a network controller or a router in a provider >>>>>> network. >>>>>> >>>>>> As another example, a bearer request is first created using a name >>>>>> that is assigned by the client, but if this feature is supported, >>>>>> the request will also include a server-generated reference. >>>>>> --> >>>>>> >>>>>> >>>>>> 2) <!--[rfced] To improve readability, may we update "to" to "for"? >>>>>> >>>>>> Original: >>>>>> * 'bw-per-site': The bandwidth is to all ACs that belong to the >>>>>> same site. >>>>>> >>>>>> Perhaps: >>>>>> 'bw-per-site': The bandwidth is for all ACs that belong to the >>>>>> same site. >>>>>> --> >>>>>> >>>>>> >>>>>> 3) <!-- [rfced] We note that the following reference is cited only >>>>>> in the YANG module. In order to have a 1:1 matchup between the >>>>>> references section and the text, may we add the following >>>>>> reference entry to the Normative References and add it to the list >>>>>> of citations preceding the YANG module? >>>>>> >>>>>> Original: >>>>>> This module uses types defined in [RFC6991], [RFC8177], and >>>>>> [RFC9181]. >>>>>> >>>>>> Perhaps: >>>>>> This module uses types defined in [RFC6991], [RFC8177], [RFC9181], >>>>>> and [IEEE_802.1Q]. >>>>>> ... >>>>>> [IEEE_802.1Q] >>>>>> IEEE, "IEEE Standard for Local and Metropolitan Area >>>>>> Networks-Bridges and Bridged Networks", IEEE Std 802.1Q- >>>>>> 2022, DOI 10.1109/IEEESTD.2022.10004498, December 2022, >>>>>> <https://doi.org/10.1109/IEEESTD.2022.10004498>. >>>>>> --> >>>>>> >>>>>> >>>>>> 4) <!--[rfced] FYI, the YANG module has been updated per the >>>>>> formatting option of pyang. Please let us know any concerns. >>>>>> --> >>>>>> >>>>>> >>>>>> 5) <!--[rfced] *AD - We note that there is some text in the >>>>>> Security Considerations that differs from the template on >>>>>> <https://wiki.ietf.org/group/ops/yang-security-guidelines>. Please >>>>>> review and let us know if the text is acceptable. Specifically: >>>>>> >>>>>> - Paragraph 5 matches the template except for the last sentence is >>>>>> an addition. Paragraph 6 does not seem to correspond to the template. >>>>>> >>>>>> - This sentence is not present, although the template says to include >>>>>> it. >>>>>> "There are no particularly sensitive RPC or action operations." >>>>>> >>>>>> If it should be added, should it be at the end of the section? >>>>>> --> >>>>> >>>>> The security considerations in this draft are truly unique. As such, the >>>>> template mostly does not apply. >>>>> >>>>> Please remove the first sentence in the Security Considerations section >>>>> that goes like “This section is modeled after the template …”. Only the >>>>> second and third paragraphs do, and even then, it is just a >>>>> cut-and-paste. Best to remove it. >>>>> >>>>> Thanks. >>>>> >>>>>> >>>>>> >>>>>> 6) <!-- [rfced] Please review the "type" attribute of each >>>>>> sourcecode element in the XML file to ensure correctness. If the >>>>>> current list of preferred values for "type" >>>>>> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) >>>>>> does not contain an applicable type, then feel free to let us know. >>>>>> Also, it is acceptable to leave the "type" attribute not set. >>>>>> --> >>>>>> >>>>>> >>>>>> 7) <!--[rfced] Abbreviation >>>>>> >>>>>> a) FYI - We have added expansions for the following abbreviation >>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review >>>>>> each expansion in the document carefully to ensure correctness. >>>>>> >>>>>> Operations, Administration, and Maintenance (OAM) >>>>>> >>>>>> >>>>>> b) Both the expansion and the acronym for the following terms are >>>>>> used throughout the document. Would you like to update to using >>>>>> the expansion upon first usage and the acronym for the rest of the >>>>>> document? >>>>>> >>>>>> Attachment Circuit (AC) >>>>>> Service Function (SF) >>>>>> --> >>>>>> >>>>>> >>>>>> 8) <!-- [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. >>>>>> >>>>>> For example, please consider whether the following should be updated: >>>>>> black-hole >>>>>> --> >>>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> RFC Editor/ap/ar >>>>>> >>>>>> >>>>>> On Aug 11, 2025, [email protected] wrote: >>>>>> >>>>>> *****IMPORTANT***** >>>>>> >>>>>> Updated 2025/08/11 >>>>>> >>>>>> 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 >>>>>> >>>>>> * [email protected] (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). >>>>>> >>>>>> * [email protected], 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-4Q9l2 >>>>>> USxIAe6P8O4Zc >>>>>> >>>>>> * 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, >>>>>> [email protected] 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/rfc9833.xml >>>>>> https://www.rfc-editor.org/authors/rfc9833.html >>>>>> https://www.rfc-editor.org/authors/rfc9833.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9833.txt >>>>>> >>>>>> Diff file of the text: >>>>>> https://www.rfc-editor.org/authors/rfc9833-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9833-rfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> Diff of the XML: >>>>>> https://www.rfc-editor.org/authors/rfc9833-xmldiff1.html >>>>>> >>>>>> >>>>>> Tracking progress >>>>>> ----------------- >>>>>> >>>>>> The details of the AUTH48 status of your document are here: >>>>>> https://www.rfc-editor.org/auth48/rfc9833 >>>>>> >>>>>> Please let us know if you have any questions. >>>>>> >>>>>> Thank you for your cooperation, >>>>>> >>>>>> RFC Editor >>>>>> >>>>>> -------------------------------------- >>>>>> RFC9833 (draft-ietf-opsawg-teas-common-ac-15) >>>>>> >>>>>> Title : A Common YANG Data Model for Attachment Circuits >>>>>> Author(s) : M. Boucadair, R. Roberts, O. Gonzalez de Dios, S. >>>>>> Barguil Giraldo, B. Wu >>>>>> WG Chair(s) : Joe Clarke, Benoît Claise >>>>>> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani >>>>>> >>>>>> >>>>> >>>>> >>>>> Mahesh Jethanandani >>>>> [email protected] >>>> >>>> >>> >>> >>> Mahesh Jethanandani >>> [email protected] >>> >>> >>> >>> >>> >>> >> > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
