Hi Kaelin/Karen, Thank you for preparing this edited version.
Please see inline. Cheers, Med > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : mardi 11 novembre 2025 20:16 > À : [email protected]; > [email protected]; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; [email protected] > Cc : [email protected]; [email protected]; netmod- > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Re: AUTH48: RFC-to-be 9899 <draft-ietf-netmod-acl- > extensions-17> for your review > > 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. [Med] Please note that the latest update on the matter is: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#name-yang-data-model-vs-yang-mod. > > 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) > --> [Med] Works for me. > > > 2) <!-- [rfced] Please insert any keywords (beyond those that > appear in the title) for use on > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fsearch&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7C9c3b6e6ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C638984854184576393%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y%2FzFc40KEiDDrrmHawhReFVMVKB > IBRmsxzOF%2FR7EK7U%3D&reserved=0. --> > [Med] Please consider the following: * Filtering * Security * Authorization * Match * Packet identification * Scrubbing * Packet pattern * payload filtering > > 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. > --> > [Med] Option B reflects the intent. > > 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. > --> > [Med] Good catch. > > 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? [Med] That's not needed as we do already mention that RFC elsewhere: CURRENT: The Network Configuration Access Control Model (NACM) [RFC8341] > > 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? [Med] Please keep the current list as it is. Thanks. > > c) May we add the IANA reference information for the IANA URL > listed in this reference entry? [Med] Yes, please. > > Original: > > reference > "RFC 9293: Transmission Control Protocol (TCP), > Section 3.1 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.iana.org%2Fassignments%2Ftcp- > parameters&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b6e6 > ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C638984854184599179%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=cnKri4FmE%2BoFCJS2DyocPaiTj%2F4ExP%2Bm > oN8HIO99dYI%3D&reserved=0"; > > Perhaps: > > reference > "RFC 9293: Transmission Control Protocol (TCP), > Section 3.1 > IANA: Transmission Control Protocol (TCP) Parameters, > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iana.org%2Fassignments%2Ftcp- > parameters&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b6e6 > ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C638984854184614253%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=AQe%2F6TTxQx1ux7pU2nVoNgO6uVpUBlnYeEkK > WZgZVZ8%3D&reserved=0>"; > --> > > > 6) <!-- [rfced] Questions about the Security Considerations > (Section 5) > > For reference: > YANG security considerations template: > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b6e6 > ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C638984854184628925%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=OLUs4U9eZ8jxCAgo6kDs%2FWHAvEMyamn3ln09 > 9TuvbI4%3D&reserved=0> > > 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." [Med] It can be added. Thanks. > > > 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. > [Med] ACK. > > 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. [Med] This text should be kept as we are defining the initial versions. However, we need to revert back some changes. Please make this change as we don't have any groupings and identities in these modules: CURRENT: The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana- ipv6-ext-types" define a set of identities, types, and groupings. NEW: The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana- ipv6-ext-types" define a set of types. > > > 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'). [Med] This is not needed. > --> > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iana.org%2Fassignments%2Fyang- > parameters%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b > 6e6ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > 0%7C0%7C638984854184643825%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=AceLXp0CzBd07a7reLg6AvvZLbQB0SHoPbK > MUQjzY3s%3D&reserved=0>. > 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. [Med] OK. > > 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. > > [Med] ACK. > 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. [Med] The OLD is correct as there is no "name" field in the IANA registry discussed in 6.3.3 > > > 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. > [Med] The OLD is correct as there is no "name" field in the IANA registry discussed in 6.3.3 > > 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. [Med] I see the reference was updated in the IANA registry. That’s OK. > > 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. [Med] ACK > > In addition, please confirm that the "type" attribute of all the > sourcecode elements are correct. [Med] ACK. > > The current list of preferred values for "type" is available at > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fmaterials%2Fsourcecode- > types.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b6e6c > e8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C638984854184658579%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=4WP%2BW%2FJkASHvy3m9XSwlZNJuy%2FklMpKXr > 2j1QpxXIb8%3D&reserved=0. 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. [Med] This is better. > --> > > > 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) [Med] OK > > 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) > --> [Med] Please use "Virtual Routing and Forwarding (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? [Med] OK > > 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? [Med] Yes, please use I-SID. > --> > > > 12) <!-- [rfced] Please review the "Inclusive Language" portion of > the online Style Guide > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7C9c3b6e6ce8d54be3223a08de2156 > d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389848541846749 > 69%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=SFud2BK9k244Bg6TX7Gp8JUWvSBZlmsldlQ0iE6ZYNU%3D&reserved=0> > 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. --> [Med] Nothing to flag on our side as well. > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Ffaq%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7C9c3b6e6ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C638984854184692034%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rq9CRpHW8nYMTMo5IN3R53D31EjfB > h1CJa7A27aq3fc%3D&reserved=0). > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > trustee.ietf.org%2Flicense- > info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b6e6ce8d54 > be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 38984854184707806%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=hpN0fZ5bks5J%2FNTih0aMAES%2Bai0gzykpLtDbMrNi > 23U%3D&reserved=0). > > * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthors.ietf.org%2Frfcxml- > vocabulary&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b6e6 > ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C638984854184722732%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=XX9Aagp2dU5Yw2dyhmyIcRqZC7a8GFCSgOPy%2 > BwSvRKw%3D&reserved=0>. > > * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > C9c3b6e6ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638984854184737228%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mtZQ4dRgLRMhzn1pSbaYrbs92upW95 > uxD8jT9LLqnq4%3D&reserved=0 > > * The archive itself: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7C9c3b6e6ce8d54be3223a08de2156 > d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6389848541847516 > 21%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=DR%2BVHFgxx93qbQ4ZVkn4GdMILUHReGwdV06aSsKNNu8%3D&reserved=0 > > * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9899.xml&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C9c3b6e6ce8d54be3223a08de2156d19c%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C638984854184766415%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8CJvhKPmuraIEj > Vk%2BE6oxtqYSkuDmlQ10TQcqWLoDBg%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9899.html&data=05%7C02%7Cmohamed.boucada > ir%40orange.com%7C9c3b6e6ce8d54be3223a08de2156d19c%7C90c7a20af34b4 > 0bfbc48b9253b6f5d20%7C0%7C0%7C638984854184781189%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VMRoKh3ai5zOa > 9RvlSjKpX2rIB9RZQwonh0%2Fz%2BTcG2U%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9899.pdf&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C9c3b6e6ce8d54be3223a08de2156d19c%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C638984854184796749%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qPirfsj%2FeIHN > POFZNg7xpGTvWBpYdwbSLSBPpRFu8x8%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9899.txt&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C9c3b6e6ce8d54be3223a08de2156d19c%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C638984854184811557%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IHWn9o6Pw%2FXO > hamFVOtLNF1MT5JLv1mpdbb5ts2hTEg%3D&reserved=0 > > Diff file of the text: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9899- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b6e6c > e8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C638984854184826010%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=xIyBm7MiwshFE7cOGAjZAuyaILN29EQv0WSuKzR > 2lQA%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9899- > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b6 > e6ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C638984854184843429%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=BjnLYMV4KY%2FLiRhB%2FSSqnw9aHMBMtoiT > MUqjnuzPgTI%3D&reserved=0 (side by side) > > Diff of the XML: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9899- > xmldiff1.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b > 6e6ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > 0%7C0%7C638984854184858503%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=ndtMd0PIFPX9x%2FToYeSk9%2BGvKoAPEFv > 3KbXMbKZpw%2F0%3D&reserved=0 > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9899-alt- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c3b6e6c > e8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C638984854184873765%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=SdCR%2B2pUBw0ee2bZN9PnTNgR5C2XttufnUy%2 > FjGemE3U%3D&reserved=0 > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauth48%2Frfc9899&data=05%7C02%7Cmohamed.boucadair%40o > range.com%7C9c3b6e6ce8d54be3223a08de2156d19c%7C90c7a20af34b40bfbc4 > 8b9253b6f5d20%7C0%7C0%7C638984854184888699%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=92wUN2DmogFjYAd7tpa > 5jsbOuIkqiqG2y5jazcI48UU%3D&reserved=0 > > 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] ____________________________________________________________________________________________________________ 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. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
