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

[[e-mail]]

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.