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

More for the WG/Chairs than Gavin or Rick

I think this document is ready for WGLC - are there any reasons why it
should not be?

thanks

tim

On Tue, Apr 9, 2024 at 11:23 AM Rick Wilhelm <Rwilhelm=
40PIR.org@dmarc.ietf.org> wrote:

> 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 <gavin.brown@icann.org>
> *Date: *Tuesday, April 9, 2024 at 8:32 AM
> *To: *Rick Wilhelm <Rwilhelm@PIR.org>
> *Cc: *regext@ietf.org <regext@ietf.org>
> *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=40PIR.org@dmarc.ietf.org>
> 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
>
> G.
>
> --
> Gavin Brown
> Principal Engineer, Global Domains & Strategy
> Internet Corporation for Assigned Names and Numbers (ICANN)
>
> https://www.icann.org
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>