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 Apr 28, 2025, at 3:08 PM, Sarah Tarrant <starr...@staff.rfc-editor.org> > wrote: > > 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
