Code change:
Algorithms".  Initial values for this registry are given in iana-hsa- contents.  Future assignments and modifications to existing assignment are to be made through the Expert Review registration <del> policy RFC8126 and shall follow the template presented in iana-hsa- template. Algorithms referenced by algorithm identifiers have to be fully defined with all parameters fixed.  Algorithm identifiers in this registry are to be interpreted as whole string values and not as a combination of parts.  That is to say, it is expected that </del> <ins> policy RFC8126. The Designated Expert (DE) is expected to ensure that the algorithms referenced by a registered algorithm identifier are fully defined with all parameters (such as salt, hash, required key length, etc) are fixed by the defining text.  The DE is expected to ensure that the algorithm definition fully specifies the "HTTP_SIGN" and "HTTP_VERIFY" primitive functions, including how all defined inputs and outputs map to the underlying cryptographic algorithm.  The DE is expected to reject any registrations that are aliases of existing registrations.  The DE is expected to ensure all registrations follow the template presented in iana-hsa-template, including that the length of the name is not excessive while still being unique and recognizable.  When setting a registered item's status to "Deprecated", the DE should ensure that a reason for the deprecation is documented, along with instructions for moving away from the deprecated functionality. This specification creates algorithm identifiers by including major parameters in the identifier string.  However, algorithm identifiers in this registry are to be interpreted as whole string values and not as a combination of parts.  That is to say, it is expected that </ins> implementors understand "rsa-pss-sha512" as referring to one specific <del> algorithm with its hash, mask, and salt values set as defined here. Implementors do not parse out the "rsa", "pss", and "sha512" portions of the identifier to determine parameters of the signing algorithm from the string, and the registry of one combination of parameters does not imply the registration of other combinations. Algorithms added to this registry MUST NOT be aliases for other entries in the registry. </del> <ins> algorithm with its hash, mask, and salt values set as defined in the defining text that establishes this identifier.  Implementors do not parse out the "rsa", "pss", and "sha512" portions of the identifier to determine parameters of the signing algorithm from the string, and the registry of one combination of parameters does not imply the registration of other combinations. </ins> 6.2.1.

Related discussion:
text: Comment by NAME I would suggest being explicit about the meaning of "active" and especially "deprecated": these are terms everywhere in RFCs (I am aware), but sometimes they are open for interpretation, and we keep discussing their meaning. It would be good to avoid that situation from this doc.
Comment by NAME The new registries do not have any guidance for the designated experts as to what registrations should be accepted or denied (conformance with template, point squatting, availability of reference specification, etc). See of RFC8126: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request.