Hi Megan, > On Jan 15, 2026, at 6:43 PM, Megan Ferguson <[email protected]> > wrote: > > 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]
Can you help me by identifying what text in Section 3.9 has been added. I am not able to find by doing a search for “3.9” or “Reference Sections”, the name of the section. > > 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. I believe the wiki already refects this change? Where are you seeing this difference? >> >>> >>> 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. I just updated the wiki to reflect this. > > > 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"; >> } The OLD is from RFC 6991 not 6991bis, and maybe why you are seeing the difference, but regardless, I agree that we should use the revision statement from RFC 9911. >> >> # 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]> Shouldn’t http be changed to https above? >> >> >> ## 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>"; >> } NEW1: // RFC Ed: replace 'date-revision' with the module publication date <— Moved “RFC Ed: here // the format is (YYYY-MM-DD) // 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: Replace RFC IIIII with the RFC number and title. <— Made the text similar to the note to the RFC Editor. // 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>"; } Thanks >> >> # 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. >> > Mahesh Jethanandani [email protected]
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
