Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-ietf-opsawg-l2nm-19> for your review

[Reuben Esparza <[e-mail]>]

Hi Adrian, Rob, and Authors,


Adrian, thank you for the input. Noted.

Rob, thank you for your review. Your approval has been noted on the AUTH48 status page.


Mohamed, we have updated the document per your nits and have added your approval to the AUTH 48 status page.

Luis, we have also added your approval to the AUTH48 status page. 


Once we receive approval from Oscar and Samier, we’ll be able to continue with the publication process for this document.



Please review the document carefully to ensure satisfaction, as we do not make changes once it 
has been published as an RFC.  

Please contact us with any further updates you may have.  We will await approvals from each author 
prior to moving forward in the publication process.

A diff file highlighting only the AUTH48 updates is available at:

https://www.rfc-editor.org/authors/rfc9291-auth48diff.html

The text, XML, and comprehensive diff files are available at:

https://www.rfc-editor.org/authors/rfc9291.txt
https://www.rfc-editor.org/authors/rfc9291.pdf
https://www.rfc-editor.org/authors/rfc9291.html
https://www.rfc-editor.org/authors/rfc9291.xml
https://www.rfc-editor.org/authors/rfc9291-diff.html

Note that it may be necessary for you to refresh your browser to access the most recent version.  

The AUTH48 status page for this document is available here:

https://www.rfc-editor.org/auth48/rfc9291

Thank you.

RFC Editor/re
> On Sep 6, 2022, at 5:43 AM, LUIS ANGEL MUÑOZ, Vodafone <[e-mail]> wrote:
> 
> Hello all
> 
> Assuming these changes are implemented, I also approve the publication of the document.
> 
> Thank you
> Regards
> Luis
> 
> C2 General
> 
> -----Mensaje original-----
> De: [e-mail] <[e-mail]> 
> Enviado el: lunes, 5 de septiembre de 2022 10:39
> Para: Reuben Esparza <[e-mail]>; [e-mail]; [e-mail]; LUIS ANGEL MUÑOZ, Vodafone <[e-mail]>; [e-mail]
> CC: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Asunto: RE: [AD] AUTH48: RFC-to-be 9291 <draft-ietf-opsawg-l2nm-19> for your review
> 
> CYBER SECURITY WARNING: This email is from an external source - be careful of attachments and links. Please follow the Cyber Code and report suspicious emails.
> 
> Hi Reuben, all,
> 
> Thank you for implementing the changes. This looks better but I think we still need to fix some very minor nits in the edited version:
> 
> (1) Section 7.3:
> 
>  OLD: VPWS with support by Ethernet
>  NEW: VPWS EVPNs
> 
> (2) Add an empty line right after the folding note (=============== NOTE: '\' line wrapping per RFC 8792 ================). This change is to be reflected in all the examples with that note.
> 
> (3) Use consistent indent for folded lines, especially in:
> 
> * Figure 24:
> 
> OLD:
>                     "pw-encapsulation-type": "iana-bgp-l2-encaps:\
>                     ethernet-tagged-mode",
> 
> NEW:
>                     "pw-encapsulation-type": "iana-bgp-l2-encaps:\
>                      ethernet-tagged-mode",
> 
> * Figure 30:
> OLD:
> 
>           "ethernet-segment-identifier": "00:11:11:11:11:11:11:\
>   11:11:11",
> 
>           "ethernet-segment-identifier": "00:22:22:22:22:22:22:\
>   22:22:22",
> 
> NEW:
>           "ethernet-segment-identifier": "00:11:11:11:11:11:11:\
>            11:11:11",
> 
>           "ethernet-segment-identifier": "00:22:22:22:22:22:22:\
>            22:22:22",
> 
> * Figure 35:
> OLD:
>             "auto-ethernet-segment-identifier": "01:11:00:11:00:11:\
>   11:9a:00:00"
> 
> NEW:
>             "auto-ethernet-segment-identifier": "01:11:00:11:00:11:\
>              11:9a:00:00"
> 
> 
> Assuming these changes are implemented, I approve the publication of the document.
> 
> Many thanks for all your effort. Much appreciated, as usual.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Reuben Esparza <[e-mail]> Envoyé : samedi 3 septembre 
>> 2022 03:18 À : BOUCADAIR Mohamed INNOV/NET 
>> <[e-mail]>; [e-mail];
>> [e-mail]; luis- 
>> [e-mail]; [e-mail] Cc : 
>> [e-mail]; [e-mail]; opsawg- 
>> [e-mail]; [e-mail]; [e-mail] 
>> Objet : Re: [AD] AUTH48: RFC-to-be 9291 <draft-ietf-opsawg-l2nm-
>> 19> for your review
>> 
>> Hi Authors and *Robert
>> 
>> *Robert, we await your AD response to the AQ below:
>> 
>> <!--[rfced] AD, please review the Security Considerations and let us 
>> know if you approve the variance to the YANG boilerplate as outlined 
>> below or if further changes should be made. Note that paragraph 5 of 
>> the security boilerplate was not included; please confirm that it does 
>> not apply here. The boilerplate is viewable
>> at: 
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac
>> .ietf.org%2Ftrac%2Fops%2Fwiki%2Fyang-security-guidelines&amp;data=05%7
>> C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07
>> eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CU
>> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
>> WwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=hPj3SrNd3JwABSePH4hqb9P5k2
>> %2Bl9r253WBDb3h4kAk%3D&amp;reserved=0
>> 
>> Note that "and delete operations" and "or authentication" was added to 
>> the boilerplate language as follows.
>> 
>> Current:
>>   Write operations (e.g., edit-config) and delete operations
>>   to these data nodes without proper protection or authentication can
>>   have a negative effect on network operations.
>> 
>> FYI - this is the missing text (paragraph 5 of the boilerplate):
>>   Some of the RPC operations in this YANG module may be
>>   considered sensitive or vulnerable in some network environments.
>>   It is thus important to control access to these operations.
>>   These are the operations and their sensitivity/vulnerability:
>> ->
>> 
>> 
>> Mohamed, thank you for your reply.  We have updated our files to
>> reflect these changes and have only the following question
>> remaining:
>> 
>> (Per your comments about the edited version email)
>>> 
>>> (4)
>>> 
>>> OLD:
>>>  'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth':
>> Specifies the
>>>     service bandwidth for the L2VPN service.
>>> 
>>> NEW:
>>>  'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth':
>> Specify the service bandwidth for the L2VPN service.
>> 
>> Assuming "Specify the service bandwidth for the L2VPN service" is
>> meant more of as a command, should the description for "mtu" above
>> it also be updated to "specify"?
>> 
>> Currently:
>>    'mtu':  Specifies the Layer 2 MTU, in bytes, for the VPN
>> network access.
>> 
>> Perhaps:
>>    'mtu':  Specify the Layer 2 MTU, in bytes, for the VPN network
>> access.
>> 
>> 
>> 
>> Once we receive your final review and approval along with that of
>> Oscar, Samier, Luis, and Robert, we'll be able to continue with
>> the publication process for this document.
>> 
>> 
>> Please review the document carefully to ensure satisfaction, as we
>> do not make changes once it has been published as an RFC.
>> 
>> Please contact us with any further updates you may have.  We will
>> await approvals from each author prior to moving forward in the
>> publication process.
>> 
>> A diff file highlighting only the AUTH48 updates is available at:
>> 
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291-auth48diff.html&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=Ops7AS121WHC4xGy87P1J0jun5i%2FuEi6OD0T2ogahHM%3D&amp;reserved=0
>> 
>> The text, XML, and comprehensive diff files are available at:
>> 
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291.txt&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=n2s3g0YKPS8JBZg0pogiUDCc3zWTyDnc18JIr5%2B%2Fzx0%3D&amp;reserved=0
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291.pdf&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=NOIdPShzk8rOinO7ipGbpztlQB03LSTEqPXDNHTYIAo%3D&amp;reserved=0
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291.html&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=xvdrZ9H3uS%2FQ1b5IiV3p0e6Q8S305jL3RxcvAXufKh4%3D&amp;reserved=0
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291.xml&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=MCw%2BrR5oHVe6lpqo43MIEdl%2B2ZUGzaEkFLLWYmH3GFY%3D&amp;reserved=0
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291-diff.html&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=Q29vKWAXx2QARju7XsJklUWLtQhbV6t3W70Xd4jM%2Bqs%3D&amp;reserved=0
>> 
>> Note that it may be necessary for you to refresh your browser to
>> access the most recent version.
>> 
>> The AUTH48 status page for this document is available here:
>> 
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9291&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=pbrl2f9T9eNb%2F0IM%2B%2FeXxWVElPT%2FqJDDtmozP%2BOXvw0%3D&amp;reserved=0
>> 
>> Thank you.
>> 
>> RFC Editor/re
>> 
>> 
>> 
>> 
>>> On Sep 2, 2022, at 4:52 AM, [e-mail] wrote:
>>> 
>>> Dear RFC Editor, all,
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : [e-mail] <[e-mail]>
>> Envoyé :
>>>> jeudi 1 septembre 2022 20:08 À : BOUCADAIR Mohamed INNOV/NET
>>>> <[e-mail]>;
>> [e-mail];
>>>> [e-mail]; luis-
>>>> [e-mail] Cc : [e-mail];
>>>> [e-mail]; opsawg- [e-mail];
>> [e-mail];
>>>> [e-mail]; [e-mail] Objet : [AD]
>> Re:
>>>> AUTH48: RFC-to-be 9291 <draft-ietf-opsawg-l2nm-
>>>> 19> for your review
>>>> 
>>>> Authors and AD*,
>>>> 
>>>> While reviewing this document during AUTH48, please resolve (as
>>>> necessary) the following questions, which are also in the XML
>> file.
>>>> 
>>>> *AD, please review and respond to question #17 below.
>>>> 
>>>> 1) <!--[rfced] We note that most of the recently published RFCs
>>>> containing YANG modules format their titles as "A YANG Data
>> Model
>>>> for...". For example:
>>>> 
>>>>  RFC 9094 - A YANG Data Model for Wavelength Switched Optical
>>>> Networks (WSONs)
>>>>  RFC 9093 - A YANG Data Model for Layer 0 Types
>>>>  RFC 9067 - A YANG Data Model for Routing Policy
>>>> 
>>>> Therefore, we would like to update the title and short title
>> (that
>>>> spans the pdf header) as follows. Please review and let us know
>> if
>>>> this is agreeable or if you prefer otherwise.
>>>> 
>>>> Original Title:
>>>>  A YANG Network Data Model for Layer 2 VPNs
>>>> 
>>> 
>>> [Med] We are actually echoing the same title structure as in
>> RFC9182. I suggest we maintain the original version.
>>> 
>>>> Perhaps:
>>>>  A Network-Centric YANG Data Model for Layer 2 Virtual Private
>>>> Networks (L2VPNs)
>>>> 
>>>> ...
>>>> Original Short Title:
>>>>  L2NM
>>>> 
>>>> Perhaps:
>>>>  A Network YANG Data Model for L2VPNs
>>> 
>>> [Med] OK.
>>> 
>>>> -->
>>>> 
>>>> 
>>>> 2) <!-- [rfced] FYI: We've updated the following terms per
>> guidance
>>>> from Benoit Claise and the YANG Doctors, as "YANG module"
>>>> and "YANG data model" are preferred. Please let us know if any
>>>> further updates are needed.
>>>> 
>>>> Original:
>>>>  "YANG data module" and "YANG model"
>>>> 
>>>> Updated:
>>>>  "YANG module" and "YANG data model"
>>>> -->
>>> 
>>> [Med] ACK.
>>> 
>>>> 
>>>> 
>>>> 3) <!-- [rfced] We note that "Luis Angel Munoz" does not appear
>> as an
>>>> author in the non-IANA YANG modules. Please let us know if his
>>>> contact information should be included.
>>>> -->
>>> 
>>> [Med] No change is needed. Thanks.
>>> 
>>>> 
>>>> 
>>>> 4) <!-- [rfced] Several lines in this document are slightly
>> longer
>>>> than the allowed 72-character maximum. Please let us know how
>> these
>>>> may be shortened.
>>>> 
>>>> 1.
>>>> 1 char too long:
>>>> |  |     |  |     +- -rw dscp?   inet:dscp
>>>> |  |     |  |     +- -rw dot1q?     uint16
>>> 
>>> [Med] what about?
>>> 
>>> OLD:
>>>                            +--rw service
>>>                               ...
>>>                               +--rw qos {vpn-common:qos}?
>>>                               |  +--rw qos-classification-
>> policy
>>>                               |  |  +--rw rule* [id]
>>>                               |  |     +--rw id
>> string
>>>                               |  |     +--rw (match-type)?
>>>                               |  |     |  +--:(match-flow)
>>>                               |  |     |  |  +--rw match-flow
>>>                               |  |     |  |     +--rw dscp?
>> inet:dscp
>>>                               |  |     |  |     +--rw dot1q?
>> uint16
>>>                               |  |     |  |     +--rw pcp?
>> uint8
>>>                               |  |     |  |     +--rw src-mac-
>> address?
>>>                               |  |     |  |     |
>> yang:mac-address
>>>                               |  |     |  |     +--rw dst-mac-
>> address?
>>>                               |  |     |  |     |
>> yang:mac-address
>>>                               |  |     |  |     +--rw color-
>> type?
>>>                               |  |     |  |     |
>> identityref
>>>                               |  |     |  |     +--rw any?
>> empty
>>>                               |  |     |  +--:(match-
>> application)
>>>                               |  |     |     +--rw match-
>> application?
>>>                               |  |     |
>> identityref
>>>                               |  |     +--rw target-class-id?
>> string
>>>                               |  +--rw qos-profile
>>>                               |     +--rw qos-profile*
>> [profile]
>>>                               |        +--rw profile
>> leafref
>>>                               |        +--rw direction?
>> identityref
>>>                               ...
>>> 
>>>                           Figure 20: QoS Subtree
>>> 
>>> NEW:
>>>                          +--rw service
>>>                             ...
>>>                             +--rw qos {vpn-common:qos}?
>>>                             |  +--rw qos-classification-policy
>>>                             |  |  +--rw rule* [id]
>>>                             |  |     +--rw id
>> string
>>>                             |  |     +--rw (match-type)?
>>>                             |  |     |  +--:(match-flow)
>>>                             |  |     |  |  +--rw match-flow
>>>                             |  |     |  |     +--rw dscp?
>> inet:dscp
>>>                             |  |     |  |     +--rw dot1q?
>> uint16
>>>                             |  |     |  |     +--rw pcp?
>> uint8
>>>                             |  |     |  |     +--rw src-mac-
>> address?
>>>                             |  |     |  |     |       yang:mac-
>> address
>>>                             |  |     |  |     +--rw dst-mac-
>> address?
>>>                             |  |     |  |     |       yang:mac-
>> address
>>>                             |  |     |  |     +--rw color-type?
>>>                             |  |     |  |     |
>> identityref
>>>                             |  |     |  |     +--rw any?
>> empty
>>>                             |  |     |  +--:(match-application)
>>>                             |  |     |     +--rw match-
>> application?
>>>                             |  |     |             identityref
>>>                             |  |     +--rw target-class-id?
>> string
>>>                             |  +--rw qos-profile
>>>                             |     +--rw qos-profile* [profile]
>>>                             |        +--rw profile      leafref
>>>                             |        +--rw direction?
>> identityref
>>>                             ...
>>> 
>>>                           Figure 20: QoS Subtree
>>> 
>>>> +- -rw broadcast-unknown-unicast-multicast
>>> 
>>> [Med] What about:
>>> 
>>> OLD:
>>>                            +--rw service
>>>                               ...
>>>                               +--rw broadcast-unknown-unicast-
>> multicast
>>>                                  +--rw multicast-site-type?
>>>                                  |       enumeration
>>>                                  +--rw multicast-gp-address-
>> mapping* [id]
>>>                                  |  +--rw id
>> uint16
>>>                                  |  +--rw vlan-id
>> uint32
>>>                                  |  +--rw mac-gp-address
>>>                                  |  |       yang:mac-address
>>>                                  |  +--rw port-lag-number?
>> uint32
>>>                                  +--rw bum-overall-rate?
>> uint64
>>> 
>>>                           Figure 22: BUM Subtree
>>> 
>>> NEW:
>>>                         +--rw service
>>>                            ...
>>>                            +--rw broadcast-unknown-unicast-
>> multicast
>>>                               +--rw multicast-site-type?
>>>                               |       enumeration
>>>                               +--rw multicast-gp-address-
>> mapping* [id]
>>>                               |  +--rw id
>> uint16
>>>                               |  +--rw vlan-id
>> uint32
>>>                               |  +--rw mac-gp-address
>>>                               |  |       yang:mac-address
>>>                               |  +--rw port-lag-number?
>> uint32
>>>                               +--rw bum-overall-rate?
>> uint64
>>> 
>>>                           Figure 22: BUM Subtree
>>> 
>>>> 
>>>> 2. 2 chars too long:
>>>> |  |     |  |     |       yang:mac-address
>>>> |  |     |  |     |       yang:mac-address
>>>> |  |     |  |     +- -rw any?         empty
>>>> |  |     +- -rw target-class-id?     string
>>> 
>>> [Med] Fixed with the proposed changes above.
>>> 
>>>> |  |  +- -rw name                    string
>>> 
>>> [Med] Please consider:
>>> 
>>> OLD:
>>> |  |  +--rw name                    string
>>> 
>>> NEW:
>>> |  |  +--rw name                  string
>>> 
>>>> |  |  +- -rw protection-type?   identityref
>>> 
>>> [Med] Can be fixed, e.g.:
>>> 
>>> NEW:
>>> |  |  +- -rw protection-type? identityref
>>> 
>>>> "bw-type": "ietf-vpn-common:bw-per-port",
>>>> "bw-type": "ietf-vpn-common:bw-per-port",
>>>> "bw-type": "ietf-vpn-common:bw-per-port",
>>>> "bw-type": "ietf-vpn-common:bw-per-port",
>>>> 
>>> 
>>> [Med] We can consider this modification:
>>> 
>>> NEW:
>>> "bw-type": "ietf-vpn-common:\
>>> bw-per-port",
>>> 
>>>> 
>>>> 3.
>>>> 3 chars too long:
>>>> +- -rw id                        vpn-common:vpn-id
>>> 
>>> [Med] Please delete the extra 3 spaces as follows:
>>> 
>>> NEW:
>>> +--rw id                    vpn-common:vpn-id
>>> 
>>>> +- -rw multicast-gp-address-mapping* [id]
>>> 
>>> [Med] Fixed in the proposed change to Figure 22 above.
>>> 
>>> 
>>>> "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\
>>>> "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\
>>>> "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\
>>>> "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\
>>>> -->
>>>> 
>>> 
>>> [Med] Please use the following:
>>> 
>>> OLD:
>>>                    "pw-encapsulation-type": "iana-bgp-l2-
>> encaps:ethernet\
>>>  -tagged-mode",
>>> 
>>> NEW:
>>>                    "pw-encapsulation-type": "iana-bgp-l2-
>> encaps:\
>>>  ethernet-tagged-mode",
>>> 
>>>> 
>>>> 5) <!--[rfced] Please confirm if "YANG" should be removed from,
>> or
>>>> perhaps included outside of, the expansion of "L2NM" since the
>>>> expansion is normally "L2VPN Network Model (L2NM)".
>>>> 
>>> 
>>> [Med] Yes, please use "L2VPN Network Model" to be consistent
>> with RFC9182.
>>> 
>>>> Original:
>>>>  This document defines an L2VPN Network YANG Model (L2NM)
>> which can
>>>>  be used to manage the provisioning of Layer 2 Virtual Private
>>>>  Network services within a network (e.g., service provider
>> network).
>>>> -->
>>>> 
>>>> 
>>>> 6) <!--[rfced] May we rephrase this sentence for clarity? Is
>> the
>>>> intent to say that the inputs typically rely on an L2SM
>> template?
>>>> 
>>>> Original:
>>>>  The L2NM can be fed with inputs that are requested by
>> customers,
>>>>  typically, relying upon an L2SM template.
>>>> 
>>>> Perhaps:
>>>>  The L2NM can be fed with inputs that are requested by
>> customers
>>>>  and that typically rely on an L2SM template.
>>> 
>>> [Med] This is better. Thanks.
>>> 
>>>> -->
>>>> 
>>>> 
>>>> 7) <!-- [rfced] Should the definition for "vpws-evpn" in
>> Section
>>>> 7.3 include the term "Ethernet VPN" to set it apart from the
>>>> definition preceding it?
>>>> 
>>>> Original:
>>>>  'vpws':    Virtual Private Wire Service (VPWS) as defined in
>>>>             Section 3.1.1 of [RFC4664].
>>>> 
>>>>  'vpws-evpn':   VPWS as defined in [RFC8214].
>>>> 
>>>> Perhaps:
>>>>  'vpws':    Virtual Private Wire Service (VPWS) as defined in
>>>>             Section 3.1.1 of [RFC4664].
>>>> 
>>>>  'vpws-evpn':   VPWS with support by Ethernet VPN as defined
>> in
>>>> [RFC8214].
>>>> -->
>>> 
>>> [Med] Works for me.
>>> 
>>>> 
>>>> 
>>>> 8) <!--[rfced] Would it make sense to replace the slash with
>> "and"?
>>>> Please clarify if it is a set of 1 each ("and"), or is it any
>>>> combination ("and/or")?
>>> 
>>> [Med] We can simplify and go for "policies" instead of
>> "policies/configurations".
>>> 
>>>> 
>>>> Original:
>>>>  The 'vpn-node' (Figure 8) is an abstraction that represents a
>> set
>>>> of
>>>>  policies/configurations applied to a network node that
>> belongs to a
>>>>  single 'vpn-service'.
>>>> 
>>>> Perhaps:
>>>>  The 'vpn-node' (Figure 8) is an abstraction that represents a
>> set
>>>> of
>>>>  policies and configurations applied to a network node that
>> belongs
>>>> to
>>>>  a single 'vpn-service'.
>>>> -->
>>>> 
>>>> 
>>>> 9) <!-- [rfced] May we rephrase this sentence to avoid "VLAN
>> bundle
>>>> bundle service"? Please let us know if the suggested text is
>>>> agreeable or if you prefer otherwise.
>>>> 
>>>> Original:
>>>>  For EVPN-related L2VPNs, 'service-interface-type' indicates
>> whether
>>>>  this is a VLAN-based, VLAN bundle, or VLAN-aware bundle
>> service
>>>> interface
>>>>  (Section 6 of [RFC7432]).
>>>> 
>>>> Perhaps:
>>>>  For EVPN-related L2VPNs, 'service-interface-type' indicates
>> whether
>>>>  this is a VLAN-based, VLAN-aware, or VLAN bundle service
>> interface
>>>>  (Section 6 of [RFC7432]).
>>>> -->
>>> 
>>> [Med] OK
>>> 
>>>> 
>>>> 
>>>> 10) <!--[rfced] Sections 8.1 and 8.2. Please clarify
>> "structure-
>>>> aware"; is this referring to a data type or is it a descriptive
>> term
>>>> for a service (i.e., a structured service)? If it's a data
>> type,
>>>> should it appear as lowercase with single quote marks (option
>> A)? If
>>>> it's a service, should it be updated as "a basic structure-
>> aware
>>>> service" or similar per use in RFC 5086? Note that there are
>> multiple
>>>> instances.
>>> 
>>> [Med] We are actually echoing what is in
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-parameters%2Fbgp-&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=kyEdziFZi%2F8HimJ%2BDeUTKnb%2BbnBKRcYXCKXDyAsgfQE%3D&amp;reserved=0
>> parameters.xhtml. We can't make a change here as the IANA registry
>> is authoritative.
>>> 
>>>> 
>>>> One example
>>>> 
>>>> Original:
>>>>   description
>>>>     "Nx64kbit/s Basic Service using Structure-aware.";
>>>>   reference
>>>>     "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
>>>>                Circuit Emulation Service over Packet Switched
>>>>                Network (CESoPSN)";
>>>> 
>>>> Perhaps:
>>>> A)    description
>>>>       "Nx64kbit/s basic service using 'structure-aware'"; or
>>>> 
>>>> B)    description
>>>>       "Nx64kbit/s using a basic structure-aware service.";
>>>> -->
>>>> 
>>>> 
>>>> 11) <!-- [rfced] Reference [RFC5143], used in Section 8.2, has
>> been
>>>> obsoleted by the older reference [RFC4842]. Should we update
>> this
>>>> document to reflect this?
>>>> -->
>>> 
>>> [Med] No, please maintain RFC5143.
>>> 
>>>> 
>>>> 
>>>> 12) <!--[rfced] Is "Election wait timer" intended here or
>> should this
>>>> be updated as "Designated Forwarder Wait timer" to match use in
>>>> Section 6 and also RFC 8584?
>>> 
>>> [Med] Indeed. We can use "DF Wait timer."
>>> 
>>>> 
>>>> Original:
>>>>  description
>>>>     "Election wait timer.";
>>>>  reference
>>>>     "RFC 8584: Framework for Ethernet VPN Designated
>>>>                Forwarder Election Extensibility";
>>>> 
>>>> Perhaps:
>>>>  description
>>>>     "Designated Forwarder Wait timer.";
>>>>  reference
>>>>     "RFC 8584: Framework for Ethernet VPN Designated
>>>>                Forwarder Election Extensibility";
>>>> -->
>>>> 
>>>> 
>>>> 13) <!--[rfced] A "Held for Document Update" errata submitted
>> by
>>>> Mohamed Boucadair (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6703&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=bA%2FKGvsrqnKB5vvRhETdlYXz3JprOqQnVpBk3weB288%3D&amp;reserved=0)
>>>> might apply to Section 8.4 of this document. Please review and
>> let us
>>>> know if the following change should be made.
>>>> 
>>> 
>>> [Med] No change is needed to 9291.
>>> 
>>>> Per Mohamed:
>>>> "Section 8 says:
>>>> 
>>>>                 leaf pbs {
>>>>                   type uint64;
>>>>                   units "bps";
>>>>                   description
>>>>                     "Peak Burst Size.  It is measured in bytes
>> per
>>>>                      second.";
>>>>                 }
>>>> 
>>>> It should say:
>>>> 
>>>>                 leaf pbs {
>>>>                   type uint64;
>>>>                   units "Bytes per Second";
>>>>                   description
>>>>                     "Peak Burst Size.";
>>>>                 }
>>>> 
>>>> Notes:
>>>> 
>>>> There is a mismatch between the units statement and the
>> description
>>>> text.
>>>> 
>>>> The corrected text assumes that the description reflects the
>> intent.
>>>> This is the meaning assumed in draft-ietf-opsawg-l2nm".
>>>> -->
>>> 
>>> [Med] FWIW, we used to have that in previous version because we
>> misinterpreted this parameter as being a rate, while this a about
>> size. The correct unit is what is in 9291.
>>> 
>>>> 
>>>> 
>>>> 14) <!--[rfced] We made "AII" plural in the following sentence.
>> If
>>>> that is not correct, please let us know.
>>>> 
>>> 
>>> [Med] The change is correct. Thanks.
>>> 
>>>> Original:
>>>>  list remote-targets {
>>>>    key "taii";
>>>>    description
>>>>      "List of allowed target Attachment Individual
>>>>       Identifier (AII) and peers.";
>>>> 
>>>> Perhaps:
>>>>  list remote-targets {
>>>>    key "taii";
>>>>    description
>>>>      "List of allowed target Attachment Individual
>>>>       Identifiers (AIIs) and peers.";
>>>> -->
>>>> 
>>>> 
>>>> 15) <!--[rfced] For clarity, may we rephrase this text as
>> suggested?
>>>> 
>>> 
>>> [Med] I suggest to maintain the original text.
>>> 
>>>> Original:
>>>>  description
>>>>    "Container for LDP or L2TP-signaled PWs
>>>>     choice.";
>>>> 
>>>> Perhaps:
>>>>  description
>>>>    "Container for the choice of LDP or
>>>>     L2TP-signaled PWs.";
>>>> -->
>>>> 
>>>> 
>>>> 16) <!--[rfced] Would it be correct to update this as "VLAN-
>> aware
>>>> VPWS" or
>>>> "VPWS VLAN-aware bundle service"?
>>>> 
>>>> Original:
>>>>  description
>>>>     "Enables (when set to 'true') or disables
>>>>      (when set to 'false') VPWS VLAN-aware.";
>>>> 
>>>> Perhaps:
>>>>  description
>>>>     "Enables (when set to 'true') or disables
>>>>      (when set to 'false') VLAN-aware VPWS.";
>>>> -->
>>>> 
>>> 
>>> [Med] What about?
>>> 
>>> NEW:
>>>                              "Enables (when set to 'true') or
>> disables
>>>                               (when set to 'false') VPWS VLAN-
>> aware
>>>                               service for the EVPN instance.";
>>> 
>>>> 
>>>> 17) <!--[rfced] *AD, please review the Security Considerations
>> and
>>>> let us
>>>> know if you approve the variance to the YANG boilerplate as
>>>> outlined below or if further changes should be made. Note that
>>>> paragraph 5 of the security boilerplate was not included;
>> please
>>>> confirm that it does not apply here. The boilerplate is
>> viewable
>>>> at: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fops%2Fwiki%2Fyang-security-&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=f6UuLT81LGkvw7BePutjTqbdMRHNvrrHDCqniwp2Ow8%3D&amp;reserved=0
>> guidelines
>>>> 
>>>> Note that "and delete operations" and "or authentication" was
>>>> added to
>>>> the boilerplate language as follows.
>>>> 
>>>> Current:
>>>>  Write operations (e.g., edit-config) and delete operations
>>>>  to these data nodes without proper protection or
>> authentication
>>>> can
>>>>  have a negative effect on network operations.
>>>> 
>>>> FYI - this is the missing text (paragraph 5 of the
>> boilerplate):
>>>>  Some of the RPC operations in this YANG module may be
>>>>  considered sensitive or vulnerable in some network
>>>> environments.
>>>>  It is thus important to control access to these operations.
>>>>  These are the operations and their sensitivity/vulnerability:
>>>> -->
>>>> 
>>>> 
>>>> 18) <!-- [rfced] FYI: We've updated the following sentence in
>>>> Section 9 for clarity regarding what the nodes contain. Please
>> let
>>>> us know if this changes the intended meaning.
>>>> 
>>>> Original:
>>>>  These identities are intended to be referenced by other YANG
>>>>  modules, and by themselves do not expose any nodes that are
>>>> writable,
>>>>  contain read-only state, or RPCs.
>>>> 
>>>> Updated:
>>>>  These identities are intended to be referenced by other YANG
>>>>  modules and by themselves do not expose any nodes that are
>>>> writable or
>>>>  contain read-only state or RPCs.
>>>> -->
>>>> 
>>> 
>>> [Med] ACK
>>> 
>>>> 
>>>> 19) <!--[rfced] In the Appendices, we removed the notes about
>> line
>>>> wrapping from the sourcecode and placed it above the figures.
>> Do
>>>> you prefer to leave all of these notes as is or should they
>>>> perhaps be removed since the use of line wrapping is described
>> in
>>>> Appendix A? If you would like to remove all of the notes,
>> perhaps
>>>> consider rephrasing the text in Appendix A as follows:
>>> 
>>> [Med] The OLD notes are required as per this text from RFC8792.
>>> 
>>> ==
>>> 7.1.  Folded Structure
>>> 
>>>  Text content that has been folded as specified by this
>> strategy MUST
>>>  adhere to the following structure.
>>> 
>>> 7.1.1.  Header
>>> 
>>>  The header is two lines long.
>>> 
>>>  The first line is the following 36-character string; this
>> string MAY
>>>  be surrounded by any number of printable characters.  This
>> first line
>>>  cannot itself be folded.
>>> 
>>>  NOTE: '\' line wrapping per RFC 8792
>>> 
>>>  The second line is an empty line, containing only the end-of-
>> line
>>>  character sequence.  This line provides visual separation for
>>>  readability.
>>> ==
>>> 
>>> Please revert back to the OLD wording. Thanks.
>>> 
>>>> 
>>>> Original:
>>>>  The examples use folding as defined in [RFC8792] for long
>>>> lines.
>>>> 
>>>> Perhaps:
>>>>  In Figures 24, 28, 30, and 35, '\' line wrapping is used for
>>>>  long lines as defined in [RFC8792].
>>>> -->
>>>> 
>>>> 
>>>> 20) <!-- [rfced] Please review the sourcecode elements in the
>>>> Appendices
>>>> and let us know if a "type" may be attributed. If the current
>>>> list of preferred values at
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2Fsourcecode-types.txt&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694653084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=ffRPmSN4nL31GScW9i7PiAaOpkFWrCUIwrt4Wf6Sn9I%3D&amp;reserved=0 does
>>>> not contain an applicable type, feel free to suggest a new one.
>>>> 
>>>> Note that it is acceptable to leave the type attribute empty.
>>>> -->
>>> 
>>> [Med] The type can be set for all these as json.
>>> 
>>>> 
>>>> 
>>>> 21) <!--[rfced] We updated the following to point to Figure 31
>>>> (instead of
>>>> Figure 29). We also updated the text slightly to clarify that
>>>> this example shows the use of L2NM to configure a VPWS-EVPN
>>>> instance. If that changes the intended meaning, please let us
>>>> know.
>>>> 
>>>> Original:
>>>>  Figure 29 shows a simplified configuration to illustrate the
>>>> use of
>>>>  the L2NM to a configured VPWS-EVPN instance.
>>>> 
>>>> Current:
>>>>  Figure 31 shows a simplified configuration to illustrate the
>>>> use of
>>>>  the L2NM to configure a VPWS-EVPN instance.
>>>> -->
>>>> 
>>> 
>>> [Med] Good catch. Thanks.
>>> 
>>>> 
>>>> 22) <!-- [rfced] FYI: Please note that we have alphabetized
>>>> certain
>>>> sequential contributors in the Acknowledgments section where it
>>>> appears alphabetization was preferred.
>>>> -->
>>>> 
>>> 
>>> [Med] ACK.
>>> 
>>>> 
>>>> 23) <!-- [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.
>>>> 
>>>> CE-VLAN vs. CE VLAN (note: no hyphen used in RFC 7432)
>>> 
>>> [Med] We can go for what is used in 7432.
>>> 
>>>> h-vpls vs. H-VPLS
>>> 
>>> [Med] We can use H-VPLS.
>>> 
>>>> t-ldp pw type vs. T-LDP PW type
>>> 
>>> [Med] Please use T-LDP PW type.
>>> 
>>>> split horizon vs. Split Horizon
>>> 
>>> [Med] Split Horizon
>>> 
>>>> oam 802.3ah vs. OAM 802.3ah
>>> 
>>> [Med] OAM 802.3ah
>>> 
>>>> 
>>>> 
>>>> In Addition:
>>>> A) We updated "BUM" as follows per usage in past RFCs
>>>> (specifically,
>>>> per RFC 8584, which is a normative reference):
>>>> 
>>>> Original:
>>>>  Broadcast, unknown unicast, or multicast
>>>> 
>>> 
>>> [Med] The original was following RFC7432. I suggest to keep it.
>>> 
>>>> Current:
>>>>  Broadcast, Unknown Unicast, and Multicast
>>>> 
>>>> B) We updated the expansion of "VXLAN" to match
>>>> use in RFC 8365.
>>>> 
>>>> Original:
>>>>  Virtual eXtensible Local Area Network (VXLAN)
>>>> 
>>>> Current:
>>>>  Virtual Extensible LAN (VXLAN)
>>>> -->
>>> 
>>> [Med] OK
>>> 
>>>> 
>>>> 
>>>> 24) <!-- [rfced] Please review the "Inclusive Language" portion
>> of
>>>> the online
>>>> Style Guide <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-%2F&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=a9zk2vZNoqv%2FlzDQ0AqpIYa5R9MFk5Iay6KHnAmXdxc%3D&amp;reserved=0
>>>> editor.org/styleguide/part2/#inclusive_language>
>>>> and let us know if any changes are needed.
>>>> 
>>>> Please note that we did not detect any terms that might be an
>>>> issue.
>>>> -->
>>> 
>>> [Med] ACK.
>>> 
>>>> 
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor/re/kc
>>>> 
>>>> 
>>>> On Sep 1, 2022, at 11:06 AM, [e-mail] wrote:
>>>> 
>>>> *****IMPORTANT*****
>>>> 
>>>> Updated 2022/09/01
>>>> 
>>>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-%2F&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=a9zk2vZNoqv%2FlzDQ0AqpIYa5R9MFk5Iay6KHnAmXdxc%3D&amp;reserved=0
>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info%2F&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=SdYRkRrFjakjxnfwoFfKW%2FQJer%2FdvADcxYHXt44WJbo%3D&amp;reserved=0).
>>>> 
>>>> *  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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=PHDAF%2B6jdT1Eqf35%2FhMc5DhXpo%2F5PY5HVrh%2BiRdc2Y4%3D&amp;reserved=0>.
>>>> 
>>>> *  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
>>>> 
>>>> *  [e-mail] (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).
>>>> 
>>>> *  [e-mail], which is a new archival
>> mailing
>>>> list
>>>>    to preserve AUTH48 conversations; it is not an active
>>>> discussion
>>>>    list:
>>>> 
>>>>   *  More info:
>>>>      https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=wUYQD016SR23w4d5c3DFX1QKL2P2ugFlhhWi7iRPdk0%3D&amp;reserved=0
>>>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>> 
>>>>   *  The archive itself:
>>>>      https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=Iqy%2BN0L0BUE69Sa5g03ARUFdsl7M42WYhAqfiFX6VzE%3D&amp;reserved=0
>>>> 
>>>>   *  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,
>>>>      [e-mail] 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291.xml&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=qdV03TLfLO1Q2vYualDi1ExpjGg3orrUF%2B0LOSgSvkA%3D&amp;reserved=0
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291.html&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=LsqlH758rFqDFUOFrYFujyJvzBLsG17F4NUEGLEj7Tg%3D&amp;reserved=0
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291.pdf&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=owhaRGPwRo2vozlXABTqQHCDxBBugvLKI3NzKwCx2l4%3D&amp;reserved=0
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291.txt&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=96ZkQARcEO6I%2FhmSl8i0F7mFpkAUsoX8mmSjG7JLDmw%3D&amp;reserved=0
>>>> 
>>>> Diff file of the text:
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291-diff.html&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=JlznTycwP2bxIFli%2BT79E2dJnplTfJDgZ1rJQ8FHY%2BU%3D&amp;reserved=0
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291-rfcdiff.html&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=PNF4VmbO070rINw70IEWgCLRqBEGykzUWaaGS68cfP8%3D&amp;reserved=0 (side
>> by
>>>> side)
>>>> 
>>>> Diff of the XML:
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291-xmldiff1.html&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=czaOBn0gA3LYV2PsX5VillmG8Jsn%2FrcRx886vP3jw1E%3D&amp;reserved=0
>>>> 
>>>> The following files are provided to facilitate creation of your
>>>> own
>>>> diff files of the XML.
>>>> 
>>>> Initial XMLv3 created using XMLv2 as input:
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291.original.v2v3.xml&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=j9k385ktLp1sU1lv2ibhUUguKFQD8l5mOJSs4S1bf5A%3D&amp;reserved=0
>>>> 
>>>> XMLv3 file that is a best effort to capture v3-related format
>>>> updates
>>>> only:
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9291.form.xml&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=eK0BRPvpLsn%2BNHwL1MB7u5%2BIfE9GPy0RN%2Bmyymh9esI%3D&amp;reserved=0
>>>> 
>>>> 
>>>> Tracking progress
>>>> -----------------
>>>> 
>>>> The details of the AUTH48 status of your document are here:
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9291&amp;data=05%7C01%7Cluis-angel.munoz%40vodafone.com%7C9e43d772f07748abcf5f08da8f1a07eb%7C68283f3b84874c86adb3a5228f18b893%7C0%7C0%7C637979639694809310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=KKDQeYxZ4M5qNELgFPY8aXANsWf19qE9Aun11O03wCI%3D&amp;reserved=0
>>>> 
>>>> Please let us know if you have any questions.
>>>> 
>>>> Thank you for your cooperation,
>>>> 
>>>> RFC Editor
>>>> 
>>>> --------------------------------------
>>>> RFC9291 (draft-ietf-opsawg-l2nm-19)
>>>> 
>>>> Title            : A YANG Network Data Model for Layer 2 VPNs
>>>> Author(s)        : M. Boucadair, O. Gonzalez de Dios, S.
>> Barguil,
>>>> L. Munoz
>>>> WG Chair(s)      : Henk Birkholz, Joe Clarke, Tianran Zhou
>>>> Area Director(s) : Warren Kumari, Robert Wilton
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> __________________________________________________________________
>> _______________________________________________________
>>> 
>>> Ce message et ses pieces jointes peuvent contenir des
>> informations confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si
>> vous avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere,
>> deforme ou falsifie. Merci.
>>> 
>>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law;
>>> they should not be distributed, used or copied without
>> authorisation.
>>> If you have received this email in error, please notify the
>> sender and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that
>> have been modified, changed or falsified.
>>> Thank you.
>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.