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. 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? Comments and Nits: - the introduction could use a few more words describing that this document really only is applying to parent/child relationships. Specifically, the intro could be read that the whole purpose of a zone is to create delegations, which may be true for the top of the DNS but less so as you go down. Now, the document is obvious extending EPP where this is used mostly for these types of domains, and hopefully people reading the document knows this already. However, since the intro is already providing background I'd wish for it to be a touch more explicit about describing zone contents. - 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. - 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 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. - 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. - 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). - 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'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). - I'd suggest tests that validate the XML if one is not already in place. - 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 - I note the DELEG example reference in the 2.2.2, which made me smile (full disclosure: I was a DELEG BOF chair). - 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
