Gavin, et al, This is a mixture of nits and wording things. I had provided this privately to Gavin, he indicated it was better to just send directly to the list.
1.2.1: The <ttl:ttl> element may have the following attributes, depending on Q1: The use of the uncapitalized ‘may’ here could be confusing. Can that be capitalized? Or perhaps reworded? 3. "min", which MUST NOT be present in commands frames but MAY be and 4. "default", which MUST NOT be present in commands frames but MAY and 5. "max", which MUST NOT be present in commands frames but MAY be Q2: In all three of these, I think that “commands” should singular; as in “… in command frames” (or perhaps “…in a command frame” ??) 1.2.1.2 [RFC6895], and is intended to match any existing and future RRTYPE I think that we mean “existing or future” ? this document in the event that a new DNS record that exists above a zone cut is specified. I think that eliding the part about “exists above a zone cut” would be helpful, because someone will argue about “what is a zone cut? And why haven’t you defined it??” So perhaps: “… in the event that a new DNS record (type?) is specified.” 1.2.1.2.1 These servers MUST reject commands which attempt to set TTL values for these record types for domain objects using a 2004 "Parameter value range" error. Noting that just above this text, in 1.2.1.2, the doct uses a different form for a 2004 error code. For consistency, would suggest text of: A server which implements host objects and receives a command which attempts to set TTL values for these record types on a domain objects MUST respond with a 2004 “Parameter value range” error. 3.1 Servers MAY restrict the supported DNS record types in accordance with their own operational needs. Suggest that “needs” be replaced with the more clear and direct “policy” 3.2 EPP servers which implement this extension SHOULD use the values provided by EPP clients for the TTL values records published in the DNS for domain and and objects. Seems like this sentence should give a nod to server policy. For example, just above this text, there is text that states: If an EPP server receives an <update> command containing a TTL value that is outside the server's permitted range, it MUST reject the command with a 2306 "Parameter value policy error" response. Perhaps the sentence in 3.2 could read: EPP servers which implement this extension SHOULD use the values provided by EPP clients for the TTL values records published in the DNS for domain and and objects, if such values conform to server policy. 5.1: (this will be an odd comment, coming from me!! Domain registry operators must strike a balance between, on the one hand, the desire of registrants for changes to their domains to be visible in the DNS quickly, and on the other, the increased DNS query traffic that short TTLs can bring. While I firmly believe that the statement as written, I’m not sure if this belongs in the RFC. In the spirit of “suggest text”: I think that perhaps the statement that goes in the RFC is that: “Domain registry operators must consider the balance between, on the one hand, …” (and continue from there). That is, I think that the notion of “striking a balance” is a value judgement, but to “consider the balance” is judgement-free. Hmm!! Thanks, Rick From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on behalf of Gavin Brown <gavin.br...@icann.org<mailto:gavin.br...@icann.org>> Date: Tuesday, March 26, 2024 at 11:13 AM To: regext <regext@ietf.org<mailto:regext@ietf.org>> Cc: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> <i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>> Subject: Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-07.txt Hi all, As discussed during the meeting in Brisbane last week, this version addresses all feedback received since -06 was published. I consider this document ready for WGLC. G. > On 26 Mar 2024, at 11:11, > internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote: > > Internet-Draft draft-ietf-regext-epp-ttl-07.txt is now available. It is a work > item of the Registration Protocols Extensions (REGEXT) WG of the IETF. > > Title: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live > (TTL) values > Author: Gavin Brown > Name: draft-ietf-regext-epp-ttl-07.txt > Pages: 28 > Dates: 2024-03-26 > > Abstract: > > This document describes an extension to the Extensible Provisioning > Protocol (EPP) that allows EPP clients to manage the Time-To-Live > (TTL) value for domain name delegation records. > > About this draft > > This note is to be removed before publishing as an RFC. > > The source for this draft, and an issue tracker, may can be found at > https://urldefense.com/v3/__https://github.com/gbxyz/epp-ttl-extension__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFcj8YpYKA$<https://urldefense.com/v3/__https://github.com/gbxyz/epp-ttl-extension__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFcj8YpYKA$> > [github[.]com]. > > The IETF datatracker status page for this Internet-Draft is: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFcK0W3swA$<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFcK0W3swA$> > [datatracker[.]ietf[.]org] > > There is also an HTMLized version available at: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-07__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFenfewX_w$<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-07__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFenfewX_w$> > [datatracker[.]ietf[.]org] > > A diff from the previous version is available at: > https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-07__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFdXESIG3A$<https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-07__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFdXESIG3A$> > [author-tools[.]ietf[.]org] > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > regext mailing list > regext@ietf.org<mailto:regext@ietf.org> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFfzsmm-bg$<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!-813lRNLpVQIgZUuPkM0dQ51RIQoMqCXVWs38dXKV9LOdAO3pml7e3TF2OEwUFBdj1IomidzMeP7Flgncr651kcSwFfzsmm-bg$> > [ietf[.]org] -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org<https://www.icann.org> _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext<https://www.ietf.org/mailman/listinfo/regext> From: regext <regext-boun...@ietf.org> on behalf of internet-dra...@ietf.org <internet-dra...@ietf.org> Date: Tuesday, March 26, 2024 at 7:11 AM To: i-d-annou...@ietf.org <i-d-annou...@ietf.org> Cc: regext@ietf.org <regext@ietf.org> Subject: [EXTERNAL] [regext] I-D Action: draft-ietf-regext-epp-ttl-07.txt CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting. Internet-Draft draft-ietf-regext-epp-ttl-07.txt is now available. It is a work item of the Registration Protocols Extensions (REGEXT) WG of the IETF. Title: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values Author: Gavin Brown Name: draft-ietf-regext-epp-ttl-07.txt Pages: 28 Dates: 2024-03-26 Abstract: This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage the Time-To-Live (TTL) value for domain name delegation records. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/epp-ttl-extension<https://github.com/gbxyz/epp-ttl-extension>. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/<https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl> There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-07<https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-07> A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-07<https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-07> Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext<https://www.ietf.org/mailman/listinfo/regext>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
