Code change:
We want registration policies that encourage extensions. We also need to bear in mind the existing guidance about how the base scheme, urgency and incremental, are used/applied by clients, servers and intermediaries. The scheme is malleable but it can't implementations are unlikely to be able to swap out prioritization wholesale. This puts reviewers into an awkward position, so we should document clear guidance on registration review and how or when it might be rejected (airing on the side of permissiveness). Fortunately, we had some of these considerations already written down. So this change makes those criteria more specific and actionable. The other important part is that keys are strings, so clashes are less likely. However, given the constraints above and the attractiveness of short key lengths for repeated information, there might be pressure on the finite supply of the 25 remaining single-character keys. So split the IANA registry in two, and place additional Specification Required policy on those precious keys.
First an easy one: Designated Expert is not a standard RFC 8126 rule. I think that you are looking for Expert Review. More substantively, placing a designated expert in a position to consider community feedback is not something we do generally, because it places a lot more responsibility on that person. If the goal is to insist on community review, then you might be better forcing registrations into the standardization process. That said, doing that has historically not worked out well and I would strongly recommend against doing so uniformly, though you might do that for some values (like one-character parameters, for which we have a limited supply) while making policies for other parameters more permissive. It is best if experts are given enough concrete guidance that they aren't ever placed in a position of having to make difficult decisions. Good decisions might cause some people to get angry, for instance. That the decision is good doesn't mean that experts will avoid consequences. Clear, unambiguous guidance to experts is how you avoid those awkward situations.
thank you! I might rewrite this as "future you will thank you for writing down the assessment criteria". We should do this change. We probably want to start thinking about who the expert(s) would be NAME NAME
That's ultimately up to NAME I'd suggest you and/or NAME :)
I am happy to voluteer for that job and if we can share the pain all the better
Same as NAME

Related discussion:
text: 4.3.1. New Priority parameters can be defined by registering them in the <del> HTTP Priority Parameters Registry. Registration requests are reviewed and approved by a Designated Expert, as per Section 4.5 of RFC8126.  A specification document is appreciated, but not required. The Expert(s) should consider the following factors when evaluating requests: Community feedback If the parameters are sufficiently well-defined and adhere to the guidance provided in new-parameters. </del> <ins> HTTP Priority Parameters Registry.  The registry governs the keys (short textual strings) used in Structured Fields Dictionary (see Section 3.2 of STRUCTURED-FIELDS).  Since each HTTP request can have associated priority signals, there is value in having short key lengths, especially single-character strings.  In order to encourage extension while avoiding unintended conflict among attractive key values, the HTTP Priority Parameters Registry operates two registration policies depending on key length. Registration requests for parameters with a key length of one use the Specification Required policy, as per Section 4.6 of RFC8126. Registration requests for parameters with a key length greater than one use the Expert Review policy, as per Section 4.5 of RFC8126.  A specification document is appreciated, but not required. When reviewing registration requests, the designated expert(s) can consider the additional guidance provided in new-parameters but cannot use it as a basis for rejection. </ins> Registration requests should use the following template: <del> Name: [a name for the Priority Parameter that matches key] </del> <ins> [a name for the Priority Parameter that matches key] </ins> <del> Description: [a description of the parameter semantics and value] </del> <ins> [a description of the parameter semantics and value] </ins> <del> Reference: [to a specification defining this parameter] </del> <ins> [to a specification defining this parameter] </ins> See the registry at https://iana.org/assignments/http-priority [4] for details on where to send registration requests.