Added the _why_ of the 3 policies

Author: jaimejim

draft-ietf-core-coap-pubsub.md

@@ -970,6 +970,8 @@ This document defines parameters used in the messages exchanged between a client
 
 Note that the media type application/core-pubsub+cbor MUST be used when these parameters are transported in the respective message fields.
 
+<!-- To be registerd in IANA: TODO Populate the TBDs non-negative unsigned -->
+
 ~~~~~~~~~~~
 +----------------------+----------+-----------+------------+
 | Name                 | CBOR Key | CBOR Type | Reference  |
@@ -1112,12 +1114,19 @@ The registration policy for the IANA registry established in  {{iana-coap-pubsub
 
 Expert reviewers should take into consideration the following points:
 
-* Clarity and correctness of registrations. Experts are expected to check the clarity of purpose and use of the requested entries. Experts need to make sure that registered parameters are clearly defined in the corresponding specification. Parameters that do not meet these objectives of clarity and completeness must not be registered. Experts should consider requesting an opinion on correctness from the Constrained RESTful Environments (CoRE) Working Group.
+The registration policy for the IANA registry established in  {{iana-coap-pubsub-parameters}} is defined as one of "Standards Action with Expert Review", "Specification Required", and "Expert Review". This section gives some general guidelines for what the experts should be looking for; however, they are being designated as experts for a reason, so they should be given substantial latitude.
+
+These registration policies are designed to accommodate different use cases; “Standards Action with Expert Review” allows for further IETF standards and extensions, maintaining consistency and alignment with established protocols; “Specification Required” allows third-party specifications from Standards Development Organizations (SDOs) to register parameters, enabling interoperability and broader applicability; and “Expert Review” provides a flexible mechanism for exposing new parameters that implementors do not want to keep in a private range.
+
+Expert reviewers should take into consideration the following points:
+
+* Clarity and correctness of registrations. Experts are expected to check the clarity of purpose and use of the requested entries. Experts need to make sure that registered parameters are clearly defined in the corresponding specification. Parameters that do not meet these objectives of clarity and completeness must not be registered.
 
-* Duplicated registration and point squatting (the use of unregistered code points) should be discouraged. Reviewers should gather enough information to ensure registration requests do not duplicate existing ones and are likely to see deployment. The zones tagged as "Private Use" are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.
+* Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as "Private Use" are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.
 
-* Specifications are recommended. When specifications are not provided, the description provided needs to have sufficient information to verify the points above.
+* Specifications are required for the "Standards Action With Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
 
+* Experts should take into account the expected usage of fields when approving point assignment. Documents published via Standards Action can also register points outside the Standards Action range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.
 
 --- back