Hi Ted and Stuart, This is a friendly reminder that we have yet to hear back from you regarding this document’s readiness for publication.
Please review the AUTH48 status page (http://www.rfc-editor.org/auth48/rfc9664) for further information and the previous messages in this thread for pertinent communication. Thank you, RFC Editor/st > On Apr 18, 2025, at 2:41 AM, Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > > Sarah and others, > After review of the updates, I approve the document for publication. > > Regards and thanks to all > -éric > From: Sarah Tarrant <starr...@staff.rfc-editor.org> > Date: Thursday, 17 April 2025 at 23:27 > To: Ted Lemon <mel...@fugue.com>, Stuart Cheshire <chesh...@apple.com>, Eric > Vyncke (evyncke) <evyn...@cisco.com> > Cc: Chris Box <chris.box.i...@gmail.com>, dnssd-...@ietf.org > <dnssd-...@ietf.org>, dnssd-cha...@ietf.org <dnssd-cha...@ietf.org>, > auth48archive <auth48archive@rfc-editor.org>, RFC Editor > <rfc-edi...@rfc-editor.org> > Subject: Re: [AD] AUTH48: RFC-to-be 9664 <draft-ietf-dnssd-update-lease-08> > for your review > Hi Stuart, Ted, and *Éric, > > *Éric - Please review the diffs, particularly the added text, and let us know > if all updates are approved. We recommend the -auth48diff.html as it > highlights the updates that occurred since the first files posted for AUTH48. > > Stuart and Ted - Thank you for the updated XML files. This really helped, > particularly with the term updates! > > FYI - Since there were some added terms to the list in Section 2.1, we update > the title from "Abbreviations" to "Terminology". > > Other than that, we have no further questions or comments regarding this > document. > > Please review the document carefully to ensure satisfaction as we do not make > changes once it has been published as an RFC. Contact us with any further > updates or with your approval of the document in its current form. We will > await approvals from each author prior to moving forward in the publication > process. > > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9664.txt > https://www.rfc-editor.org/authors/rfc9664.pdf > https://www.rfc-editor.org/authors/rfc9664.html > https://www.rfc-editor.org/authors/rfc9664.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9664-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9664-auth48diff.html (AUTH48 changes > only) > > Note that it may be necessary for you to refresh your browser to view the > most recent version. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9664 > > Thank you, > RFC Editor/st > > > On Dec 4, 2024, at 3:14 PM, Ted Lemon <mel...@fugue.com> wrote: > > > > I have finished my work on both documents and have uploaded new versions on > > github. Stuart has some additional updates to make based on his review of > > the document, and we met to discuss his work this evening. I think he has > > some conflicts and won't be able to update until next week, but I also get > > the sense that his changes are pretty light. > > > > The RFC Editor edits were pretty heavy, and some of the questions you > > raised required broad text changes. The majority of these changes are > > purely editorial, but a few errata were caught. As a result I would not > > want to move forward without giving the WG an opportunity to review the > > changes. > > > > > > On Wed, Dec 4, 2024 at 5:12 PM Sarah Tarrant <starr...@amsl.com> wrote: > > Authors and AD, > > > > Please see mail below regarding this document as well as our cluster-wide > > email with questions relating to all three related documents. > > > > This document set has been in AUTH48 since mid-September. Please let us > > know if there is anything we can do to facilitate moving the AUTH48 review > > forward. > > > > Sincerely, > > RFC Editor/st > > > > > On Nov 22, 2024, at 2:11 PM, Sarah Tarrant <starr...@amsl.com> wrote: > > > > > > Hi all, > > > > > > This is a friendly weekly reminder that we await answers to the questions > > > below and your review of the document before continuing with the > > > publication process. > > > > > > Please let us know if we can be of further assistance as you complete > > > your review. > > > > > > Thank you, > > > RFC Editor/st > > > > > >> On Nov 14, 2024, at 2:27 PM, Sarah Tarrant <starr...@amsl.com> wrote: > > >> > > >> Hi all, > > >> > > >> This is a friendly weekly reminder that we await answers to the > > >> questions below and your review of the document before continuing with > > >> the publication process. > > >> > > >> Please let us know if we can be of further assistance as you complete > > >> your review. > > >> > > >> Thank you, > > >> RFC Editor/st > > >> > > >>> On Nov 4, 2024, at 1:46 PM, Sarah Tarrant <starr...@amsl.com> wrote: > > >>> > > >>> Hi Ted, > > >>> > > >>> Thank you for the update! > > >>> > > >>> Sincerely, > > >>> RFC Editor/st > > >>> > > >>>> On Nov 4, 2024, at 11:57 AM, Ted Lemon <mel...@fugue.com> wrote: > > >>>> > > >>>> Sarah, I've been working my way through the diffs of my previous > > >>>> review to make sure I get everything. The edit to update-lease is > > >>>> pretty heavy. Should be done with both sometime tomorrow. Sorry it's > > >>>> taking so long. > > >>>> > > >>>> On Mon, Nov 4, 2024 at 5:37 PM Sarah Tarrant <starr...@amsl.com> wrote: > > >>>> Hi all, > > >>>> > > >>>> This is a friendly reminder that we await answers to the questions > > >>>> below and your review of the document before continuing with the > > >>>> publication process. > > >>>> > > >>>> Thank you, > > >>>> RFC Editor/st > > >>>> > > >>>>> On Oct 7, 2024, at 12:39 PM, Sarah Tarrant <starr...@amsl.com> wrote: > > >>>>> > > >>>>> Authors, > > >>>>> > > >>>>> This is a friendly reminder that we await answers to the questions > > >>>>> below and your review of the document before continuing with the > > >>>>> publication process. > > >>>>> > > >>>>> Thank you, > > >>>>> RFC Editor/st > > >>>>> > > >>>>>> On Sep 30, 2024, at 10:56 PM, rfc-edi...@rfc-editor.org wrote: > > >>>>>> > > >>>>>> Authors, > > >>>>>> > > >>>>>> While reviewing this document during AUTH48, please resolve (as > > >>>>>> necessary) the following questions, which are also in the XML file. > > >>>>>> > > >>>>>> 1) <!--[rfced] We had two related questions about these sentences: > > >>>>>> > > >>>>>> a) We were unsure if some singular/plural changes should be made with > > >>>>>> regard to "Leases". See suggested text below. > > >>>>>> > > >>>>>> b) Should the use of "DNS" be made uniform? That is, "Dynamic DNS > > >>>>>> Update Leases Requests and Responses" or "Dynamic Update Leases > > >>>>>> Requests and Responses"? > > >>>>>> > > >>>>>> Original 1: > > >>>>>> > > >>>>>> Dynamic DNS Update Leases Requests and Responses are formatted as > > >>>>>> standard DNS Dynamic Update messages [RFC2136]. This update MUST > > >>>>>> include the EDNS(0) OPT RR, as described in [RFC6891]. > > >>>>>> > > >>>>>> Perhaps ("Leases" becomes "Lease" and "This update" becomes "These > > >>>>>> updates"): > > >>>>>> > > >>>>>> Dynamic DNS Update Lease Requests and Responses are formatted as > > >>>>>> standard DNS Dynamic Update messages [RFC2136]. These updates MUST > > >>>>>> include the EDNS(0) OPT RR, as described in [RFC6891]. > > >>>>>> > > >>>>>> or perhaps ("Leases" becomes "Lease" and "These updates" becomes > > >>>>>> "This > > >>>>>> new format"): > > >>>>>> > > >>>>>> Dynamic DNS Update Lease Requests and Responses are formatted as > > >>>>>> standard DNS Dynamic Update messages [RFC2136]. This new format > > >>>>>> MUST include the EDNS(0) OPT RR, as described in [RFC6891]. > > >>>>>> > > >>>>>> > > >>>>>> Original 2: > > >>>>>> > > >>>>>> Refresh messages are formatted like Dynamic Update Leases Requests > > >>>>>> and Responses... > > >>>>>> > > >>>>>> Perhaps ("Leases" becomes "Lease"): > > >>>>>> > > >>>>>> Refresh messages are formatted like Dynamic Update Lease Requests > > >>>>>> and Responses... > > >>>>>> > > >>>>>> > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> 2) <!--[rfced] Might the following update be less redundant than the > > >>>>>> original? > > >>>>>> > > >>>>>> Original: > > >>>>>> DNS Servers implementing the Update Lease option MUST include an > > >>>>>> Update Lease option in response to any successful DNS Update > > >>>>>> (RCODE=0) that includes an Update Lease option. > > >>>>>> > > >>>>>> Perhaps: > > >>>>>> DNS servers MUST include an Update Lease option in response to any > > >>>>>> successful DNS Update (RCODE=0) that also includes one. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> 3) <!--[rfced] May we update this text as follows to reduce > > >>>>>> redundancy? > > >>>>>> > > >>>>>> Original: > > >>>>>> In order to prevent records expiring, requestors MUST refresh > > >>>>>> resource records before they expire. > > >>>>>> > > >>>>>> Perhaps: > > >>>>>> In order to prevent records expiring, requestors MUST refresh > > >>>>>> them. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> 4) <!-- [rfced] We suggest the following update as BCP 14 uses > > >>>>>> "RECOMMENDED" (with the -ed ending). Please let us know any > > >>>>>> objections. > > >>>>>> > > >>>>>> Current: > > >>>>>> We RECOMMEND a minimum of 30 seconds for > > >>>>>> both the LEASE and KEY-LEASE intervals. > > >>>>>> > > >>>>>> Perhaps: > > >>>>>> A minimum of 30 seconds for both the LEASE and KEY-LEASE > > >>>>>> intervals is RECOMMENDED. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> 5) <!--[rfced] We had the following questions related to terminology > > >>>>>> used > > >>>>>> throughout the document: > > >>>>>> > > >>>>>> We see the following similar terms. Please let us know if/how they > > >>>>>> may be made uniform. > > >>>>>> > > >>>>>> (4-byte) variant vs. 4-byte variant > > >>>>>> (8-byte) variant vs. 8-byte variant > > >>>>>> > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> 6) <!-- [rfced] Please review whether any of the notes in this > > >>>>>> document > > >>>>>> should be in the <aside> element. It is defined as "a container > > >>>>>> for content that is semantically less important or tangential to > > >>>>>> the content that surrounds it" > > >>>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > > >>>>>> > > >>>>>> Specifically, we're referring to the instances of "Note:" in Section > > >>>>>> 4.2 and of "Note that" in Section 4.3. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> 7) <!-- [rfced] Please review the "Inclusive Language" portion of the > > >>>>>> online Style Guide > > >>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > >>>>>> and let us know if any changes are needed. > > >>>>>> > > >>>>>> Note that our script did not flag any words in particular, but this > > >>>>>> should still be reviewed as a best practice. > > >>>>>> --> > > >>>>>> > > >>>>>> > > >>>>>> Thank you. > > >>>>>> > > >>>>>> RFC Editor/st/mf > > >>>>>> > > >>>>>> *****IMPORTANT***** > > >>>>>> > > >>>>>> Updated 2024/09/30 > > >>>>>> > > >>>>>> 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://www.rfc-editor.org/faq/). > > >>>>>> > > >>>>>> 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://trustee.ietf.org/license-info/). > > >>>>>> > > >>>>>> * 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://authors.ietf.org/rfcxml-vocabulary>. > > >>>>>> > > >>>>>> * 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 > > >>>>>> > > >>>>>> * rfc-edi...@rfc-editor.org (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). > > >>>>>> > > >>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing > > >>>>>> list > > >>>>>> to preserve AUTH48 conversations; it is not an active discussion > > >>>>>> list: > > >>>>>> > > >>>>>> * More info: > > >>>>>> > > >>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > >>>>>> > > >>>>>> * The archive itself: > > >>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > > >>>>>> > > >>>>>> * 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, > > >>>>>> auth48archive@rfc-editor.org 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://www.rfc-editor.org/authors/rfc9664.xml > > >>>>>> https://www.rfc-editor.org/authors/rfc9664.html > > >>>>>> https://www.rfc-editor.org/authors/rfc9664.pdf > > >>>>>> https://www.rfc-editor.org/authors/rfc9664.txt > > >>>>>> > > >>>>>> Diff file of the text: > > >>>>>> https://www.rfc-editor.org/authors/rfc9664-diff.html > > >>>>>> https://www.rfc-editor.org/authors/rfc9664-rfcdiff.html (side by > > >>>>>> side) > > >>>>>> > > >>>>>> Diff of the XML: > > >>>>>> https://www.rfc-editor.org/authors/rfc9664-xmldiff1.html > > >>>>>> > > >>>>>> > > >>>>>> Tracking progress > > >>>>>> ----------------- > > >>>>>> > > >>>>>> The details of the AUTH48 status of your document are here: > > >>>>>> https://www.rfc-editor.org/auth48/rfc9664 > > >>>>>> > > >>>>>> Please let us know if you have any questions. > > >>>>>> > > >>>>>> Thank you for your cooperation, > > >>>>>> > > >>>>>> RFC Editor > > >>>>>> > > >>>>>> -------------------------------------- > > >>>>>> RFC9664 (draft-ietf-dnssd-update-lease-08) > > >>>>>> > > >>>>>> Title : An EDNS(0) option to negotiate Leases on DNS > > >>>>>> Updates > > >>>>>> Author(s) : S. Cheshire, T. Lemon > > >>>>>> WG Chair(s) : Chris Box, David Schinazi > > >>>>>> Area Director(s) : Erik Kline, Éric Vyncke > > >>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
