Hi Bo,

Thank you for your reply. All of our document-specific questions have now been 
addressed; however, there are still 3 cluster-wide questions that have not yet 
been answered.

We will await responses to those outstanding cluster-wide questions as well as 
approvals from each author prior to moving this document forward in the 
publication process.

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)
https://www.rfc-editor.org/authors/rfc9835-lastdiff.html (last version to this 
one)
https://www.rfc-editor.org/authors/rfc9835-lastrfcdiff.html (rfcdiff between 
last version and this)

Please see the AUTH48 status page for this document here:
https://www.rfc-editor.org/auth48/rfc9835

Thank you,
Alanna Paloma
RFC Production Center

> On Aug 29, 2025, at 12:37 AM, Wubo (lana) <[email protected]> wrote:
> 
> Hi Alanna,
> 
> Thank you for the updates; they look good to me. 
> Please also see my replies in line with [Bo Wu].
> 
> Regards,
> Bo
> 
> -----Original Message-----
> From: Alanna Paloma <[email protected]> 
> Sent: Friday, August 29, 2025 2:18 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. The files have been updated accordingly. Please 
> note that we have some follow-up questions.
> 
> We ask that you review these previously sent questions and explicitly let us 
> know if/what further updates are needed.
> 
>> 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.  
>> -->
> [Bo Wu] I confirm that all “type” attributes are set to the preferred value. 
> Thanks.
> 
> 
>> 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
>> -->
> [Bo Wu] After review, I recommend keeping the terms unchanged. “Hold Time” is 
> the BGP-specific interval, while “holdtime” is the BFD holddown to prevent 
> state flapping; the distinction also aligns with RFC 9182, so I think no 
> edits are needed. 
> 
> Thanks,
> Bo
> 
> ---
> 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)  https://www.rfc-editor.org/authors/rfc9835-lastdiff.html (last 
> version to this one)  
> https://www.rfc-editor.org/authors/rfc9835-lastrfcdiff.html (rfcdiff between 
> last version and this)
> 
> Please review the document carefully as documents do not change once 
> published as RFCs.
> 
> We will await any further changes you may have and approvals from each author 
> prior to moving forward in the publication process.
> 
> Please see the AUTH48 status page for this document here:
> https://www.rfc-editor.org/auth48/rfc9835
> 
> Thank you,
> Alanna Paloma
> RFC Production Center
> 
> 
>> On Aug 26, 2025, at 7:49 PM, Wubo (lana) <[email protected]> wrote:
>> 
>> 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-type
>>>>>>>> s
>>>>>>>> ) 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-4Q9
>>>>>>>> l
>>>>>>>> 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]

Reply via email to