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.