Hi Authors,
This is a friendly reminder that 3 cluster-wide questions have not yet been
addressed:
> 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.
You may track the progress of all documents in this cluster through AUTH48 at:
https://www.rfc-editor.org/auth48/C530
Thank you,
Alanna Paloma
RFC Production Center
> On Aug 21, 2025, at 9:33 AM, Alanna Paloma <[email protected]>
> wrote:
>
> 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]
