Hi Bo, 

1) Regarding authors' names in the YANG modules:

a) Samier's last name is "Barguil Giraldo" in the header and Authors'
Addresses section of the cluster documents, but the YANG modules list it as 
"Barguil". We also note that it is "Barguil" in previously published RFCs.
Which form is preferred?

>>> Can you please keep it as Samier Barguil.

Thanks 

Regards,

Samier Barguil

-----Original Message-----
From: Wubo (lana) <lana.w...@huawei.com> 
Sent: Tuesday, August 12, 2025 11:21 AM
To: rfc-edi...@rfc-editor.org; mohamed.boucad...@orange.com; 
rrobe...@juniper.net; oscar.gonzalezded...@telefonica.com; Samier Barguil 
Giraldo (Nokia) <samier.barguil_gira...@nokia.com>
Cc: opsawg-...@ietf.org; opsawg-cha...@ietf.org; rro...@ciena.com; 
mjethanand...@gmail.com; auth48archive@rfc-editor.org
Subject: RE: [C530] AUTH48 questions: RFCs-to-be 9833-9836

Hi,

For the abbreviations, please see my reply below. I'm good with the other 
suggestions.

Thanks,
Bo

-----Original Message-----
From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>
Sent: Tuesday, August 12, 2025 1:56 PM
To: mohamed.boucad...@orange.com; rrobe...@juniper.net; 
oscar.gonzalezded...@telefonica.com; samier.barguil_gira...@nokia.com; Wubo 
(lana) <lana.w...@huawei.com>
Cc: rfc-edi...@rfc-editor.org; opsawg-...@ietf.org; opsawg-cha...@ietf.org; 
rro...@ciena.com; mjethanand...@gmail.com; auth48archive@rfc-editor.org
Subject: [C530] AUTH48 questions: RFCs-to-be 9833-9836

Authors,

While reviewing this cluster of documents*, please reply to the questions below 
regarding consistency across the cluster. These questions are in addition to 
the document-specific questions sent for each RFC-to-be. Your reply will likely 
impact two or more of the documents in the cluster, so please discuss off-list 
as necessary, and then let us know how to proceed. Note - You have the option 
of updating the edited XML files yourself, if you prefer.  We will wait to hear 
from you before continuing with the publication process.

* Cluster 530 (C530) currently in AUTH48 state:
   https://www.rfc-editor.org/authors/rfc9833.html 
   https://www.rfc-editor.org/authors/rfc9834.html 
   https://www.rfc-editor.org/authors/rfc9835.html
   https://www.rfc-editor.org/authors/rfc9836.html
(In addition, the .pdf, .txt, .xml, and diff files are available.)

You may track the progress of all documents in this cluster through AUTH48 at:
  https://www.rfc-editor.org/auth48/C530

1) Regarding authors' names in the YANG modules:

a) Samier's last name is "Barguil Giraldo" in the header and Authors'
Addresses section of the cluster documents, but the YANG modules list it as 
"Barguil". We also note that it is "Barguil" in previously published RFCs.
Which form is preferred?

b) Richard Roberts is listed as an Author in the YANG modules in RFC 9833 and 
RFC 9834, but he has an editor role in the cluster documents. Should his title 
be updated to "Editor" in the YANG module, like Mohamed Boucadair?


2) The following abbreviations are used inconsistently across the cluster.
Please review and let us know which version is preferred for consistency.

  ASN = Autonomous System Number (RFC 9833, RFC 9834), AS Number (RFC 9835) [Bo 
Wu] After reviewing RFC 9835, I suggest we go with "ASN = Autonomous System 
Number".

  C-VLAN (RFC 9833) vs. CVLAN (RFC 9834) = Customer VLAN [Bo Wu] To align with 
the published RFC 9181, C-VLAN is my choice.

  L2NM = Layer 2 Network Model (RFC 9833, RFC 9836) 
     vs. L2VPN Network Model   (RFC 9834, RFC 9835)
[Bo Wu] L2VPN Network Model (L2NM) is consistent with RFC9291.

  L3NM = Layer 3 Network Model (RFC 9833, RFC 9836)
     vs. L3VPN Network Model   (RFC 9834, RFC 9835)
[Bo Wu] L3VPN Network Model (L3NM) is consistent with RFC9182.

  L2SM = Layer 2 Service Model (RFC 9833, RFC 9836) 
     vs. L2VPN Service Model   (RFC 9834, RFC 9835)
[Bo Wu] Per RFC8466, L2VPN Service Model for consistency.

  L3SM = Layer 3 Service Model (RFC 9833, RFC 9836) 
     vs. L3VPN Service Model   (RFC 9834, RFC 9835)
[Bo Wu] Same as above. Let's stick with L3VPN Service Model.


3) Regarding the diagram (that appears in each document) to show the import 
relationships for the YANG modules: Please consider whether the direction of 
the arrow is as you intended. It seems the reverse of the intuitive direction 
of "import". [Best viewed with fixed-width font.]

CURRENT:
                               ietf-ac-common
                                ^     ^     ^
                                |     |     |
                     .----------'     |     '----------.
                     |                |                |
                     |                |                |
               ietf-ac-svc <--- ietf-bearer-svc        |
                  ^    ^                               |
                  |    |                               |
                  |    '------------------------ ietf-ac-ntw
                  |                                    ^
                  |                                    |
                  |                                    |
                  '------------ ietf-ac-glue ----------'

               X --> Y: X imports Y
  
As noted, "the "ietf-ac-common" module is imported by the "ietf-bearer-svc", 
"ietf-ac-svc", and "ietf-ac-ntw" modules", etc.

Seemingly, this would be more intuitive as the arrow "brings in" 
the import.

PERHAPS:  
                               ietf-ac-common
                                |     |     |
                                |     |     |
                     .----------'     |     '----------.
                     |                |                |
                     v                v                |
               ietf-ac-svc ---> ietf-bearer-svc        |
                  |    |                               |
                  |    |                               v
                  |    '-----------------------> ietf-ac-ntw
                  |                                    |
                  |                                    |
                  |                                    |
                  '-----------> ietf-ac-glue <---------'

              X <-- Y: X imports Y


4) RFCs-to-be 9834 and 9835 each have the following sentence. May we clarify 
how the contents of RFC 8177 correspond to the listed data nodes as follows?

Original:                                                                       
                       
   Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-         
                       
   chain') rely upon [RFC8177] for authentication purposes.                     
                       
                                                                                
                       
Perhaps:                                                                        
                       
   Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'customer-key-         
                       
   chain') rely upon the key chains described in [RFC8177] for                  
                       
   authentication purposes.  


Thank you.
RFC Editor/ap/ar

-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org

Reply via email to