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

Reuben Esparza <resparza@amsl.com> Sat, 03 September 2022 01:19 UTC

Return-Path: <resparza@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AB7C1524CB; Fri, 2 Sep 2022 18:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9beHr8PEeozV; Fri, 2 Sep 2022 18:19:19 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651DCC1524B0; Fri, 2 Sep 2022 18:19:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 41A574243EFA; Fri, 2 Sep 2022 18:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBheAZHyyTtZ; Fri, 2 Sep 2022 18:19:19 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2601:646:203:1300:bd85:3174:481a:8d21]) by c8a.amsl.com (Postfix) with ESMTPSA id DE2B74243EF9; Fri, 2 Sep 2022 18:19:18 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Reuben Esparza <resparza@amsl.com>
In-Reply-To: <28115_1662119547_6311EE7B_28115_225_1_2f476e52a9344d9985197bfd079e7412@orange.com>
Date: Fri, 02 Sep 2022 18:18:17 -0700
Cc: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "opsawg-ads@ietf.org" <opsawg-ads@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <68EC786B-26AD-43F0-ABC7-F10086847648@amsl.com>
References: <20220901180828.3B6C585CCC@rfcpa.amsl.com> <28115_1662119547_6311EE7B_28115_225_1_2f476e52a9344d9985197bfd079e7412@orange.com>
To: Mohamed Boucadair <mohamed.boucadair@orange.com>, "oscar.gonzalezdedios@telefonica.com" <oscar.gonzalezdedios@telefonica.com>, "samier.barguilgiraldo.ext@telefonica.com" <samier.barguilgiraldo.ext@telefonica.com>, "luis-angel.munoz@vodafone.com" <luis-angel.munoz@vodafone.com>, "rwilton@cisco.com" <rwilton@cisco.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/TyMxuIKS0YsFckGx2CHMshmqaWY>
Subject: Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-ietf-opsawg-l2nm-19> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Sep 2022 01:19:24 -0000

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:                                                
—>


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, mohamed.boucadair@orange.com wrote:
> 
> Dear RFC Editor, all, 
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>
>> Envoyé : jeudi 1 septembre 2022 20:08
>> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
>> oscar.gonzalezdedios@telefonica.com;
>> samier.barguilgiraldo.ext@telefonica.com; luis-
>> angel.munoz@vodafone.com
>> Cc : rfc-editor@rfc-editor.org; opsawg-ads@ietf.org; opsawg-
>> chairs@ietf.org; adrian@olddog.co.uk; rwilton@cisco.com;
>> auth48archive@rfc-editor.org
>> 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, rfc-editor@rfc-editor.org 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
>> 
>>  *  rfc-editor@rfc-editor.org (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).
>> 
>>  *  auth48archive@rfc-editor.org, 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,
>>       auth48archive@rfc-editor.org 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.