0 Hi, I'm going to send the email right now but I just want to ask it cuz they need to say anything like what specifically I just need to say
On Tue, Feb 3, 2026, 13:22 <[email protected]> wrote: > Send auth48archive mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of auth48archive digest..."Today's Topics: > > 1. Re: Document intake questions about > <draft-ietf-netconf-http-client-server-30> > (Sarah Tarrant) > 2. Re: [AD] [IANA] AUTH48: RFC-to-be 9907 > <draft-ietf-netmod-rfc8407bis-28> for your review > (Megan Ferguson) > > > > ---------- Forwarded message ---------- > From: Sarah Tarrant <[email protected]> > To: Kent Watsen <[email protected]> > Cc: [email protected], [email protected], Mahesh Jethanandani < > [email protected]>, [email protected], > [email protected] > Bcc: > Date: Tue, 3 Feb 2026 12:08:12 -0600 > Subject: [auth48] Re: Document intake questions about > <draft-ietf-netconf-http-client-server-30> > Hi Kent, > > Very good! We're just waiting on AD approval. > > In the meantime, could you answer the questions we had on the intake form? > > > 1) As there may have been multiple updates made to the document during > Last Call, > > please review the current version of the document: > > > > * Is the text in the Abstract still accurate? > > * Are the Authors' Addresses, Contributors, and Acknowledgments > > sections current? > > > > > > 2) Please share any style information that could help us with editing > your > > document. For example: > > > > * Is your document's format or its terminology based on another > document? > > If so, please provide a pointer to that document (e.g., this document's > > terminology should match DNS terminology in RFC 9499). > > * Is there a pattern of capitalization or formatting of terms? (e.g., > field names > > should have initial capitalization; parameter names should be in double > quotes; > > <tt/> should be used for token names; etc.) > > > > > > 3) Please review the entries in the References section carefully with > > the following in mind. Note that we will update as follows unless we > > hear otherwise at this time: > > > > * References to obsoleted RFCs will be updated to point to the current > > RFC on the topic in accordance with Section 4.8.6 of RFC 7322 > > (RFC Style Guide). > > > > * References to I-Ds that have been replaced by another I-D will be > > updated to point to the replacement I-D. > > > > * References to documents from other organizations that have been > > superseded will be updated to their superseding version. > > > > Note: To check for outdated RFC and I-D references, you can use > > idnits <https://author-tools.ietf.org/idnits>. You can also help the > > IETF Tools Team by testing idnits3 < > https://author-tools.ietf.org/idnits3/> > > with your document and reporting any issues to them. > > > > > > 4) Is there any text that should be handled extra cautiously? For > example, are > > there any sections that were contentious when the document was drafted? > > > > > > 5) Is there anything else that the RPC should be aware of while editing > this > > document? > > > > > > 6) This document is part of Cluster 463. > > > > * To help the reader understand the content of the cluster, is there a > > document in the cluster that should be read first? Next? If so, please > provide > > the order and we will provide RFC numbers for the documents accordingly. > > If order is not important, please let us know. > > * Is there any text that has been repeated within the cluster document > that > > should be edited in the same way (for instance, parallel introductory > text or > > Security Considerations)? > > * For more information about clusters, see > https://www.rfc-editor.org/about/clusters/ > > * For a list of all current clusters, see: > http://www.rfc-editor.org/all_clusters.php > > > Thank you, > Sarah Tarrant > RFC Production Center > > > On Feb 3, 2026, at 11:38 AM, Kent Watsen <[email protected]> wrote: > > > > Hi Sarah, > > > > Sorry for the delay! Good news, everything is sorted out now in -32. > > > > FWIW, the net-net is: > > > > - one YANG module (ietf-uri) was removed. > > - the ietf-uri contents were moved into the ietf-http-client module. > > - this update has zero impact on other/downstream/consuming modules. > > - specifically, draft-ietf-netconf-restconf-client-server is unaffected. > > > > Cheers, > > Kent > > > > > >> On Feb 2, 2026, at 3:46 PM, Sarah Tarrant < > [email protected]> wrote: > >> > >> Hi Kent, > >> > >> Just checking in to see how this draft is going. > >> > >> Sincerely, > >> Sarah Tarrant > >> RFC Production Center > >> > >>> On Jan 15, 2026, at 3:54 PM, Sarah Tarrant < > [email protected]> wrote: > >>> > >>> Hi Kent, > >>> > >>> Well, I'm sorry to hear that that has been so frustrating. > >>> > >>> Do you expect to post a version update with that previous solution? > >>> > >>> Sincerely, > >>> Sarah Tarrant > >>> RFC Production Center > >>> > >>>> On Jan 15, 2026, at 12:01 PM, Kent Watsen <[email protected]> > wrote: > >>>> > >>>> Hi Sarah, > >>>> > >>>> I'm still stuck on responses from others, but I think that I'll will > give up hope for an agreement there, and instead move the draft's solution > back to a previously agreed solution (note: all this happened in the IESG > review stage). > >>>> > >>>> FWIW, I'm miffed that all this didn't get sussed out before (e.g, > during the WGLC) :mad: > >>>> > >>>> Kent // author > >>>> > >>>> > >>>>> On Jan 12, 2026, at 4:57 PM, Sarah Tarrant < > [email protected]> wrote: > >>>>> > >>>>> Hi Kent, > >>>>> > >>>>> Just checking in on the status of the aforementioned "snafu" and a > friendly reminder that we await answers to the questions below before > continuing with the editing process for this document. > >>>>> > >>>>> Thank you, > >>>>> Sarah Tarrant > >>>>> RFC Production Center > >>>>> > >>>>>> On Jan 6, 2026, at 10:37 AM, Kent Watsen <[email protected]> > wrote: > >>>>>> > >>>>>> Dear Sarah, > >>>>>> > >>>>>> This draft hit a snafu during the IANA review. > >>>>>> > >>>>>> Worst case is that a rather large edit will be made that will > impact various sections including the Abstract and Introduction. I've > been waiting for the snafu to resolve before replying to your message > below, but it seems that the Winter Holidays slowed things down. I just > pinged some of the blocking folks, so hopefully a resolution will come soon. > >>>>>> > >>>>>> Please note that, if the "large edit" mentioned above is needed, > draft-ietf-netconf-restconf-client-server MAY be affected. I believe that > it is in the same Cluster as this draft. > >>>>>> > >>>>>> Kent // author > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Jan 5, 2026, at 10:50 AM, Sarah Tarrant < > [email protected]> wrote: > >>>>>>> > >>>>>>> Hi Author(s), > >>>>>>> > >>>>>>> This is a friendly reminder that we await answers to the questions > below before continuing with the editing process for this document. > >>>>>>> > >>>>>>> Thank you, > >>>>>>> Sarah Tarrant > >>>>>>> RFC Production Center > >>>>>>> > >>>>>>>> On Dec 19, 2025, at 4:29 PM, [email protected] wrote: > >>>>>>>> > >>>>>>>> Author(s), > >>>>>>>> > >>>>>>>> Congratulations, your document has been successfully added to the > RFC Editor queue! > >>>>>>>> The team at the RFC Production Center (RPC) is looking forward to > working with you > >>>>>>>> as your document moves forward toward publication. To help reduce > processing time > >>>>>>>> and improve editing accuracy, please respond to the questions > below. Please confer > >>>>>>>> with your coauthors (or authors of other documents if your > document is in a > >>>>>>>> cluster) as necessary prior to taking action in order to > streamline communication. > >>>>>>>> If your document has multiple authors, only one author needs to > reply to this > >>>>>>>> message. > >>>>>>>> > >>>>>>>> As you read through the rest of this email: > >>>>>>>> > >>>>>>>> * If you need/want to make updates to your document, we encourage > you to make those > >>>>>>>> changes and resubmit to the Datatracker. This allows for the easy > creation of diffs, > >>>>>>>> which facilitates review by interested parties (e.g., authors, > ADs, doc shepherds). > >>>>>>>> * If you feel no updates to the document are necessary, please > reply with any > >>>>>>>> applicable rationale/comments. > >>>>>>>> > >>>>>>>> > >>>>>>>> Please note that the RPC team will not work on your document > until we hear from you > >>>>>>>> (that is, your document will remain in AUTH state until we > receive a reply). Even > >>>>>>>> if you don't have guidance or don't feel that you need to make > any updates to the > >>>>>>>> document, you need to let us know. After we hear from you, your > document will start > >>>>>>>> moving through the queue. You will be able to review and approve > our updates > >>>>>>>> during AUTH48. > >>>>>>>> > >>>>>>>> Please feel free to contact us with any questions you may have at > >>>>>>>> [email protected]. > >>>>>>>> > >>>>>>>> Thank you! > >>>>>>>> The RPC Team > >>>>>>>> > >>>>>>>> -- > >>>>>>>> > >>>>>>>> 1) As there may have been multiple updates made to the document > during Last Call, > >>>>>>>> please review the current version of the document: > >>>>>>>> > >>>>>>>> * Is the text in the Abstract still accurate? > >>>>>>>> * Are the Authors' Addresses, Contributors, and Acknowledgments > >>>>>>>> sections current? > >>>>>>>> > >>>>>>>> > >>>>>>>> 2) Please share any style information that could help us with > editing your > >>>>>>>> document. For example: > >>>>>>>> > >>>>>>>> * Is your document's format or its terminology based on another > document? > >>>>>>>> If so, please provide a pointer to that document (e.g., this > document's > >>>>>>>> terminology should match DNS terminology in RFC 9499). > >>>>>>>> * Is there a pattern of capitalization or formatting of terms? > (e.g., field names > >>>>>>>> should have initial capitalization; parameter names should be in > double quotes; > >>>>>>>> <tt/> should be used for token names; etc.) > >>>>>>>> > >>>>>>>> > >>>>>>>> 3) Please review the entries in the References section carefully > with > >>>>>>>> the following in mind. Note that we will update as follows unless > we > >>>>>>>> hear otherwise at this time: > >>>>>>>> > >>>>>>>> * References to obsoleted RFCs will be updated to point to the > current > >>>>>>>> RFC on the topic in accordance with Section 4.8.6 of RFC 7322 > >>>>>>>> (RFC Style Guide). > >>>>>>>> > >>>>>>>> * References to I-Ds that have been replaced by another I-D will > be > >>>>>>>> updated to point to the replacement I-D. > >>>>>>>> > >>>>>>>> * References to documents from other organizations that have been > >>>>>>>> superseded will be updated to their superseding version. > >>>>>>>> > >>>>>>>> Note: To check for outdated RFC and I-D references, you can use > >>>>>>>> idnits <https://author-tools.ietf.org/idnits>. You can also help > the > >>>>>>>> IETF Tools Team by testing idnits3 < > https://author-tools.ietf.org/idnits3/> > >>>>>>>> with your document and reporting any issues to them. > >>>>>>>> > >>>>>>>> > >>>>>>>> 4) Is there any text that should be handled extra cautiously? For > example, are > >>>>>>>> there any sections that were contentious when the document was > drafted? > >>>>>>>> > >>>>>>>> > >>>>>>>> 5) Is there anything else that the RPC should be aware of while > editing this > >>>>>>>> document? > >>>>>>>> > >>>>>>>> > >>>>>>>> 6) This document is part of Cluster 463. > >>>>>>>> > >>>>>>>> * To help the reader understand the content of the cluster, is > there a > >>>>>>>> document in the cluster that should be read first? Next? If so, > please provide > >>>>>>>> the order and we will provide RFC numbers for the documents > accordingly. > >>>>>>>> If order is not important, please let us know. > >>>>>>>> * Is there any text that has been repeated within the cluster > document that > >>>>>>>> should be edited in the same way (for instance, parallel > introductory text or > >>>>>>>> Security Considerations)? > >>>>>>>> * For more information about clusters, see > https://www.rfc-editor.org/about/clusters/ > >>>>>>>> * For a list of all current clusters, see: > http://www.rfc-editor.org/all_clusters.php > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > > > > ---------- Forwarded message ---------- > From: Megan Ferguson <[email protected]> > To: "<[email protected]>" <[email protected]>, " > [email protected]" <[email protected]>, "[email protected]" < > [email protected]> > Cc: "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>, " > [email protected]" <[email protected]>, " > [email protected]" <[email protected]> > Bcc: > Date: Tue, 3 Feb 2026 11:22:38 -0700 > Subject: [auth48] Re: [AD] [IANA] AUTH48: RFC-to-be 9907 > <draft-ietf-netmod-rfc8407bis-28> for your review > Med, IANA (Amanda), and *Mahesh, > > Thank you for your careful reviews and replies. We have incorporated the > changes submitted by Med (on 2 Feb). We have some further queries based on > the reply from Mahesh below: > > *Mahesh - Thank you for raising the three issues. > > 1) We believe the items you highlighted from the diff between the document > template and the text in the wiki ( > https://wiki.ietf.org/group/ops/yang-security-guidelines?) require no > change to the document (i.e., the document uses RFC 9907 while the wiki > page uses [RFCAAAA]). The wiki will need to be updated upon the > publication of the document with the RFC number. > > 2) Section 4.30.3: Thank you for pointing out the missing sentence! And > apologies - we don’t think we understood the update the first time around. > We have now incorporated the missing sentence into the document as we > *believe* was intended. A related note below: > > **AUTHORS** please review this update as well as the list formation > (indentation) we created (we believe this was a new list, not a further > embedded list). Having it appear this way may clear Mahesh’s concern about > the MAY/SHALL switch(?). If this does not appear as desired, please let us > know how to update. If we have it right currently, please let Mahesh know > to re-review how it now appears. > > 3) Section 4.30.3.1: We will await further guidance from the authors on > what updates are needed to address Mahesh’s comments. (Please also see > related mail from Amanda dated 3 February.) > > The files have been posted here (please refresh): > 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 related diff files have been posted here (please refresh): > 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 to date) > https://www.rfc-editor.org/authors/rfc9907-auth48rfcdiff.html (AUTH48 > changes side by side) > https://www.rfc-editor.org/authors/rfc9907-lastdiff.html (last version > to this) > https://www.rfc-editor.org/authors/rfc9907-lastrfcdiff.html (last > version side by side) > > The AUTH48 status page is viewable here: > https://www.rfc-editor.org/auth48/rfc9907 > > Thank you. > > Megan Ferguson > RFC Production Center > > > On Feb 2, 2026, at 1:25 AM, [email protected] wrote: > > > > Hi Megan, all, > > > > Thank you for sharing this updated version. Please find below some few > comments: > > > > # Section 3.9: delete an extra } > > > > OLD: > > } > > > > 3.10. Validation Tools > > > > NEW: > > > > 3.10. Validation Tools > > > > # Section 3.10/3.11 > > > > There is inconsistency formatting about how tools are listed, e.g., > 'pyang' vs "yanglint" > > > > Please change "yangson" / "yanglint" to 'yangson' / 'yanglint' to adhere > to the formatting used in 8407. > > > > # Please revert back these changes through the document > > > > "definition" statement > > "definition" statements > > > > to > > > > definition statement > > definition statements > > > > # Section 4.20: revert this change > > > > OLD: "yang-data" "extension" statement > > > > NEW: OLD: "yang-data" extension statement > > > > Assuming these changes are implemented, I approve the publication of the > document. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Megan Ferguson <[email protected]> > >> Envoyé : vendredi 30 janvier 2026 19:53 > >> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > >> [email protected]; [email protected] > >> Cc : [email protected]; [email protected]; > >> [email protected]; [email protected]; [email protected]; > >> [email protected]; [email protected] > >> Objet : Re: [AD] [IANA] AUTH48: RFC-to-be 9907 <draft-ietf-netmod- > >> rfc8407bis-28> for your review > >> > >> > >> Hi Med and Amanda (and *Mahesh), > >> > >> [*Mahesh - please see our mail sent 26 January regarding AD > >> actions.] > >> > >> We have updated per your replies. We believe Med's reply > >> addressed all of our concerns from our previous mail (and have > >> recorded this fact in the notes on the AUTH48 status page linked > >> below). We will await AD approval from our previous message prior > >> to moving forward in the publication process. > >> > >> Please review carefully and let us know if any further changes are > >> necessary. > >> > >> The files have been posted here (please refresh): > >> > >> 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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C639053960376312830%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=710lW0XndgdlI% > >> 2BBItFNd5u6bisZ9CHx5qghBXRgoqCQ%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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C639053960376328445%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NkAiahW2SxHO6m > >> Go4A%2BsnGAll6GD7X0ePWcDzd5ybAA%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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b4 > >> 0bfbc48b9253b6f5d20%7C0%7C0%7C639053960376338773%7CUnknown%7CTWFpb > >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WAvJmWP6%2BO% > >> 2B5SsImir0GOKtoLOhblRkt%2FO6ohgy1wSA%3D&reserved=0 > >> > >> 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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C639053960376349659%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mkL3bP6y7%2B77 > >> sPNFNO67VMEQjwXHVqX%2BbseU7U4YruU%3D&reserved=0 > >> > >> The related diff files have been posted here (please refresh): > >> > >> 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%7C89f3cbb6 > >> ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > >> 0%7C639053960376361497%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > >> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> Q%3D%3D%7C0%7C%7C%7C&sdata=ndhXp3NTOHpjlFiw67Ve7j3hxybXvjYn2jicwvY > >> HpB8%3D&reserved=0 (comprehensive) > >> > >> 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%7C89f3c > >> bb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > >> %7C0%7C639053960376371900%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=jOvxPNle7NwCMFbmY%2F0x%2BXG6JV1wo8%2 > >> FY6jiwjZ70lcw%3D&reserved=0 (comprehensive side by side) > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9907- > >> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C89 > >> f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20% > >> 7C0%7C0%7C639053960376381941%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > >> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > >> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i7AoqZ8laUd6EabYkxxGhUOXFOECX1rMq > >> UXa%2BP8tfKU%3D&reserved=0 (AUTH48 changes to date) > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9907- > >> auth48rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > >> C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d > >> 20%7C0%7C0%7C639053960376393254%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > >> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1cVek6Dw493S7KJsGsP0GB%2BOjAzF > >> wevZMIG3UbqIIEg%3D&reserved=0 (AUTH48 changes side by side) > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9907- > >> lastdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C89f3 > >> cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > >> 0%7C0%7C639053960376403391%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > >> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > >> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=VHf%2FDriIH5ZGFlTuLz0J3dVX%2B00qheC > >> mcIIQ%2Br24yPY%3D&reserved=0 (last version to this) > >> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9907- > >> lastrfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8 > >> 9f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20 > >> %7C0%7C0%7C639053960376416862%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h > >> cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > >> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SUNBh1KUX1%2FeCUc89rMsXI4IQLC%2B > >> DMRRkYZvSAv2STM%3D&reserved=0 (last version side by side) > >> > >> The AUTH48 status page is available 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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc4 > >> 8b9253b6f5d20%7C0%7C0%7C639053960376427203%7CUnknown%7CTWFpbGZsb3d > >> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > >> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZTEo89BuVx3GXcApule > >> T05DuMJu1PexgBme6TtGrZOE%3D&reserved=0 > >> > >> Thank you. > >> > >> Megan Ferguson > >> RFC Production Center > >> > >> > >> > >>> On Jan 27, 2026, at 12:08 AM, [email protected] > >> wrote: > >>> > >>> Hi Megan, all, > >>> > >>> Please see inline. > >>> > >>> Cheers, > >>> Med > >>> > >>> PS: I'm currently travelling so I don't have enough flexibility > >> to review more than what is requested below. > >>> > >>> De : Megan Ferguson <[email protected]> Envoyé : > >> lundi 26 > >>> janvier 2026 21:13 À : BOUCADAIR Mohamed INNOV/NET > >>> <[email protected]>; [email protected] Cc : > >>> [email protected]; [email protected]; > >> [email protected]; > >>> [email protected]; [email protected]; > >> [email protected]; > >>> [email protected]; [email protected] Objet : Re: [AD] > >> [IANA] > >>> AUTH48: RFC-to-be 9907 <draft-ietf-netmod-rfc8407bis-28> for > >> your > >>> review > >>> > >>> > >>> > >>> Hi Med, *Mahesh, (and IANA), > >>> > >>> Thanks for your careful reviews and replies. > >>> > >>> This message addresses mail from Mahesh, Med, and IANA (the > >> changes requested by Amanda on 22 January). For your convenience, > >> we have included links to the current versions of files in > >> multiple places in this mail (but all point to the same files). > >>> > >>> Please review all updates carefully and let us know if further > >> changes are necessary. We will await approvals from all parties > >> (and of all actions) listed at the AUTH48 status page > >> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > >> Fwww.rfc- > >> editor.org%2Fauth48%2Frfc9907&data=05%7C02%7Cmohamed.boucadair%40o > >> range.com%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc4 > >> 8b9253b6f5d20%7C0%7C0%7C639053960376438218%7CUnknown%7CTWFpbGZsb3d > >> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > >> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=p%2BplcwHwFWRMMPRNM > >> fof3sI6ZviDZfRbbGehUEUxSh4%3D&reserved=0) prior to moving this > >> document forward in the publication process. > >>> > >>> > >>> > >>> Addressing Mahesh's reply (and necessary actions): > >>> ------------------------------------------------- > >>> *Mahesh - the addition of text to Section 3.9 can be viewed in > >> the diff files here: > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9907- > >> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C89 > >> f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20% > >> 7C0%7C0%7C639053960376448071%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > >> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > >> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9rr6AYNWOJmMuF8v9CDGSktIutKroBQMl > >> %2BITbzk5fng%3D&reserved=0 (AUTH48 changes only) > >>> > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www. > >>> rfc-editor.org%2Fauthors%2Frfc9907- > >> auth48rfcdiff.html&data=05%7C02%7Cm > >>> > >> ohamed.boucadair%40orange.com%7C89f3cbb6ffca48df781a08de6030d7d2%7 > >> C90c > >>> > >> 7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639053960376457593%7CUnkno > >> wn%7 > >>> > >> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > >> W4zM > >>> > >> iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Y3hCUjt0NHa > >> R1Ce > >>> uc8mrsOXESgJ5FFnzOYop8j0g8n8%3D&reserved=0 (AUTH48 side by side) > >>> > >>> We have also attached a screenshot of the piece in question for > >> your convenience. > >>> > >>> <image001.png> > >>> > >>> With regard to the possible updates to the wiki page at > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> wiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > >> guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C89f3cbb > >> 6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > >> C0%7C639053960376466844%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > >> fQ%3D%3D%7C0%7C%7C%7C&sdata=azZAHPx14GAycwgLw5elkkt%2BDp0uGQ1%2FKz > >> vjDJijfIg%3D&reserved=0?, we have also posted a diff file to > >> highlight the current differences between the document (template) > >> and the wiki at: > >>> > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www. > >>> rfc-editor.org%2Fauthors%2Frfc9907-wiki- > >> diff.html&data=05%7C02%7Cmoham > >>> > >> ed.boucadair%40orange.com%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c > >> 7a20 > >>> > >> af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639053960376476582%7CUnknown%7 > >> CTWF > >>> > >> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM > >> iIsI > >>> > >> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5naUX14Gm8NSVQW > >> BkdB > >>> 6hZdbTRm5lFv%2BP3D5JHFa0o4%3D&reserved=0 > >>> > >>> Some of the differences highlighted are expected and will likely > >> remain (e.g., having an RFC number in brackets or marking with a > >> double dash in the RFC itself vs. colored boxes), but there are > >> some textual differences remaining that we believe should be > >> resolved. > >>> > >>> > >>> Regarding this comment from Mahesh: > >>> OLD: > >>> "WG Web: > >> <https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2F > >> datatracker.ietf.org%2Fwg%2Fyour-wg- > >> name%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C89f3cbb6ff > >> ca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > >> 7C639053960376486772%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > >> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > >> 3D%3D%7C0%7C%7C%7C&sdata=oS%2BoSXXFbgoTigBEYm6aOCPM3%2BdDHRXXIHyra > >> YmcwY4%3D&reserved=0> > >>> WG List: <mailto:[email protected]> > >>> > >>> NEW: > >>> "WG Web: > >> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fd > >> atatracker.ietf.org%2Fwg%2Fyour-wg- > >> name&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C89f3cbb6ffca4 > >> 8df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > >> 39053960376495936%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > >> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > >> 3D%7C0%7C%7C%7C&sdata=6E1OYdT%2FPg%2FIyjOV%2BusBzouCh2lPEijEjI5hW8 > >> gUL2k%3D&reserved=0 > >>> WG List: YOUR-WG-NAME <mailto:[email protected]> > >>> > >>> Shouldn't http be changed to https above? > >>> > >>> [rfced] We have updated as suggested. Calling out here for > >> author awareness. > >>> > >>> > >>> For the update to the instructions below: > >>> > >>> 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>"; > >>> } > >>> > >>> > >>> Please review our update to this text and let us know if any > >> further changes are necessary. > >>> > >>> *Mahesh - please also review and approve the following updates > >> we have received in the meantime: > >>> > >>> -the addition of text to the end of the Introduction > >>> > >>> -the updates captured in the "Addressing the mail exchange with > >> IANA" part of this email below (the updates suggested by IANA as > >> well as our updates to it) - this includes changes to Sections > >> 4.30.3 (added text), 4.30.3.1 (added and changed text), 4.30.3.2 > >> (added and changed text), 5.3 (and the reorganization/addition of > >> Sections 5.3.1 and 5.3.1). > >>> > >>> The above are reviewable in the files below: > >>> > >>> The files have been posted here (please refresh): > >>> > >> 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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C639053960376505953%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ABIjlS%2F8zher > >> WGMZFifYvOHG2Vba1To5mulZNIcsZF0%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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C639053960376516107%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=krK2doIOas100% > >> 2Fn3Jm%2F5X71pJUtaGMtcupBNfRR7QYU%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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b4 > >> 0bfbc48b9253b6f5d20%7C0%7C0%7C639053960376525956%7CUnknown%7CTWFpb > >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Yrjfc2MjIoImD > >> 54K5yuCMtJasrU288EZxh3ENrs6PwM%3D&reserved=0 > >>> > >>> > >> 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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40 > >> bfbc > >>> > >> 48b9253b6f5d20%7C0%7C0%7C639053960376536234%7CUnknown%7CTWFpbGZsb3 > >> d8ey > >>> > >> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > >> TWFp > >>> > >> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RN4ldiectbHluhTxuK6CPu%2Bq > >> tQS7 > >>> 9O%2BfiNRSj1PuRoE%3D&reserved=0 > >>> > >>> The related diff files have been posted here (please refresh): > >>> > >> 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%7C89f3cbb6 > >> ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > >> 0%7C639053960376546200%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > >> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> Q%3D%3D%7C0%7C%7C%7C&sdata=3oUGoVW0Z4F2z4mv3WMelYTo5jxccrqVaC0LjkL > >> Sd%2F0%3D&reserved=0 (comprehensive) > >>> > >> 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%7C89f3c > >> bb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > >> %7C0%7C639053960376555860%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=VjpyHqxuFNT3gLt4fy0nVU1re9szbwyQw%2B > >> sOOxQ4v%2BY%3D&reserved=0 (comprehensive side by side) > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9907- > >> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C89 > >> f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20% > >> 7C0%7C0%7C639053960376566385%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > >> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > >> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VDISHGNIk%2BPSX%2F%2BcO7OaDzB2Osu > >> nt0iIA40FQP%2FTFF0%3D&reserved=0 (AUTH48 changes to date) > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9907- > >> auth48rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > >> C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d > >> 20%7C0%7C0%7C639053960376581854%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > >> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=06MvJ8y%2Fx8%2Fdz7KYOAFMMPbEdv > >> ZkHupl27kI7bo%2B6Pk%3D&reserved=0 (AUTH48 changes side by side) > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www.rfc-editor.org%2Fauthors%2Frfc9907- > >> lastdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C89f3 > >> cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > >> 0%7C0%7C639053960376595837%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > >> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > >> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=K1Kqo8nVkMjp8xcpvfCanSBq1oXfj1PJaet > >> aLMtYcP0%3D&reserved=0 (last version to this) > >>> > >>> > >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> www. > >>> rfc-editor.org%2Fauthors%2Frfc9907- > >> lastrfcdiff.html&data=05%7C02%7Cmoh > >>> > >> amed.boucadair%40orange.com%7C89f3cbb6ffca48df781a08de6030d7d2%7C9 > >> 0c7a > >>> > >> 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639053960376609138%7CUnknown > >> %7CT > >>> > >> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4 > >> zMiI > >>> > >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dbjLi7Jr4p15q > >> IXhS > >>> vcG%2Faz1b1v5dXMBa8ygNOs5qBo%3D&reserved=0 (last version side by > >> side) > >>> > >>> > >>> Addressing Med's mail (all resolved issues snipped): > >>> --------------------------------------------------- > >>> > >>> On Jan 16, 2026, at 12:43 AM, [email protected] > >> wrote: > >>> > >>> > >>> > >>> 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. > >>> > >>> [Med] We can update all "model" occurrences in the bullet list > >> of 4.23.3 to "module". > >>> > >>> Also, make a similar change in 4.23.3.1 for two occurrences. > >>> [rfced] Please note that we also updated an instance before the > >> bulleted list in Section 4.23.3. Please review and let us know if > >> this change should be reverted. > >>> [Med] ACK > >>> > >>> > >>> 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 > >>> > >>> [Med] We can double quote all statements for internal > >> consistency then and also with RFC7950. > >>> > >>> Here is my proposal: > >>> > >>> "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 > >>> > >>> [rfced] In implementing these suggestions, we had these follow > >> up queries: > >>> > >>> -Should anydata be quoted here? > >>> "Added anydata to the list of statements with mandatory". > >>> [Med] Yes, please. > >>> > >>> -Should any quotes be added here? > >>> "YANG module namespace statement" (see also namespace statement > >> without YANG module before). > >>> [Med] This should be changed to "YANG module "namespace" > >> statement" to be consistent with 7950. All similar namespace > >> statements should be changed (except for templates). > >>> > >>> -Should "definition" be double-quoted in the following or other > >> instances of "data definition statement"? > >>> "...all top-level data definition statements." > >>> [Med] No. Please revert these changes. > >>> Also, please revert "ordered list or leaf-list" to "ordered > >> "list" or "leaf-list"" (Section 4.6.2). > >>> > >>> -We see this use of "extensions statement"; should double quotes > >> be used? > >>> ".or a "nacm:default-deny-all" extensions statement, then > >> those." > >>> [Med] We can leave this one unchanged as this will overload the > >> template. > >>> > >>> -We assume these should not be single-quoted in the YANG > >> example, please confirm. > >>> "Several description and pattern statements have been > >> improved.";" > >>> Pattern statements; range statement; max-elements statement; > >> list statement; YANG constraint statments, and YANG deviation > >> statement? > >>> [Med] I confirm. > >>> > >>> -Please advise on how quoting should appear in the following > >> titles (i.e., should any of these be double quoted as well?): > >>> 4.8. Module Header, Meta, and Revision Statement (quotes only > >> on > >>> Revision, correct?) 4.19.1. Conditional Augment Statements > >> 4.19.2. > >>> Conditionally Mandatory Data Definition Statements 4.20. > >> Deviation > >>> Statements 4.21. Extension Statements [Med] We can leave these > >>> unchanges. > >>> > >>> -We added quotes to "extension" statement, but that makes for > >> back-to-back quotes as seen in this example (see Section 4.29 for > >> more examples): > >>> "...the use of the "structure" "extension" statement..." > >>> [Med] For those we can use ""structure" extension" to be > >> consistent with rfc8791. > >>> > >>> > >>> 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? > >>> > >>> [Med] statement is actually more compliant with RFC7950. > >>> > >>> [rfced] We have updated from "expression" to "statement" per > >> this guidance. Please review and let us know if this is in error. > >>> [Med] ACK > >>> > >>> "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] The 2 uses in the doc are OK. However, when re-reading: > >>> > >>> CURRENT: > >>> The "/interfaces-state" hierarchy has > >>> been marked "status deprecated". Models that mark their > >> "/foo- > >>> state" hierarchy with "status deprecated" will allow > >> NMDA- > >>> > >>> I wonder whether: > >>> > >>> OLD: been marked "status deprecated". > >>> > >>> NEW: been marked with "status deprecated". > >>> [rfced] We have made this update as requested. As this was > >> marked "I wonder", please confirm this appears as desired. > >>> [Med] OK > >>> > >>> 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. > >>> > >>> > >>> [Med] Please use a consistent approach for all similar matters. > >>> [rfced] We have updated to include double quotes outside the > >> <tt> tags for CODE BEGINS and CODE ENDS throughout. We have added > >> <tt> tags and quotation marks around BEGIN TEMPLATE TEXT and END > >> TEMPLATE TEXT as well. Please let us know any objections. > >>> > >>> The above updates (and all the updates related Med's mail are > >> reviewable in the most recent postings, again, those are viewable > >> at: > >>> > >>> The files have been posted here (please refresh): > >>> > >> 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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C639053960376622632%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PI3CT%2B9k0DXw > >> D1fcrxwwqqsun1cZgcv3iLH%2Fg15RabE%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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40 > >> bfbc48b9253b6f5d20%7C0%7C0%7C639053960376636194%7CUnknown%7CTWFpbG > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S0MNrQiC6vqlm3 > >> IpAJ6%2BxEtf5%2FYT6vyB8ySeTyUz8is%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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b4 > >> 0bfbc48b9253b6f5d20%7C0%7C0%7C639053960376649995%7CUnknown%7CTWFpb > >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MSzqm8%2B8BkG > >> 4Ok60MqV4C%2BDBF0F6V2%2F5hQzOJTnddcs%3D&reserved=0 > >>> > >>> > >> 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%7C89f3cbb6ffca48df781a08de6030d7d2%7C90c7a20af34b40 > >> bfbc > >>> > >> 48b9253b6f5d20%7C0%7C0%7C639053960376663410%7CUnknown%7CTWFpbGZsb3 > >> d8ey > >>> > >> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > >> TWFp > >>> > >> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DCtyhCwB4oZGt1qoK9gBzUaSXT > >> I4cr > >>> 8WxWa7OzHKcj0%3D&reserved=0 > >>> > >>> The related diff files have been posted here (please refresh): > >>> > >> 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%7C89f3cbb6 > >> ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > >> 0%7C639053960376676817%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > >> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> Q%3D%3D%7C0%7C%7C%7C&sdata=NR18f8p9v4HA3HYxFIswBwpkCo90hHQZmEnKXq8 > >> eME0%3D&reserved=0 (comprehensive) > >>> > >> 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%7C89f3c > >> bb6ffca48df781a08de6030d7d2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > >> %7C0%7C639053960376690389%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=PxlJLhCsKvMpnTFQ0iFbt4F3ia%2F5XQrHXy > >> AWrb14LOM%3D&reserved=0 (comprehensive side by side) > >>> > >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F>
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
