-
Notifications
You must be signed in to change notification settings - Fork 38
Registry Thoughts
Some registries are used by communities much larger than the IETF. For example, link relations and HTTP headers are routinely created by people who have no experience interacting with the IETF, and no desire to do so.
These registries need to be adaptable to the needs of these broader communities. In particular, they need extremely low friction to new registrations, visibility about registration status, and the ability to be easily updated.
The idea here is that the specification of a registry should not define the interface for making registrations; rather, it should define the requirements for a valid registration, and the interface between the experts and IANA (assuming Expert Review).
This allows the expert(s) to define a workflow for making submissions that is well-suited to the community using that registry, in consultation with IANA. See below for examples.
When such a workflow is established, IANA should update the registry to direct registration requests to it. Registration requests to an e-mail address MUST also be accepted, even if this just means that the e-mail's contents are pasted into the workflow tool.
The expert(s) should also be given the power to modify the registry to reflect deployed reality; for example, registering values that are in use but whose "owner" has not made a registration request, updating existing entries, and (where appropriate) removing invalid ones.
IANA also tracks requests that it receives as part of the RFC publication process, so that it can update the references in the registries in an automated fashion. As a result, these registrations need to be managed by the IANA toolchain, not an external one.
Accommodating this will need experimentation; e.g., it might be best to regularly get a file of the registrations from IANA and create a small amount of tooling to incorporate them into the repo. This might even be done with a CI job.
The expert(s) establish an organisation with a repo dedicated to tracking registration requests. It contains a file or files that represent the current contents of the registry. New requests can be made as issues on the repo, or as pull requests. The experts discuss the request with the community on the issue/PR, and when they come to a conclusion, incorporate the appropriate changes into the registry file(s) and notify IANA.
As with other uses of Github in the IETF, the state of the issues list needs to be persisted, notifications should be sent to an e-mail list (possibly the registry list, if it is not otherwise active), and the repo should be set up with appropriate README and CONTRIBUTING files. It is probably also good to use an issue template for registration requests.