Wes, Thanks for your review, I believe Gavin has addressed your comments, however he has also asked you some questions.
Please let me know if you have further comments, I am preparing ballot text for this document. Regards, OS, ART AD On Mon, Sep 2, 2024 at 9:57 AM Gavin Brown <gavin.br...@icann.org> wrote: > Hi Wes, apologies for the delay, I was on PTO. My responses below. > > > On 15 Aug 2024, at 01:18, Wes Hardaker via Datatracker <nore...@ietf.org> > wrote: > > > > Reviewer: Wes Hardaker > > Review result: Has Nits > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > A note about my background: I'm very familiar with the DNS, moderately > > with EPP concepts, and not an expert on XML. > > > > The summary of the review is: ready with a few minor comments/nits > > > > Over all: well written, clear and easy to read document. Thank you. > > > > The biggest issue: > > > > - Did the WG discuss whether or not a client should be able to check > > generally how long a server will make use of a new TTL value? It's > > clear that the server can change it at any point, but that makes it > > very hard for a client to actually manage their records in a way > > where the TTL change point can be ideally depended upon. If I'm > > rolling a key and desire a 4 hour TTL in order to do so properly, > > but the server decides to switch back to a longer one 2 hours later > > that's a real problem and will cause large issues operationally. > > That was not discussed explicitly. The document describes a policy > discovery mechanism (see Section 2.1.1.2) which allows clients to learnt > the min/default/max values, but it does not provide a way to discover > if/when a server might reset a non-default value. > > EPP would not be particularly well-suited to provide this information, as > the audience for such information would be much wider than just EPP client > operators. However, the RDAP extension (see draft-brown-rdap-ttl-extension, > which I plan to bring to regext once this document is published) does > provide a way for a registry to publish its policy in a way that is > discoverable for all interested parties, not just those who can connect to > its EPP server. > > > Furthermore, what if the policy changes after a client has set their > > value. So if I set it to 4 hours because the policy is 30 minutes > > to 12 hours and then shortly after I set my TTL the server decides > > the new minimum value is 24 hours, what happens? > > The document does not address this and therefore it would be up to the > server operator to decide. They might decide to clobber the client-assigned > value, or honour it temporarily or permanently. > > Policy changes will almost certainly only happen infrequently, and the > omission was intentional on my point. Do you feel it warrants some > discussion in the document? > > > Comments and Nits: > > > > - the introduction could use a few more words describing that this > > document really only is applying to parent/child relationships. > > EPP is only ever used in that specific context. To add clarity, I will > change "domain name provisioning system" in the first sentence of the > introduction to "domain name registry system" to avoid any confusion. > > > - In the bottom of 1.1 there is a discussion about the ttl prefix > > being used in examples. It would add some clarity to specifically > > talk about the name space reference that the string should actually > > point to, like the rest of the examples already do. > > The text in this section is boilerplate that is present in almost all > EPP-related RFCs, going back to RFC 3730. > > > - Section 1.2.1 says that elements MAY have the following > > attributes.... but the reality is that the following list contains a > > bunch of REQUIRED, MUST, MUST NOT and MAY requirements. I'd argue > > this MAY should actually be dropped and left to each of the > > sub-bullets for exactness instead. Something like "the following > > attributes, depending on whether it appears in a command or response > > frame, can appear:" > > I will downgrade the "MAY" to "may". > > > - I note that there is no generic statement about what to do when any > > required elements are missing. Specifically, servers should always > > return "2306 Parameter value policy" error when any required field > > is missing or invalid. This should probably be added in section 3 > > generically, where the rest of the section may be specifically > > stating specific cases but should otherwise be used as a generic > > error message. > > RFC 5730 provides the 2003 "Required parameter missing" error code. > > > - It's unclear if the min parameter is allowed to equal to the max > > parameter. It's clearly stated that default can be equal to min and > > max, but it would be nice to state clearly that min can, in fact, be > > equal to max as well. > > If a server policy set min=max, then only that value could ever be > specified, and this extension would serve no function. > > > - In 1.2.1.1 there is no upper bound on the TTL value, which surprises > > me. I think it should match the DNS spec and I think it's indicated > > it might be in the XML requirements (I didn't check). > > The schema sets the maximum. > > > - In general it seems that the common terminology of > > "registry/registrar/registrant" is avoided (which is fine by me) but > > there are a few instances (eg 1.2.1.2 bullet #3). I may be > > misreading the intention to shy away from this terminology though. > > I'll change "registry" to "server". > > > - I'd suggest moving the examples in 1.2.1.3 after the 1.3 section > > since the examples include a info reference (in 1.2.1.3.2). > > That makes sense, will do. > > > - I'd suggest tests that validate the XML if one is not already in place. > > All XML instances are validated as part of the document generation worklow. > > > - In the XML the clID and crID are both frequently "ClientX" -- I wanted > > to verify that this value is the right example value for both fields > > It's an arbitary string, but is used throughout the base RFC series and > many subsequent documents. > > > - I note the DELEG example reference in the 2.2.2, which made me smile > > (full disclosure: I was a DELEG BOF chair). > > DELEG was top of mind when making sure this extension was future-proof. > > > - You might mention in the security considerations that an account > > compromise would lead to an attacker changing the NS/glue addresses > > and then setting a max length TTL to keep the real client from a > > swift recovery. > > That's a good suggestion, thanks. > > I'll upload a new version shortly! > > G. > > -- > Gavin Brown > Principal Engineer, Global Domains & Strategy > Internet Corporation for Assigned Names and Numbers (ICANN) > > https://www.icann.org > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
