Hi Med (and *AD), [*AD - please review and approve the addition of text to Section 3.9, the update to the example in Section 4.8, and the revisions to the template in Appendix B]
Thank you for your detailed reply and guidance! We now have things narrowed down to a few follow up questions (see questions 1-7 below). We have been through both of your emails and made updates to the file accordingly (see links below). Note that we have also recorded Andy’s approval at the AUTH48 status page (see link below). Questions: 1) You mentioned questions 16(c)ii and 16(c)iii will require updates at the wiki page: >> >> ii) Numbering and textual differences: >> >> This document: >> These YANG-based management protocols (1) have to use a secure >> transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC >> [RFC9000]) and (2) have to use mutual authentication. >> >> The wiki: >> These protocols have to use a secure transport layer (e.g., SSH >> [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to use >> mutual >> authentication. > > [Med] The wiki should be updated to use the version in the draft. > >> >> iii) Use of "reasonably": >> >> This document: >> All writable data nodes are likely to be sensitive or >> vulnerable in some network environments. >> >> The wiki: >> All writable data nodes are likely to be reasonably sensitive or >> vulnerable in some network environments. >> > > [Med] The wiki should be updated to use the version in the draft. We have noted this update on the AUTH48 status page and will verify the page matches the document prior to publication. 2) You mentioned the following regarding questions 17(a) and 17(b): >> 17) <!--[rfced] Regarding the use of code markers: >> >> a) Please consider whether you want the <CODE BEGINS> >> and <CODE ENDS> markers to be added to any snippets in this >> document >> (i.e., if you want to add markers="true" to the sourcecode >> elements). >> >> We note Section 3.2.1 contains the following, but how it should >> be applied within this document is not clear: >> Example modules are not code components. The <CODE BEGINS> >> convention MUST NOT be used for example modules. However, >> example >> modules MUST be validated (Section 3.10). >> >> b) In contrast, regarding your note (about Section 3.7.1): >> * Added code markers for the security template. >> >> Why are the code markers being used for the security >> considerations >> template? It seems odd because it is prose, not code. > > [Med] This one was requested by the trust. Please see > https://datatracker.ietf.org/meeting/116/materials/slides-116-netmod-05-security-considerations-template-for-yang-module-documents-00 > or > https://mailarchive.ietf.org/arch/msg/netmod/gBEuz3mgOuyghmeQk7T4so_ZxF8/. > >> >> c) Similarly, why are code markers used for the templates >> in Sections 4.30.3.1 and 4.30.3.2? > > [Med] For the same reasons as above. Might it be possible to update to <BEGIN TEMPLATE TEXT> and <END TEMPLATE TEXT> instead? Additionally, should the following paragraph from the TLP should be included? From https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ (which is linked to from https://datatracker.ietf.org/meeting/116/materials/slides-116-netmod-05-security-considerations-template-for-yang-module-documents-00): Section 9. Template Text a. Certain RFCs may contain text designated as “Template Text” by the inclusion of the following legend in the introduction to the RFC: “This RFC contains text intended for use as a template as designated below by the markers <BEGIN TEMPLATE TEXT> and <END TEMPLATE TEXT> or other clear designation. Such Template Text is subject to the provisions of Section 9(b) of the Trust Legal Provisions.” 3) Regarding the reply to question 28(c): >> c) We note that templates in this document use a mix of filler >> numbers >> for RFCs (e.g., RFC IIII, RFC XXXX, FFFF). We suggest updating to >> use RFC >> XXXX throughout. Please let us know any objections. > > [Med] I need to check the full text as there are cases where using XXXX does > not work. For example, > > OLD: > revision date-initial { > description > "Initial version"; version."; > reference > "RFC YYYY: <Replace With Document Title>"; > > CURRENT: > revision date-initial { > description > "Initial version"; version."; > reference > "RFC XXXX: <Replace With Document Title>"; > > XXXX is referring to the RFC that first defined the modules, while YYYY is > the RFC that defines an update. > > IIII is used per the convention in the terminology section: > > RFC IIII is used to refer to an RFC that defines an initial version > of an IANA-maintained module. > > BTW, > > OLD: "RFC YYYY: Common YANG Data Types"; > CURRENT: "RFC 6991: Common YANG Data Types"; > > Please change that one to > > NEW: "RFC 9911: Common YANG Data Types”; We did see one update in your other email to use IIII. Please review and let us know if any further changes are necessary or if we can close this query out. 4) For 28d: >> d) Please review the use of module/model when it appears without >> YANG >> and confirm that these instances appear as intended. > > [Med] Will review that separately. Please let us know if any further changes are necessary once you complete your review. 5) 28(e) and 28(f) ask about quotation around terms: >> e) We note that there may be some inconsistency in the double >> quotes >> around statement names. For example, these terms are not quoted >> at >> places in the text: >> >> import statement >> include statement >> normative reference statement >> XPath statement >> extension statement >> YANG statement >> YANG extension statement >> YANG conditional statement >> reference statement >> length statement >> module tag extension statement > > [Med] Please follow the same convention as in RFC8407 for these. Unfortunately, RFC 8407 has some inconsistencies here. A number of the items in the list above appear in both quotes and unquoted, with the latter being more prevalent. Other statement names like “description” and “revision” statement are majority quoted. Please let us know if one of the following options should be implemented: a) double quote all statement (and substatement?) names b) unquote all statement (and substatement?) names c) leave these untouched (better to match RFC 8407 than be consistent) >> NOTE 1: We have added some quotes to "revision" statement. Please >> review >> and confirm these changes. > > [Med] ACK > >> >> NOTE 2: We see that the quotes around require-instance statement >> were >> removed between RFC 8407 and this document. Please review and >> confirm >> this update is as intended. > > [Med] Can you please indicate which one? I don't see these in my diff. Please ignore - this is a misread. > >> >> NOTE 3: We sometimes see the use of YANG statement. Should these >> simply be statement? >> >> "when" statement vs. "when" YANG statement >> "must" statement vs. "must" YANG statement > > [Med] These are inherited from 8407. We can leave these as is. > >> >> f) Further, there are some similar terms that may benefit from >> quotation review. We see: >> >> when expression vs. "when" expression >> must expression vs. "must” expression [rfced] Note also that we see “when” statement and “must” statement. Should these be updated to expression? Note that we updated to use “when” and “must” (with quotes) to match the majority use in RFC 8407. >> "enumeration" data type vs. enumeration data type vs. enumeration [rfced] Use in RFC 8407 was inconsistent. We have updated to use quotes where we felt appropriate. >> typedefs >> present vs. "not present” [rfced] We have left “not present” quoted to match RFC 8407. >> anyxml vs. “anyxml” >> descendant data nodes vs. "descendant” axis [rfced] For anyxml and descendant, we have left instances of these data node names unquoted to match 8407. Note, however, we see “config false” data nodes…so RFC 8407 doesn’t seem to be consistent on quoting names of data nodes. >> user-ordered list vs. user-ordered "list" >> leaf-list vs. "leaf-list” [rfced] For the above two related to lists, we have removed the quotation marks from one sentence as other instances in RFC 8407 seemed to not use quotation marks. >> false vs. "false" >> true vs. “true” [rfced] Instance where these terms appear to be values have been quoted (which matches RFC 8407). >> "deprecated" vs. "status deprecated” [rfced] We have added quotation marks where these appears to be a setting. Please advise if any changes from simply “deprecated” to instead say “status deprecated” are desired. > [Med] Please use the same convention as in RFC8407 if possible. If not, I > have a preference for the "word" variant. Thanks. 6) We did not see a reply to questions 29(b) and 29(c). Please let us know if any action is necessary on these items: >> b) Please review the use of quotation marks (both single quotes >> and >> double quotes) with these terms; specifically, should they be >> moved to >> outside the <tt> tag? >> >> For example, we see both: >> >> <tt>"<CODE BEGINS>"</tt> tag >> >> and >> >> <tt><CODE BEGINS></tt> convention >> >> c) Please review to ensure the usage of <tt> is consistent. It >> appears that there may be varying treatment of these terms. 7) We saw your communication with IANA on January 12. Please let us know if any changes to the document are requested based on that discussion (we don’t believe so, but please confirm). Please review our updates to these files carefully as we do not make changes once the document is published as an RFC. The files have been posted here: https://www.rfc-editor.org/authors/rfc9907.txt https://www.rfc-editor.org/authors/rfc9907.pdf https://www.rfc-editor.org/authors/rfc9907.html https://www.rfc-editor.org/authors/rfc9907.xml The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9907-diff.html (comprehensive) https://www.rfc-editor.org/authors/rfc9907-rfcdiff.html (comprehensive side by side) https://www.rfc-editor.org/authors/rfc9907-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9907-auth48rfcdiff.html (AUTH48 side by side) Please contact us with any further updates/questions/comments you may have. We will await approvals from each of the parties listed on the AUTH48 status page prior to moving forward to publication. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfcxxxx Thank you. Megan Ferguson RFC Production Center > On Jan 9, 2026, at 6:33 AM, [email protected] wrote: > > Re-, > > Please find below some comments about the edited version: > > # Section 3.8.3.2/5.1 > > As we are adding a new registration to a new one, we need to also cite > RFC9890: > > OLD: > IANA is requested to register the following YANG module in the "YANG > Module Names" registry [RFC6020] within the "YANG Parameters" > registry group. > > NEW: > IANA is requested to register the following YANG module in the "YANG > Module Names" registry [RFC6020][RFC9890] within the "YANG Parameters" > registry group. > > + list RFC9890 as normative. > > + update Section 5.1 as follows: > > OLD: > IANA has registered the following YANG modules in the "YANG Module > Names" registry [RFC6020] within the "YANG Parameters" registry > group. > > NEW: > IANA has registered the following YANG modules in the "YANG Module > Names" registry [RFC6020] [RFC9890] within the "YANG Parameters" registry > group. > > > # Section 3.12 > > Some examples may be provided to illustrate malformed data instances. Such > examples are not required to be validated. > > Please make this change: > > OLD: > Examples MUST be validated (Section 3.10). > > NEW: > Examples that are meant to illustrate valid data instance MUST be validated > (Section 3.10). > > # Section 4.8 > > The original text uses YYYY which was 6991bis draft. I suggest we make this > change to mirror 9911: > > OLD: > revision 2023-01-23 { > description > "This revision adds the following new data types: > - yang:date-with-zone-offset > - yang:date-no-zone > - yang:time-with-zone-offset > - yang:time-no-zone > - yang:hours32 > - yang:minutes32 > - yang:seconds32 > - yang:centiseconds32 > - yang:milliseconds32 > - yang:microseconds32 > - yang:microseconds64 > - yang:nanoseconds32 > - yang:nanoseconds64 > - yang:language-tag > The yang-identifier definition has been aligned with YANG 1.1. > Several pattern statements have been improved."; > reference > "RFC 6991: Common YANG Data Types"; > } > > NEW: > revision 2025-12-22 { > description > "This revision adds the following new data types: > - yang:date > - yang:date-no-zone > - yang:time > - yang:time-no-zone > - yang:hours32 > - yang:minutes32 > - yang:seconds32 > - yang:centiseconds32 > - yang:milliseconds32 > - yang:microseconds32 > - yang:microseconds64 > - yang:nanoseconds32 > - yang:nanoseconds64 > - yang:language-tag > The yang-identifier definition has been aligned with YANG > 1.1, and types representing time support the representation > of leap seconds. The representation of time zone offsets > has been aligned with RFC 9557. Several description and > pattern statements have been improved."; > reference > "RFC 9911: Common YANG Data Types"; > } > > # Section 4.28 > > Please revert to the OLD as this is consistent with the terminology used out > there: > > CURRENT: > [RFC8819] specifies a method for associating tags with YANG modules. > Tags may be defined and associated at the time of module design, at > the time of implementation, or via user administrative control. > > NEW: > [RFC8819] specifies a method for associating tags with YANG modules. > Tags may be defined and associated at design time, at > implementation time, or via user administrative control. > > # Section 4.30.2 > > Address a comment we received from Dhruv about the clarity of a statement: > > OLD: > An IANA-maintained module may use the "identityref" data type (e.g., > [RFC8675]) or an enumeration data type (e.g., [RFC9108]). > > NEW: > An IANA-maintained module may use the "identityref" data type approach > (e.g., > [RFC8675]) or an enumeration data type approach (e.g., [RFC9108]). > > # Section 4.30.3 > > CURREN (2 occurrences): > description > "IPsec tunnel mode encapsulation."; > > Unless you IANA update the registry, I suggest to revert the change as that > is correct. > > FWIW, the registry > (https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib) says: > > ipsectunnelmode(19) -- IpSec tunnel mode encapsulation > > # Appendix B > > ## address a comment received from Kent + use https > > OLD: > "WG Web: <http://datatracker.ietf.org/wg/your-wg-name/> > WG List: <mailto:[email protected]> > > NEW: > "WG Web: http://datatracker.ietf.org/wg/your-wg-name > WG List: YOUR-WG-NAME <mailto:[email protected]> > > > ## instruction clarity > > OLD: > // RFC Ed.: replace XXXX with actual RFC number and remove > // this note > > // replace 'date-revision' with the module publication date > // the format is (YYYY-MM-DD) > > revision date-revision { > description > "What changed in this revision."; > reference > "RFC XXXX: <Replace With Document Title>"; > } > > // RFC Ed.: Update with the RFC number and title > // of the RFC that defined the initial version of > // the module and remove this note > > revision date-initial { > description > "Initial version"; version."; > reference > "RFC YYYY: XXXX: <Replace With Document Title>"; > } > > NEW: > // replace 'date-revision' with the module publication date > // the format is (YYYY-MM-DD) > > // RFC Ed.: replace XXXX with actual RFC number and remove > // this note > > revision date-revision { > description > "What changed in this revision."; > reference > "RFC XXXX: <Replace With Document Title>"; > } > > // Authors: Update with the RFC number and title > // of the RFC that defined the initial version of > // the module and remove this note > > revision date-initial { > description > "Initial version"; version."; > reference > "RFC IIII: <Replace With Document Title>"; > } > > # Appendix C > > I received a comment from Dhruv that the tel. number is to be checked > > CURRENT: > Tel: +1 424 254 5300 > > Should that be updated to: > > NEW: > Tel: +1 310 301 5800 > > I will re-review the full text once all the pending points are implemented. > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : [email protected] <[email protected]> >> Envoyé : vendredi 9 janvier 2026 07:40 >> À : [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 : AUTH48: RFC-to-be 9907 <draft-ietf-netmod-rfc8407bis-28> >> for your review >> >> >> *****IMPORTANT***** >> >> Updated 2026/01/08 >> >> 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% >> 7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5 >> d20%7C0%7C0%7C639035376376592486%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e >> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI >> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vasp1mXIMbsWiId49xguONMnE0Olp >> zghBlEU%2BQiVzN0%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%7C996760e600154 >> 1306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 >> 39035376376615407%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs >> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% >> 3D%7C0%7C%7C%7C&sdata=aHV8pdXYb0OZxacb2FSeFR6xQjWSGwO64t9RLC9DelY% >> 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%7C996760e >> 6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 >> C0%7C639035376376634975%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >> fQ%3D%3D%7C0%7C%7C%7C&sdata=VVd7o6uyAaANuamDQ4Nf2P8iXJIc6r%2B%2FYP >> VMpINt6zE%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 >> C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d >> 20%7C0%7C0%7C639035376376646646%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=U1J9K5shZ7K8bDDmEqK7GxxslJ9trs >> 1u6oKtOo4cai0%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%7C996760e6001541306f0b08de4f49 >> f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390353763766571 >> 41%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA >> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C >> &sdata=NvMAAEzIM9wakQaKiJ1LMU2P1h%2BNWCTPQMcGS06mL0U%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%2Frfc9907.xml&data=05%7C02%7Cmohamed.boucadai >> r%40orange.com%7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639035376376666822%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bWEgtD%2FWD7jv >> rxBYi%2FA51ONcvqDVu0kJA7nyp3BGhcI%3D&reserved=0 >> >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc- >> editor.org%2Fauthors%2Frfc9907.html&data=05%7C02%7Cmohamed.boucada >> ir%40orange.com%7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b4 >> 0bfbc48b9253b6f5d20%7C0%7C0%7C639035376376676702%7CUnknown%7CTWFpb >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lXZMVFfTKrlqk >> 8j%2BLC3fWyTvy%2BeEzaPE6HQ9BN4dL1E%3D&reserved=0 >> >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc- >> editor.org%2Fauthors%2Frfc9907.pdf&data=05%7C02%7Cmohamed.boucadai >> r%40orange.com%7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639035376376686295%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TDLXy1ifMxLudV >> fA9k1OTa2PilKpTPuxaBghT8f46ms%3D&reserved=0 >> >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc- >> editor.org%2Fauthors%2Frfc9907.txt&data=05%7C02%7Cmohamed.boucadai >> r%40orange.com%7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639035376376695228%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fdczpv1840OJBh >> bl62w7v6hnbgOzgjwVzuiknRksS8E%3D&reserved=0 >> >> Diff file of the text: >> >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc-editor.org%2Fauthors%2Frfc9907- >> diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C996760e6 >> 001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C >> 0%7C639035376376704453%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >> Q%3D%3D%7C0%7C%7C%7C&sdata=dCxO4kAnhglm6k1A7pIFNQEWzeTe9JMIv%2BIv7 >> YUjNjI%3D&reserved=0 >> >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc-editor.org%2Fauthors%2Frfc9907- >> rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C99676 >> 0e6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 >> %7C0%7C639035376376714188%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=T9T4ZyDP15ajWTytN9qPqBoANh4a5f7hCH%2 >> FVv%2Fj4eds%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%2Frfc9907- >> xmldiff1.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9967 >> 60e6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C >> 0%7C0%7C639035376376724785%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=dqrKLsR6VUjQflKcN3R5D8WUjMrtiu4dNDK >> 5j5JNa6s%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%2Frfc9907&data=05%7C02%7Cmohamed.boucadair%40o >> range.com%7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc4 >> 8b9253b6f5d20%7C0%7C0%7C639035376376734635%7CUnknown%7CTWFpbGZsb3d >> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI >> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xnRiIUjtFLyhaLEH8MD >> 4%2FG1dEMc3c%2F%2FtFkPQg5twja8%3D&reserved=0 >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC9907 (draft-ietf-netmod-rfc8407bis-28) >> >> Title : Guidelines for Authors and Reviewers of >> Documents Containing YANG Data Models >> Author(s) : A. Bierman, M. Boucadair, Ed., Q. Wu >> WG Chair(s) : Kent Watsen, Lou Berger >> 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]
