Re: [regext] [Ext] [EXTERNAL] I-D Action: draft-ietf-regext-epp-ttl-07.txt

[Rick Wilhelm <[e-mail]>]

Gavin, et al,

I’m good with the handlings that you describe below.

That includes the item in 3.2, I grok your point about the supplied TTL values already needing to conform to EPP server policy.

And the various rewordings (1.2.1.2 and 1.2.1.2.1) also look good.

Thanks,
Rick




From: Gavin Brown <[e-mail]>
Date: Tuesday, April 9, 2024 at 8:32 AM
To: Rick Wilhelm <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Ext] [regext] [EXTERNAL] I-D Action: draft-ietf-regext-epp-ttl-07.txt
Hi Rick, thanks for sharing your feedback, my responses are below.

> On 8 Apr 2024, at 15:52, Rick Wilhelm <Rwilhelm=[e-mail]> wrote:
>
> 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?

I will capitalize "MAY" here as suggested.

> 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” ??)

Agreed, corrected.

> 1.2.1.2
> [RFC6895], and is intended to match any existing and future RRTYPE
> I think that we mean “existing or future” ?

I've reworded this slightly to say:

"The regular expression [...] is intended to match both existing and future RRTYPE mnemonics."

I think this wording is clearer.

> 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

I've reworded this to say (continuing from the sentence above):

"This eliminates the need to update this document in the event that new DNS records that exist above a zone cut (Section 7 of [RFC9499]) see is specified."

This adds an informational reference to RFC9499 so it's clear what is meant by a zone cut.

> 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.

I've updated the wording to be consistent in both places.

> 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”

Agreed.

> 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.

I think this change is redundant, since the server already MUST reject any transform command that tries to set a TTL value outside the permitted policy; therefore there is no need for additional server logic to check if supplied TTL values conform to server policy when publishing records in the DNS, since those values will already conform to that policy. Does that make sense?

> 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!!

Agreed, I've updated the wording.

Diff here: https://github.com/gbxyz/epp-ttl-extension/commit/d25d21fc54c877bb399205bddbc45ae616ccc385<https://github.com/gbxyz/epp-ttl-extension/commit/d25d21fc54c877bb399205bddbc45ae616ccc385>

G.

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org<https://www.icann.org>