Hi Rebecca, all, Thanks for preparing this edited version.
Please see inline. Cheers, Med > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : samedi 14 mars 2026 06:45 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected] > Cc : [email protected]; [email protected]; opsawg- > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Re: AUTH48: RFC-to-be 9950 <draft-ietf-opsawg-secure- > tacacs-yang-13> 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] The abbreviated title (appears in the running > header in PDF > output) and the abstract use "TACACS+ over TLS". The document > title does not include "over TLS". Please review and let us know > if any updates are needed for consistency. > > Document title: > A YANG Data Model for Terminal Access Controller Access-Control > System > Plus (TACACS+) > > Abbreviated title: > YANG for TACACS+ over TLS > [Med] Please delete "over TLS". That abbr was stale as the draft started as a TLS extension but we ended with a bis. > Abstract: > Specifically, the YANG > module t TACACS+ over TLS 1.3. > --> [Med] I suggest: NEW: Specifically, the TACACS+ YANG module can be used to manage TACACS+ over TLS. > > > 2) <!-- [rfced] Please also review the text after "YANG module > for" in these sentences from the Abstract and Introduction. The > phrasing is different; please confirm the meaning is > correct/consistent for both. > > Abstract: > Specifically, this document defines a YANG > module for TACACS+ over TLS 1.3. > > Introduction: > This document defines a YANG module for managing TACACS+ > clients > (Section 4), including TACACS+ over TLS 1.3 clients > [I-D.ietf-opsawg-tacacs-tls13]. > --> [Med] I think this is now better with the NEW above. > > > 3) <!-- [rfced] In Section 3, should the "augment" line be > indented 2 spaces (as it would be if it were incorporated into a > full tree diagram per Section 2 of 8340)? We would indent the > other lines 2 spaces as well. We do not believe this would cause > any issues with line length for the TXT output. > --> > [Med] I don’t think this is needed. > > 4) <!-- [rfced] Is "Section 3.3" correct here? We ask because we > do not see "domain name" or "domain-name" in Section 3.3 of > [RFC9887]. Is another section in [RFC9887] intended, perhaps > Section 3.4.2? [Med] Good catch. I agree this should be changed to 3.4.2. > > Current: > 'domain-name': Provides a domain name of the server per > Section 3.3 > of [I-D.ietf-opsawg-tacacs-tls13]. This is the TLS TACACS+ > server's domain name that is included in the SNI extension. > This > domain name is distinct from the IP address/hostname used > for the > underlying transport connection. > --> > > > 5) <!-- [rfced] We note that RFCs 8446, 8907, 9105, and 6066 are > cited in the YANG module, but they are not included in the text > introducing the module (see below). Please let us know if these > should be added. If they are added, please indicate which sentence > to include them. [Med] No change is needed here. All these RFCs are appropriately cited in the main text. > > Original: > This YANG module uses types and groupings defined in [RFC6991], > [RFC8341], [RFC8343], [RFC8529], [RFC9640], [RFC9641], > [RFC9642], and > [RFC9645]. > > The module augments [RFC7317]. > > The module also cites [RFC6520], [RFC9257], and [RFC9258]. > --> > > > 6) <!-- [rfced] RFC 6991 has been obsoleted by RFC 9911. Would you > like to replace RFC 6991 with RFC 9911? Note RFC 6991 is mentioned > three times in the document (one time in the text introducing the > YANG module in Section 4 and twice in the module itself). > --> > [Med] Yes, please. > > 7) <!--[rfced] May we update the YANG module as shown in the > following diff file? > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Fietf-system-tacacs-plus%402026-03- > 13- > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf2af1 > 057087d4840eaa308de818cc7af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C639090638934431926%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=Y9mypa%2BhVKrlcTiVg3pFKW4JdEVz4Ln8M0 > 1rr%2B8IGXM%3D&reserved=0 [Med] OK. > > This diff file compares the current module to the output of the > formatting tool (using pyang to format the module as described on > the IETF "YANG review tools" wiki page at > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > wiki.ietf.org%2Fgroup%2Fops%2Fyang-review- > tools&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf2af1057087d > 4840eaa308de818cc7af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > 639090638934453321%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=Zm%2BqU3ku2NBwWDjehY8jSZS2KclWGPc%2FGMHW1rm > GM5U%3D&reserved=0). > > To be clear, with or without the formatting updates, the YANG > module parses. > --> > > > 8) <!-- [rfced] We note that the list of authors/editors within > the YANG module does not match the list of authors/editors for the > document (i.e., Guangying Zheng appears in list in YANG module but > is not listed as an author for the document). Please let us know > if any updates are necessary. [Med] No change is needed. > > Original: > contact > "WG Web: > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fdatatracker.ietf.org%2Fwg%2Fopsawg%2F&data=05%7C02%7Cmohamed.bouc > adair%40orange.com%7Cf2af1057087d4840eaa308de818cc7af%7C90c7a20af3 > 4b40bfbc48b9253b6f5d20%7C0%7C0%7C639090638934464093%7CUnknown%7CTW > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oz5OgQ53yE > MBfZjYYb45wDdXw3lk5aowfHOIbFowtEs%3D&reserved=0> > WG List: <mailto:[email protected]> > > Editor: Mohamed Boucadair > <mailto:[email protected]> > Author: Bo Wu > <[email protected]> > Author: Guangying Zheng > <[email protected]>"; > --> > > > 9) <!-- [rfced] This text does not parse. May we update as > follows? > > Original: > - added a constraint on the VRF with 'source-interface' > is also provided > > Perhaps: > - adds a constraint on the VRF with 'source-interface' > --> [Med] OK. > > > 10) <!-- [rfced] FYI - We updated "servers list" to "list of > servers" here for clarity. > > Original: > - requires that the servers list must be unique per > address/port number. > > Perhaps: > - requires that the list of servers must be unique per > address/port number. > --> > [Med] ACK > > 11) <!-- [rfced] May we update this description clause as follows > to improve clarity? The suggested text below is similar to > phrasing used elsewhere in the document. > > Original: > description > "Server type: authentication/authorization/accounting and > various combinations."; > > Perhaps: > description > "The server type can be authentication, authorization, > accounting, or any combination of the three types."; > --> [Med] ACK > > > 12) <!-- [rfced] Security Considerations > > a) This document informatively references [I-D.ietf-netmod- > rfc8407bis], which is currently in AUTH48 as RFC-to-be 9907. It > seems that it will be published soon, so we updated the reference > in this document to [RFC9907]. We also made a few small updates to > the Security Considerations section of this document to align with > the template as it currently appears in Section 3.7.1 of RFC-to-be > 9907. > > b) We added the following sentences before the last paragraph in > the Security Considerations section per Section 3.7.1 of RFC-to-be > 9907. Please confirm this is correct. > > Perhaps: > There are no particularly sensitive readable data nodes. > > There are no particularly sensitive RPC or action operations. > --> > [Med] ACK. > > 13) <!-- [rfced] The figures in Appendix B and Appendix C include > a note about using line wrapping per RFC 8792, but this document > does not include a reference entry for RFC 8792. May we add > something like the following to Section 2 ("Conventions and > Definitions") and a corresponding informative reference entry? > > Perhaps A (after key words paragraph in Section 2): > Some examples in this document contain long lines that are > wrapped as described in [RFC8792]. > [Med]OK. > or > Perhaps B (after Section 2.1): > 2.2. Line Wrapping > > Some examples in this document contain long lines that are > wrapped as described in [RFC8792]. > --> > > > 14) <!-- [rfced] Terminology > > a) We do not see "TACACS+TLS" in RFC 9887 or any other published > RFC. Will readers understand this term, or should it be defined in > this document? > [Med] We can use "TACACS+ over TLS" > > b) We see instances of the following. Please let us know how/if > these should be made consistent. > > user name > username > Note: RFC 7317 uses "user name", and RFC 9105 uses "username". > [Med] I would keep the same use as in 9105 > hash algorithm [Med] we can keep this one > Hash algorithm > > credential reference > credentials reference [Med] we can use this one. > > > c) Please review "domain-name" in the following description > clauses. Should these be updated to one of the following? > > 'domain-name' (single quotes and hyphen) [Med] we can use this one > domain name (no quotes and no hyphen) > > In running text and description clauses, the convention seems to > be single quotes and hyphen for the name of the leaf ('domain- > name') and and no quotes and no hyphen for general use (domain > name). > > Original: > - updates the description of the 'name' under 'server' > list to better reflect the intended use and clarifies > the difference with the new domain-name > ... > "A name that is used to uniquely identify a TACACS+ > server within the device configuration. > This name is not to be confused with the domain-name."; > > Perhaps A: > - updates the description of the 'name' under 'server' > list to better reflect the intended use and clarifies > the difference with the new 'domain-name' > ... > "A name that is used to uniquely identify a TACACS+ > server within the device configuration. > This name is not to be confused with the 'domain-name'."; > > Perhaps B: > - updates the description of the 'name' under 'server' > list to better reflect the intended use and clarifies > the difference with the new domain name > ... > "A name that is used to uniquely identify a TACACS+ > server within the device configuration. > This name is not to be confused with the domain name."; > --> > > > 15) <!-- [rfced] We see both of the following expansions for RPK > in this > document: > > Raw Public Keys (RPKs) > raw private key (RPK) > > Note that RFCs 7250, 9641, and 9887 use "Raw Public Keys (RPKs)". > However, because the YANG module in this document uses both "raw- > public-keys" and "raw-private-key", would it be best to only use > the expanded forms (and not the acronym RPK)? Or do you prefer > another solution? > --> [Med] We can use only the expanded version > > > 16) <!-- [rfced] FYI: For the figures in Section 3 and Appendix C, > we updated <artwork> to <sourcecode type="yangtree">. Please > confirm that this is correct. > --> [Med] ACK > > > 17) <!-- [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%7Cf2af1057087d4840eaa308de818c > c7af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390906389344738 > 19%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=0YBljQrAH4dXO72tmDxpy%2BY410MhDVkOUzmJloV2FlU%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 report. Thanks > > Thank you. > > Rebecca VanRheenen > RFC Production Center > > > > On Mar 13, 2026, at 10:31 PM, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2026/03/13 > > 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% > 7Cf2af1057087d4840eaa308de818cc7af%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C639090638934483935%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=N6YoJcCzbEG9l53PCFFgrazHYNvQL > i%2F9%2FeBH1rHStU8%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%7Cf2af1057087d4 > 840eaa308de818cc7af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 39090638934493395%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=65CgTM%2FrU5HbxjCAT2He0qzBmIi7DqWWipQC03fBgO > 0%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%7Cf2af105 > 7087d4840eaa308de818cc7af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639090638934503418%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=TIXorNnjoUnuTq5%2FPDHj9QWunJ%2Fd9twPAY > DUq%2BFprEY%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 > Cf2af1057087d4840eaa308de818cc7af%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C639090638934515189%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YGQXWrWV841PYnkMd58KIWbcrmGsZM > GT1sJ%2FcArE3dY%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%7Cf2af1057087d4840eaa308de818c > c7af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390906389345271 > 25%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=lhsh6jUfmQrH54AoWc5EHBBtxZVCJ61vIpO0DtLwXls%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%2Frfc9950.xml&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7Cf2af1057087d4840eaa308de818cc7af%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639090638934537343%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cEN4tdBlbpFy10 > %2FsosQSocRDqa3OK8VnwLk%2FCkROM8A%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9950.html&data=05%7C02%7Cmohamed.boucada > ir%40orange.com%7Cf2af1057087d4840eaa308de818cc7af%7C90c7a20af34b4 > 0bfbc48b9253b6f5d20%7C0%7C0%7C639090638934547477%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1%2BEvsirjsco > MMfNpBsHgCQWxveXz184YM60w%2FqvtHqg%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9950.pdf&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7Cf2af1057087d4840eaa308de818cc7af%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639090638934557550%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ELIbS5MUlKVDrv > Z2i7RLBGwVwVcWBi9Qc%2BAK8pfdZdA%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9950.txt&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7Cf2af1057087d4840eaa308de818cc7af%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639090638934567215%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oHJv7ZkE6FhSGR > DKJ3H1xRt%2BP3ici9e2BOOFZX5KAZ8%3D&reserved=0 > > Diff file of the text: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9950- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf2af1057 > 087d4840eaa308de818cc7af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C639090638934576853%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=IHIGlDkA8%2Fgls20OnyRtllaOqKxHKmzEElBST > eolZc0%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9950- > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf2af1 > 057087d4840eaa308de818cc7af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C639090638934586450%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=lGpUr2AIEuHZYwZWhgSa5pPwt%2FuJWUb4fv > j9SnO9DF4%3D&reserved=0 (side by side) > > 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%2Frfc9950-alt- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf2af1057 > 087d4840eaa308de818cc7af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C639090638934598914%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=ri%2Bt%2Fx1NeIT%2BXWwEEIXVrG0BH9l5flGwt > 6plxH3g0K4%3D&reserved=0 > > Diff of the XML: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9950- > xmldiff1.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf2af > 1057087d4840eaa308de818cc7af%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > 0%7C0%7C639090638934608869%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=Rl%2BAt1p8nMUYCj8OGPkA5o9bOUySzdWFF > 8AObOGuANk%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%2Frfc9950&data=05%7C02%7Cmohamed.boucadair%40o > range.com%7Cf2af1057087d4840eaa308de818cc7af%7C90c7a20af34b40bfbc4 > 8b9253b6f5d20%7C0%7C0%7C639090638934631867%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VeMDiNmiBjkFa3qth8Y > TSxVKE0dFyOQdNc%2FouZp8AmI%3D&reserved=0 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9950 (draft-ietf-opsawg-secure-tacacs-yang-13) > > Title : A YANG Data Model for Terminal Access > Controller Access-Control System Plus (TACACS+) > Author(s) : M. Boucadair, Ed., B. Wu > WG Chair(s) : Joe Clarke, Benoît Claise > > Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani ____________________________________________________________________________________________________________ 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]
