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= [email protected]> 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 <[email protected]> > *Date: *Tuesday, April 9, 2024 at 8:32 AM > *To: *Rick Wilhelm <[email protected]> > *Cc: *[email protected] <[email protected]> > *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 <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/regext >
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
