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
