Hi

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.

TL;DR: The document is ready. 

The document specifies no new protocol. EPP is already specified in RFC 5730, and extending EPP is already specified in RFC 3735. This document only specifies the IANA registry for such extensions. Most of the document is about criteria for considerations by the designated expert, and there's a 3-page IANA considerations section (includes lots of examples).

Some elements that seemed strange to me. I’m not trying to second-guess the working group that produced this, as I’ve never participated in it, but I am pointing these things out:
The registry policy is "specification required", which seems OK, and the document points out correctly that this policy implies expert review. I’m used to multiple registries with a single expert (such as in IPsec), so I was surprised to see the requirements in section 2.1.1:
   The IESG should appoint a small pool of individuals (perhaps 3 - 5)
   to serve as designated experts as described in Section 3.2 of RFC
   5226.  The pool should have a single administrative chair who is
   appointed by the IESG.  The designated experts should use the
   existing eppext mailing list (eppext@ietf.org) for public discussion
   of registration requests.  This implies that the mailing list should
   remain open after the work of the EPPEXT working group has concluded.
I guess the number of experts relates to the amount of work to be done, so it depends on the per-document requirements in RFC 3735 and on the amount of documents that arrive in a unit of time. 

NIT: Section 2.1 says, "An English language version of the extension specification will appear in the registry”. The intent, I guess, is that the English-language version is referenced from the registry.

Section 2.2.1 specifies the format for the registration form, which includes an email address, I’m guessing that it’s used as a contact address. For standards-track documents the email address should be iesg@ietf.org. I don’t know if that’s a good idea. Probably best to leave either the editor’s address or the eppext working group.

Section 2.2.3 has some requirements for IANA, so it should be reviewed by IANA. I think it needs a pointer from the IANA considerations section, which is what they review.

The document just sets up an IANA registry. As such, security considerations should probably be no different than any other interaction with IANA. The security considerations describes a possible spoofing attack on the submission process, which is done via email. This seems very unspecific to this document. What's more, I'm not sure I understand why this document requires that submissions be done through email. If IANA decides that they're opening a facebook page, and registration requests should from here on be posted to their "wall", do we need to rev this document?

This document makes no reference to the security of the extensions themselves. Extensions that break the security assumptions of base protocols are a real issue. This is covered to some extent in RFC 3735, but I would have liked the document to specifically mention that this is part of the job of the expert reviewer. Specifically, where section 2.1.1 says:

OLD:
    Extensions should be evaluated for architectural soundness using the
   guidelines described in RFC 3735 [RFC3735].
   
I think it would be better to add at the end there ", including the Security Considerations section of that document.”

NEW:
   Extensions should be evaluated for architectural soundness using the
   guidelines described in RFC 3735 [RFC3735], including the Security 
   Considerations section of that document.

Yoav