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 >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
