Hi Authors,
Thank you for your replies. We have updated the documents per the responses
from Bo and Samier.
Please note that we are still awaiting responses to these cluster-wide queries:
> 1) Regarding authors' names in the YANG modules:
>
> 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?
>
> 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,
Alanna Paloma
RFC Production Center
> On Aug 17, 2025, at 6:38 AM, Samier Barguil Giraldo (Nokia)
> <[email protected]> wrote:
>
> 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) <[email protected]>
> Sent: Tuesday, August 12, 2025 11:21 AM
> To: [email protected]; [email protected];
> [email protected]; [email protected]; Samier Barguil
> Giraldo (Nokia) <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> 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: [email protected] <[email protected]>
> Sent: Tuesday, August 12, 2025 1:56 PM
> To: [email protected]; [email protected];
> [email protected]; [email protected]; Wubo
> (lana) <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> 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 -- [email protected]
To unsubscribe send an email to [email protected]
