Hi Ted, Thank you for your reply. We have updated the document accordingly and noted your approval on the AUTH48 status page for this document (http://www.rfc-editor.org/auth48/rfc9664).
We just need Stuart's final approval, and then we can proceed with publication processing! 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 May 28, 2025, at 7:04 AM, Ted Lemon <mel...@fugue.com> wrote: > > Thanks for the update. I have two minor tweaks: > > In 4.1, OLD: > > so the term "Lease Update Request" is to specify behavior that is the > same for both types of DNS Update. > > NEW: > > so the term "Lease Update Request" is used to specify behavior that is the > same for both types of DNS Update. > > In section 6, OLD: > > When using UDP, > reliable transmission must be guaranteed by retransmitting if a DNS UDP > message is not > acknowledged in a reasonable amount of time. > > NEW: > > For communication using UDP, > reliable transmission must be guaranteed by retransmitting when a DNS UDP > message is not > acknowledged in a reasonable amount of time. > > I think the first change is very much worth doing; the second is more of a > judgment call, but I think "when" is more clear than "if" in this sentence, > so tweaking it to make that work I think makes it clearer. > > Whether you apply zero, one or both of these, this represents my sign-off on > RFC9664, and I think you already have Stuart's, so I think we're done. > >> On 23 May 2025, at 16:31, Sarah Tarrant <starr...@staff.rfc-editor.org> >> wrote: >> >> Hi Stuart, >> >> Thank you for your reply. We have updated the document accordingly. >> >> We have no further questions or comments regarding this document and will >> await Ted's final review. Note that we also await comments and approvals on >> RFC-to-be 9665. >> >> 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 May 22, 2025, at 6:43 PM, Stuart Cheshire <chesh...@apple.com> wrote: >>> >>> On Apr 28, 2025, at 13:08, 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 >>> >>> Thank you for the updated draft Sarah. I have completed my final review, >>> and I have just five very minor edits to suggest. >>> >>> 1. Duplication. These two sentences seem redundant together. Suggest >>> combining. >>> Old: >>> This OPT RR MUST include an EDNS(0) Option as shown below. >>> The Update Lease EDNS(0) option is formatted as follows: >>> New: >>> This OPT RR MUST include an Update Lease EDNS(0) Option as shown below: >>> >>> 2. Confusing wording. (Requests are formatted like Requests and Responses?) >>> Old: >>> Refresh Requests are formatted like Update Lease Requests >>> and Update Lease Responses (see Section 4). >>> New: >>> Refresh Requests and their corresponding responses >>> are formatted like Update Lease Requests >>> and Update Lease Responses (see Section 4). >>> >>> 3. Confusing duplication (The ... in a Refresh Request contains ... for >>> Requests) >>> Old: >>> The Update Lease option in a Refresh Request contains the desired >>> new lease duration for Requests, and the actual granted lease for >>> Responses. >>> New: >>> In a Refresh Request >>> the Update Lease option contains the desired new lease duration, >>> and in the corresponding response >>> the Update Lease option contains the actual granted lease. >>> >>> 4. Clarify that (as stated elsewhere in the document) a Refresh Request may >>> request any appropriate lifetime, such as the same as the initial request, >>> or from the initial reply, or any other suitable value as needed. (I added >>> “or other desired values as appropriate” at the end.) >>> Old: >>> The Update Lease option MAY either specify the same >>> durations as in the initial Registration Request or use >>> the values returned by the server in the previous Lease >>> Update Response. >>> New: >>> The Update Lease option MAY either specify the same >>> durations as in the initial Registration Request or use >>> the values returned by the server in the previous Lease >>> Update Response, or other desired values as appropriate. >>> >>> 5. Spelling: >>> successfylly >>> >>> With those changes, I think we should be finished with RFC-to-be 9664. >>> >>> I spoke with Ted this week and he should get his final review done in the >>> next few days. >>> >>> Stuart Cheshire >> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
