[auth48] [AD] Re: AUTH48: RFC-to-be 9291 <draft-ietf-opsawg-l2nm-19> for your review
rfc-editor@rfc-editor.org Thu, 01 September 2022 18:08 UTC
Return-Path: <wwwrun@rfcpa.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 4C9DFC1524DE; Thu, 1 Sep 2022 11:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.659
X-Spam-Level:
X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.998, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 fWdqnezU4hCO; Thu, 1 Sep 2022 11:08:28 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (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 9C8EDC1524D4; Thu, 1 Sep 2022 11:08:28 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 3B6C585CCC; Thu, 1 Sep 2022 11:08:28 -0700 (PDT)
To: mohamed.boucadair@orange.com, oscar.gonzalezdedios@telefonica.com, samier.barguilgiraldo.ext@telefonica.com, luis-angel.munoz@vodafone.com
From: rfc-editor@rfc-editor.org
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
Content-type: text/plain; charset="UTF-8"
Message-Id: <20220901180828.3B6C585CCC@rfcpa.amsl.com>
Date: Thu, 01 Sep 2022 11:08:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/veY8ThFTyZl-LkK5Ely-a0AG4Gs>
Subject: [auth48] [AD] Re: 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: Thu, 01 Sep 2022 18:08:32 -0000
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 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 --> 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" --> 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. --> 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 +- -rw broadcast-unknown-unicast-multicast 2. 2 chars too long: | | | | | yang:mac-address | | | | | yang:mac-address | | | | +- -rw any? empty | | +- -rw target-class-id? string | | +- -rw name string | | +- -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", 3. 3 chars too long: +- -rw id vpn-common:vpn-id +- -rw multicast-gp-address-mapping* [id] "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\ --> 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)". 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. --> 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]. --> 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")? 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]). --> 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. 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? --> 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? 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. 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". --> 14) <!--[rfced] We made "AII" plural in the following sentence. If that is not correct, please let us know. 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? 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."; --> 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. --> 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: 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. --> 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. --> 22) <!-- [rfced] FYI: Please note that we have alphabetized certain sequential contributors in the Acknowledgments section where it appears alphabetization was preferred. --> 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) h-vpls vs. H-VPLS t-ldp pw type vs. T-LDP PW type split horizon vs. Split Horizon oam 802.3ah vs. 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 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) --> 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. --> 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
- [auth48] AUTH48: RFC-to-be 9291 <draft-ietf-opsaw… rfc-editor
- [auth48] [AD] Re: AUTH48: RFC-to-be 9291 <draft-i… rfc-editor
- Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9291 <dra… mohamed.boucadair
- Re: [auth48] AUTH48: RFC-to-be 9291 <draft-ietf-o… mohamed.boucadair
- Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-i… Reuben Esparza
- Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-i… Adrian Farrel
- Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-i… mohamed.boucadair
- Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-i… Rob Wilton (rwilton)
- Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-i… LUIS ANGEL MUÑOZ, Vodafone
- Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-i… Reuben Esparza
- Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-i… SAMIER BARGUIL GIRALDO
- Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-i… Reuben Esparza
- Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-i… Oscar González de Dios
- Re: [auth48] [AD] AUTH48: RFC-to-be 9291 <draft-i… Reuben Esparza
- [auth48] Final question - Re: AUTH48: RFC-to-be 9… Sandy Ginoza
- Re: [auth48] Final question - Re: AUTH48: RFC-to-… mohamed.boucadair