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
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.brown@xxxxxxxxx> 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 <noreply@xxxxxxxx> 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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
