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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Rueben,

> -----Original Message-----
> From: Reuben Esparza <[e-mail]>
> Sent: 03 September 2022 02:18
> To: Mohamed Boucadair <[e-mail]>;
> [e-mail];
> [e-mail]; luis-
> [e-mail]; Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: 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://trac.ietf.org/trac/ops/wiki/yang-security-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:
> —>

I approve the current text (since the module defines no YANG RPCs or actions).

Regards,
Rob


> 
> 
> 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://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 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://www.iana.org/assignments/bgp-parameters/bgp-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://www.rfc-editor.org/errata/eid6703)
> >> 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://trac.ietf.org/trac/ops/wiki/yang-security-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://www.rfc-editor.org/materials/sourcecode-types.txt 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://www.rfc-
> >> 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://www.rfc-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://trustee.ietf.org/license-info/).
> >>
> >> *  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://authors.ietf.org/rfcxml-vocabulary>.
> >>
> >> *  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://mailarchive.ietf.org/arch/msg/ietf-
> >> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >>
> >>    *  The archive itself:
> >>       https://mailarchive.ietf.org/arch/browse/auth48archive/
> >>
> >>    *  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://www.rfc-editor.org/authors/rfc9291.xml
> >>  https://www.rfc-editor.org/authors/rfc9291.html
> >>  https://www.rfc-editor.org/authors/rfc9291.pdf
> >>  https://www.rfc-editor.org/authors/rfc9291.txt
> >>
> >> Diff file of the text:
> >>  https://www.rfc-editor.org/authors/rfc9291-diff.html
> >>  https://www.rfc-editor.org/authors/rfc9291-rfcdiff.html (side by
> >> side)
> >>
> >> Diff of the XML:
> >>  https://www.rfc-editor.org/authors/rfc9291-xmldiff1.html
> >>
> >> The following files are provided to facilitate creation of your
> >> own
> >> diff files of the XML.
> >>
> >> Initial XMLv3 created using XMLv2 as input:
> >>  https://www.rfc-editor.org/authors/rfc9291.original.v2v3.xml
> >>
> >> XMLv3 file that is a best effort to capture v3-related format
> >> updates
> >> only:
> >>  https://www.rfc-editor.org/authors/rfc9291.form.xml
> >>
> >>
> >> Tracking progress
> >> -----------------
> >>
> >> The details of the AUTH48 status of your document are here:
> >>  https://www.rfc-editor.org/auth48/rfc9291
> >>
> >> 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.
>