While I have divided my comments up into those I think are 'discuss worthy' and 'mere comments', I do believe all of my comments should be considered carefully.  The goal of this process specification is to have a clear and concise set of instructions for those with submissions/changes to this registry and the DEs who will be doing the work to consider them.

Many thanks to Tero Kivinen for their secdir review.  I will also state that I agree with his points about: the status of the specification, the format of the references, the inclusion of '(or its future replacement)' - it should be deleted. 

Process specifications are not protocol documents.  There is no reason to make it PS when BCP works just fine - and especially when BCP was working group consensus. (Even if there is one example process specification that is standards track, the vast majority are not.) 

Section 2.1, second para, last sentence:  Why aren't Internet Drafts are not acceptable?  Do they not meet the 'permanent and readily available' requirement?  What if someone takes the contents of an I-D, posts it to a site that is considered 'permanent and readily available', can it be used then? This deviation from what is normally acceptable for 'specification required' needs to be explained.

Section 2.1.1, para 2:  Under what circumstances is it ok for a DE with a COI not defer?  The SHOULD is currently naked, without rationale about when it is ok to ignore it.

Section 2.2.3, para 1:  How are requests to modify or deactivate registrations authenticated?  Can anyone just masquerade as the POC make the request?

Section 4:  Consider how an unauthenticated attacker could disrupt this registry.  Email addresses are super easy to spoof, what keeps this from happening to either modify or deactivate an entry?

** Section 2.1.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.

This language above is a slight reinterpretation of Section 5.2, RFC8126.  Is that really necessary as the following are underspecified:

-- What is a “consensus-based group” (e.g., rough consensus, majority, unanimity)

-- When should a DE NOT recuse if there is a COI?

-- Is there a requirement being set on the IESG that it has to approved more than one DE here (as the language reads, the “IESG should …”)?

** Section 2.1.1
   Should they decline to do so, perceived similarity SHOULD NOT be a
   sufficient reason for rejection as long as all other requirements are
   met.

When is “perceived similarity” a sufficient reason to reject, as the guidance says similarity is sometimes adequate justification (since MUST NOT is not used)?

** Section 2.2.3
   IESG Approval (Section 4.10 of [RFC8126]) is REQUIRED to remove or
   deactivate registrations created through IETF consensus.

What does it mean to “deactivate” a registration?