Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] May we update the title of this document as follows? We have received guidance from Benoit Claise and the YANG Doctors that "YANG module" and "YANG data model" are preferred, and our suggested text more closely matches the title of RFC 8519. Note that if the document title is updated, we will also update the references to this document within the YANG module (Section 4). Original: Extensions to the Access Control Lists (ACLs) YANG Model Perhaps: Extensions to the YANG Data Model for Access Control Lists (ACLs) --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] Would option A or B below clarify how "optionally the code and the rest of the header" relates to the rest of the sentence? Original: ICMP sets: An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6 [RFC4443] types, each of them identified by a type value, optionally the code and the rest of the header. Perhaps A: ICMP sets: An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6 [RFC4443] types, and each type is identified by a type value, the code (optionally), and the rest of the header. or Perhaps B: ICMP sets: An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6 [RFC4443] types, and each type is identified by a type value and is optionally identified by the code and the rest of the header. --> 4) <!-- [rfced] FYI - We have updated "EVNP-PBB" to "EVPN-PBB" in the text below. Please review. Original: Being able to filter by I-component Service identifier is a feature of the EVNP-PBB configuration. Current: Being able to filter by I-component service identifier is a feature of the EVPN-PBB configuration. --> 5) <!-- [rfced] Questions about Section 4 a) The following sentence does not mention RFC 8341, but RFC 8341 is referenced in the YANG module. May we update this sentence to include RFC 8341 as well? Original: This model imports types from [RFC6991], [RFC8519], and [RFC8294]. Perhaps: This Yang module imports types from [RFC6991], [RFC8341], [RFC8519], and [RFC8294]. b) Should Qin Wu be added to the list of authors in the YANG module in this section? c) May we add the IANA reference information for the IANA URL listed in this reference entry? Original: reference "RFC 9293: Transmission Control Protocol (TCP), Section 3.1 https://www.iana.org/assignments/tcp-parameters";; Perhaps: reference "RFC 9293: Transmission Control Protocol (TCP), Section 3.1 IANA: Transmission Control Protocol (TCP) Parameters, <https://www.iana.org/assignments/tcp-parameters>"; --> 6) <!-- [rfced] Questions about the Security Considerations (Section 5) For reference: YANG security considerations template: <https://wiki.ietf.org/group/ops/yang-security-guidelines> a) The "RPC/action operations section" does not appear in this document. The YANG security considerations template suggests including the following text if this section does not apply; should this text be added to this section? Perhaps: "There are no particularly sensitive RPC or action operations." b) The "Reusable groupings from other modules section" does not appear in this document. Please review the template and confirm that this paragraph does not apply. c) Per the "No data nodes section" portion of the YANG security considerations template, should it be included whether the "ietf-acl-enh" YANG module defines a set of identities, types, and groupings? Also, is it correct to include the three IANA modules in this paragraph, or should the modules or this paragraph perhaps be removed since the IANA modules were removed from the document itself? Current: The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana- ipv6-ext-types" define a set of identities, types, and groupings. These nodes are intended to be reused by other YANG modules. Each module by itself does not expose any data nodes that are writable, data nodes that contain read-only state, or RPCs. d) Per the "No data nodes section" portion of the YANG security considerations template, should the following paragraph be added to Section 5? If so, please review and let us know what we may replace 'node-example' with. Perhaps: Modules that use the groupings that are defined in this document should identify the corresponding security considerations. For example, reusing some of these groupings will expose privacy-related information (e.g., 'node-example'). --> 7) <!-- [rfced] We have included specific questions about the IANA text below. In addition to responding to those questions, please review all of the IANA-related updates carefully and let us know if any further updates are needed. a) We note that RFC 9890 is included as a reference for the "YANG Module Names" registry <https://www.iana.org/assignments/yang-parameters/>. Should RFC 9890 be added to the text below and to the Informative References section? Current: IANA has registered the following YANG modules in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group. Perhaps: IANA has registered the following YANG modules in the "YANG Module Names" registry [RFC6020] [RFC9890] within the "YANG Parameters" registry group. b) FYI: Per the note from the authors, we replaced the [IANA_ICMPv4_YANG_URL], [IANA_ICMPv6_YANG_URL], and [IANA_IPV6_YANG_URL] citations with the [IANA-YANG-PARAMETERS] citation as shown below. Original: (Section 1) Readers should refer to the IANA websites [IANA_ICMPv4_YANG_URL], [IANA_ICMPv6_YANG_URL], and [IANA_IPV6_YANG_URL] to retrieve the latest version of these IANA-maintained modules. (Section 6.3.1) When this registry is modified, the YANG module "iana- icmpv4-types" [IANA_ICMPv4_YANG_URL] must be updated as defined in RFC 9899. (Section 6.3.2) When this registry is modified, the YANG module "iana- icmpv6-types" [IANA_ICMPv6_YANG_URL] must be updated as defined in RFC 9899. (Section 6.3.3) When this registry is modified, the YANG module "iana-ipv6-ext- types" [IANA_IPV6_YANG_URL] must be updated as defined in RFC 9899. Current: (Section 1) The latest version of these IANA-maintained modules can be retrieved from the "YANG Parameters" registry group [IANA-YANG-PARAMETERS]. (Section 6.3.1) When this registry is modified, the YANG module "iana- icmpv4-types" [IANA-YANG-PARAMETERS] must be updated as defined in RFC 9899. (Section 6.3.2) When this registry is modified, the YANG module "iana- icmpv6-types" [IANA-YANG-PARAMETERS] must be updated as defined in RFC 9899. (Section 6.3.3) When this registry is modified, the YANG module "iana- ipv6-ext-types" [IANA-YANG-PARAMETERS] must be updated as defined in RFC 9899. c) We note that the description of "enum" appears slightly different in Sections 6.3.1, 6.3.2, and 6.3.3. Should these instances be made consistent? If so, please let us know how to update. In addition, should "striped" be "stripped"? Original: "enum": Replicates the name from the registry with all illegal characters (e.g., spaces) are striped. "enum": Replicates the name from the registry with all illegal characters (e.g., spaces) striped. "enum": Replicates the description from the registry with all spaces striped. Perhaps: "enum": Replicates the name from the registry with all illegal characters (e.g., spaces) stripped. d) We note that this item appears slightly different in the following sections. Please review and let us know if/how to update for consistency. Usage in Sections 6.3.1. and 6.3.2: "description": Replicates the name from the registry. Usage in Section 6.3.3: "description": Replicates the description from the registry. e) FYI: We typically note that a document has been added as an additional reference to a registry within the running text (in paragraph form). Thus, we updated the text in Sections 6.3.1, 6.3.2, and 6.3.3 as shown below (i.e., removed "OLD/NEW" and removed RFCs 2780, 5237, and 7045 from the Informative References section as they were only mentioned in the "OLD/NEW" text). Please let us know of any objection. One example (from Section 6.3.1) Original: IANA is requested to add this note to "ICMP Type Numbers" [IANA-ICMPv4]: [...] IANA is requested to update the "Reference" in the "ICMP Type Numbers" registry as follows: OLD: [RFC2780] NEW: [RFC2780][RFCXXXX] Current: IANA has added this note to the "ICMP Type Numbers" registry [IANA-ICMPv4] and listed this document as an additional reference for the registry: [...] --> 8) <!--[rfced] We updated <artwork> to <sourcecode type="json"> for Figure 3 in Appendix A.1. Please confirm that this is correct. In addition, please confirm that the "type" attribute of all the sourcecode elements are correct. The current list of preferred values for "type" is available at https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> 9) <!-- [rfced] May we update as follows to avoid repetition of "defining" and "defined"? Original: Defining this field to be defined as a flag bitmask together with a set of operations is meant to efficiently handle TCP flags filtering rules. Perhaps: Defining this field as a flag bitmask together with a set of operations is meant to efficiently handle TCP flags filtering rules. --> 10) <!-- [rfced] Abbreviations a) FYI - We have expanded the following abbreviations upon first use. Please review each expansion in the document carefully to ensure correctness. Datagram Congestion Control Protocol (DCCP) Explicit Congestion Notification (ECN) Media Access Control (MAC) Stream Control Transmission Protocol (SCTP) b) How should "VRF" be expanded in Appendix A.8? Perhaps one of these options: 1) VPN Routing and Forwarding (VRF) 2) Virtual Routing and Forwarding (VRF) 3) Verifiable Random Function (VRF) --> 11) <!-- [rfced] Terminology a) Section 4: In this section's YANG module, we note mixed use of abbreviation and expansion for the terms below. For consistency, may we update to use the abbreviated form of these terms after their first expansions? Traffic Class vs. TC Time-to-live vs. TTL c) We note a few instances of "ISID" in Appendix B. Should these instances be updated to "I-SID" for consistency? --> 12) <!-- [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. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. Kaelin Foody and Karen Moore RFC Production Center On Nov 11, 2025, at 11:13 AM, RFC Editor via auth48archive <[email protected]> wrote: *****IMPORTANT***** Updated 2025/11/11 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 * [email protected] (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). * [email protected], 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, [email protected] 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/rfc9899.xml https://www.rfc-editor.org/authors/rfc9899.html https://www.rfc-editor.org/authors/rfc9899.pdf https://www.rfc-editor.org/authors/rfc9899.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9899-diff.html https://www.rfc-editor.org/authors/rfc9899-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9899-xmldiff1.html For your convenience, we have also created an alt-diff file that will allow you to more easily view changes where text has been deleted or moved: https://www.rfc-editor.org/authors/rfc9899-alt-diff.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9899 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9899 (draft-ietf-netmod-acl-extensions-17) Title : Extensions to the Access Control Lists (ACLs) YANG Model Author(s) : O. Gonzalez de Dios, S. Barguil, M. Boucadair, Q. Wu WG Chair(s) : Kent Watsen, Lou Berger Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
