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) C-VLAN (RFC 9833) vs. CVLAN (RFC 9834) = Customer VLAN L2NM = Layer 2 Network Model (RFC 9833, RFC 9836) vs. L2VPN Network Model (RFC 9834, RFC 9835) L3NM = Layer 3 Network Model (RFC 9833, RFC 9836) vs. L3VPN Network Model (RFC 9834, RFC 9835) L2SM = Layer 2 Service Model (RFC 9833, RFC 9836) vs. L2VPN Service Model (RFC 9834, RFC 9835) L3SM = Layer 3 Service Model (RFC 9833, RFC 9836) vs. L3VPN Service Model (RFC 9834, RFC 9835) 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
