Section 2, general comment:  Remove all of the RFC 8126 text (you don't want to have to update this specification when that RFC gets replaced and yes, there is a 8126bis already), it adds no value, just makes it harder to maintain this specification. 

Section 2.2.1, Registrant name and email address:  Wait, one can merely use IETF, and the IESG's email address?  How will this work?  Don't we really want a person who knows more about the registration?  For some other registries, it is acceptable to use a working group name and email address (Mediatypes, for example).

Section 2.2.3, para 2 and 3:  This is incomprehensible.  Registrations that were created w/ IETF and w/out IETF consensus can be approved by the IESG?  But external registrations can just be summarily deactivated by the DEs?

Section 5:  I'm baffled by this section.  This is a process specification, why are there operational considerations? Everything that exists in this section could be either moved elsewhere or removed. Para 1 belongs in Section 1, para 2 belongs in Section 2 with the rest of the DE instructions, para 3 can be removed.

Section 2.1.1, paragraph 1
>    The IESG should appoint a primary designated expert and a small
>    number of individuals (perhaps 3 - 5) to serve as backup designated
>    experts as described in Section 5.2 of [RFC8126].  The primary
>    designated expert is responsible for conducting all reviews requested
>    by IANA.  The secondary designated experts are responsible for
>    conducting reviews as a consensus-based group if the primary
>    designated expert is unavailable.  In cases where a registration
>    decision could be perceived as creating a conflict of interest for a
>    particular Designated Expert, that Expert SHOULD defer to the
>    judgment of the other Experts.  The designated experts MUST use the
>    existing regext mailing list (regext@ietf.org) or its successor for
>    public discussion of registration requests.

A SHOULD permits an expert with a perceived conflict of interest to decide 
not to recuse in the above paragraph. Conflict-of-interest provisions 
in governance contexts are typically mandatory. MUST would better reflect 
the intent. I support Éric Vyncke who made a similar ballot comment.

Section 5, paragraph 1
>    Section 2 includes provisions for modifying and deleting existing
>    registration entries by registrants.  Such requests MUST NOT be
>    granted if the requested action has operational implication on other
>    entities that deploy that extension, assuming that those entities can
>    be identified.  This guidance can be overridden if the requested
>    action MUST be taken to comply with actions that are beyond the
>    control of the experts and/or IANA, e.g., to comply with legal
>    actions.  Note that the registry does not include a history mechanism
>    and there is no way to track deleted entries once they have been
>    removed.

The second sentence in this paragraph makes the prohibition conditional: 
if affected parties cannot be identified, the constraint does not apply 
and the removal could proceed despite potential operational impact. 
If this is the intended policy, a brief rationale should be provided. 
If not, the language should be tightened.

No reference entries found for these items, which were mentioned in the text:
[RFC5730].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 1
>    RFCs 3735 [RFC3735] and 5730 RFC5730 do not describe how extension
>    development can be managed and coordinated.  This has led to a
>    situation in which server operators can develop different extensions
>    to address similar needs, such as the provisioning of Value Added Tax
>    (VAT) information.  Clients then need to support multiple extensions
>    that serve similar purposes, and interoperability suffers as a
>    result.

s/RFC5730/[RFC5730]/

You are missing the square brackets.

Section 2.1.1, paragraph 1
>    Extensions should be evaluated for architectural soundness using the
>    guidelines described in RFC 3735 [RFC3735] (or its future
>    replacement, including the Security Considerations section of that
>    document.  Expert evaluation should explicitly include consideration
>    of the privacy consequences of proposed extensions, and, at a
>    minimum, ensure that any privacy considerations are fully documented
>    in the relevant specification(s).

s/(or its future replacement/(or its future replacement)/)

You are missing the closing parenthesis.

** Section 2.1.1. Are these three statement providing unique normative guidance?
   The designated experts MUST use the
   existing regext mailing list (regext@ietf.org) or its successor for
   public discussion of registration requests.
…
   The results of the evaluation MUST be shared via email with the
   registrant and the regext mailing list or its successor.
…
   The designated experts MUST make an
   explicit decision and that decision MUST be shared via email with the
   registrant and the regext mailing list or its successor.

** Section 2.2.3
   On receipt of a registration request, IANA will initiate review by
   the designated expert(s), who will evaluate the request using the
   criteria in Section 2.1.1 in consultation with the current working
   group mailing list focused on the development of EPP extensions if
   such working group exists.

Why is this text needed.  It is restating what IANA already does for “Specification Required”.