RFC 2434:

2. RFC 2434: • Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority.

3. RFC - 3406 • The creation of a new registry name will be simple for most flat registries. The only required elements will be the registry name, a reference to relevant documents, a statement about which current/proposed document repositories contains the authoritative data for the registry, and a statement specifying which element in the registry is the value to be used in the URN.

4. RFC 3406 • Organization Requirements • the organization maintaining the URN namespace should demonstrate stability and the ability to maintain the URN namespace for a long time, and/or it should be clear how the namespace can continue to be usable/useful if the organization ceases to be able to foster it; • it should demonstrate ability and competency in name assignment. This should improve the likelihood of persistence (e.g. to minimize the likelihood of conflicts); • it should commit to not re-assigning existing names and allowing old names to continue to be valid, even if the owners or assignees of those names are no longer members or customers of that organization. This does not mean that there must be resolution of such names, but that they must not resolve the name to false or stale information, and that they must not be reassigned.

5. Request includes various boilerplate plus: • URN resolution/delegation • type of resources to be identified • type of services to be supported • URN assignment procedures