Hi Alanna, Thank you for the updates; they look good to me. On the other questions, I agree with the proposed changes if my co-authors raise no concerns.
Thanks, Bo -----Original Message----- From: Alanna Paloma <[email protected]> Sent: Wednesday, August 27, 2025 12:41 AM To: Wubo (lana) <[email protected]> Cc: mohamed.boucadair <[email protected]>; [email protected]; OSCAR GONZALEZ DE DIOS <[email protected]>; [email protected]; RFC Editor <[email protected]>; Mahesh Jethanandani <[email protected]>; [email protected]; opsawg-chairs <[email protected]>; [email protected]; auth48archive <[email protected]> Subject: Re: AUTH48: RFC-to-be 9835 <draft-ietf-opsawg-ntw-attachment-circuit-16> for your review 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/rfc9835.xml https://www.rfc-editor.org/authors/rfc9835.txt https://www.rfc-editor.org/authors/rfc9835.html https://www.rfc-editor.org/authors/rfc9835.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9835-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9835-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9835-auth48rfcdiff.html (AUTH48 changes side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9835 Thank you, Alanna Paloma RFC Production Center > On Aug 26, 2025, at 5:11 AM, Wubo (lana) <[email protected]> wrote: > > Hi Alanna, > > I have a particular suggestion on #6, “Network Slice Service vs. Network > Slice”, and I recommend adopting “RFC 9543 Network Slice Service(s)” > throughout this document as per RFC 9543, whenever the term “Network Slice > Service” is used, we should use “RFC 9543 Network Slice Service.” > > Thanks, > Bo > > -----Original Message----- > From: Alanna Paloma <[email protected]> > Sent: Friday, August 22, 2025 12:32 AM > To: mohamed.boucadair <[email protected]>; > [email protected]; OSCAR GONZALEZ DE DIOS > <[email protected]>; > [email protected]; Wubo (lana) <[email protected]> > Cc: RFC Editor <[email protected]>; Mahesh Jethanandani > <[email protected]>; [email protected]; opsawg-chairs > <[email protected]>; [email protected]; auth48archive > <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9835 > <draft-ietf-opsawg-ntw-attachment-circuit-16> 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/rfc9835 > > 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/rfc9835 >> >> Alanna Paloma >> RFC Production Center >> >> >>> On Aug 14, 2025, at 11:21 AM, Mahesh Jethanandani <[email protected]> >>> wrote: >>> >>> Hi Allana, >>> >>> The changes look good to me. Thanks. >>> >>>> On Aug 14, 2025, at 9:36 AM, Alanna Paloma <[email protected]> >>>> wrote: >>>> >>>> Hi Mahesh, >>>> >>>> Thank you for your reply. We’ve updated the Security Considerations >>>> section accordingly. >>>> >>>> The files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9835.xml >>>> https://www.rfc-editor.org/authors/rfc9835.txt >>>> https://www.rfc-editor.org/authors/rfc9835.html >>>> https://www.rfc-editor.org/authors/rfc9835.pdf >>>> >>>> The relevant diff files have been posted here: >>>> https://www.rfc-editor.org/authors/rfc9835-diff.html (comprehensive >>>> diff) https://www.rfc-editor.org/authors/rfc9835-auth48diff.html >>>> (AUTH48 changes) >>>> https://www.rfc-editor.org/authors/rfc9835-auth48rfcdiff.html >>>> (AUTH48 changes side by side) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9835 >>>> >>>> Thank you, >>>> RFC Editor/ap >>>> >>>>> On Aug 13, 2025, at 4:36 PM, Mahesh Jethanandani >>>>> <[email protected]> wrote: >>>>> >>>>> Hi, >>>>> >>>>>> On Aug 11, 2025, at 10:50 PM, [email protected] wrote: >>>>>> >>>>>> Authors, AD, >>>>>> >>>>>> * Mahesh (as AD), please reply to #4. >>>>>> >>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>> necessary) the following questions, which are also in the XML file. >>>>>> >>>>>> 1) <!--[rfced] We note that Figure 4 uses "CE#1" and "CE#2", >>>>>> while other figures in the document use "CE1" and "CE2". May we >>>>>> update the CEs in Figure 4 to match the other figures in the document? >>>>>> >>>>>> If so, both artworks (svg and ascii-art) will be updated accordingly. >>>>>> --> >>>>>> >>>>>> >>>>>> 2) <!--[rfced] To improve readability, may we update "to" to "for"? >>>>>> >>>>>> Original: >>>>>> 'bw-per-site': The bandwidth is to all peer SAPs that belong to >>>>>> the same site. >>>>>> >>>>>> Perhaps: >>>>>> 'bw-per-site': The bandwidth is for all peer SAPs that belong to >>>>>> the same site. >>>>>> --> >>>>>> >>>>>> >>>>>> 3) <!--[rfced] FYI, this YANG module has been updated per the >>>>>> formatting option of pyang. Please let us know any concerns. >>>>>> --> >>>>>> >>>>>> >>>>>> 4) <!--[rfced] *AD - We note that there is some text in the >>>>>> Security Considerations section 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. >>>>>> >>>>>> For example: >>>>>> - This sentence is not present; should it be added? >>>>>> "There are no particularly sensitive RPC or action operations." >>>>>> If so, should it be at the end of the section? >>>>>> (Your reply to this question will also be applied to RFC 9836.) >>>>> >>>>> Yes, please add the statement to the end of the section. >>>>> >>>>>> >>>>>> From the guidelines page: >>>>>> "If the data model contains any particularly sensitive RPC or >>>>>> action operations, then those operations must be listed here, >>>>>> along with an explanation of the associated specific sensitivity >>>>>> or vulnerability concerns. Otherwise, state: 'There are no >>>>>> particularly sensitive RPC or action operations.'" >>>>>> >>>>>> - The last two paragraphs (after the readable nodes section) do >>>>>> not seem to be within a section of the template. >>>>>> —> >>>>>> >>>>> >>>>> Please do something similar to what I recommended on the other document. >>>>> Let us move the two paragraphs to the beginning of the Security >>>>> Considerations section, and before the line “This section is modeled >>>>> after ….”. That statement should be further modified as follows: >>>>> >>>>> OLD: >>>>> This section is modeled after the template described in Section 3.7 of >>>>> [YANG-GUIDELINES]. >>>>> >>>>> NEW: >>>>> The remaining section is modeled after the template described in Section >>>>> 3.7.1 of [YANG-GUIDELINES]. >>>>> >>>>> Thanks. >>>>> >>>>>> >>>>>> 5) <!-- [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. >>>>>> --> >>>>>> >>>>>> >>>>>> 6) <!-- [rfced] Throughout the text, the following terminology >>>>>> appears to be used inconsistently. Please review these >>>>>> occurrences and let us know if/how they may be made consistent. >>>>>> >>>>>> Hold Time vs. holdtime >>>>>> Network Slice Service vs. Network Slice >>>>>> --> >>>>>> >>>>>> >>>>>> 7) <!--[rfced] Abbreviations >>>>>> >>>>>> a) 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 for consistency? >>>>>> >>>>>> attachment circuit (AC) >>>>>> Customer Edge (CE) >>>>>> Layer 2 VPN (L2VPN) >>>>>> Layer 3 VPN (L3VPN) >>>>>> Provider Edge (PE) >>>>>> Service Attachment Point (SAP) >>>>>> >>>>>> b) 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. >>>>>> >>>>>> Class of Service (CoS) >>>>>> --> >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> Note that our script did not flag any words in particular, but >>>>>> this should still be reviewed as a best practice. >>>>>> --> >>>>>> >>>>>> >>>>>> 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-4Q9l >>>>>> 2 >>>>>> 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/rfc9835.xml >>>>>> https://www.rfc-editor.org/authors/rfc9835.html >>>>>> https://www.rfc-editor.org/authors/rfc9835.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9835.txt >>>>>> >>>>>> Diff file of the text: >>>>>> https://www.rfc-editor.org/authors/rfc9835-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9835-rfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> Diff of the XML: >>>>>> https://www.rfc-editor.org/authors/rfc9835-xmldiff1.html >>>>>> >>>>>> >>>>>> Tracking progress >>>>>> ----------------- >>>>>> >>>>>> The details of the AUTH48 status of your document are here: >>>>>> https://www.rfc-editor.org/auth48/rfc9835 >>>>>> >>>>>> Please let us know if you have any questions. >>>>>> >>>>>> Thank you for your cooperation, >>>>>> >>>>>> RFC Editor >>>>>> >>>>>> -------------------------------------- >>>>>> RFC9835 (draft-ietf-opsawg-ntw-attachment-circuit-16) >>>>>> >>>>>> Title : A Network 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]
