LSR WG, After going through the various emails on whether and when to allocate an IANA registry for a flags field, the chairs do not believe we have a strong enough consensus to choose a policy as of yet; however, we feel we do have a rough consensus that would allow us to issue guidance. After some experience with the guidance, we could then choose to make it or some variation, the policy if that was still needed.
Guidance on IANA registry creation for flags fields: - If a flags/bits field is intended for use by the defining document only, and future expansion would be expected to take place in a revision of said document (a "bis"), then no IANA registry creation should be required. - Otherwise, there is some belief that secondary documents (ones that would "update" rather than "replace" the defining base document) may add flags to this field and, hence, an IANA registry should be created by the defining document. - If one has trouble picking, look at other protocol encodings with similar meanings (headers/[sub-]TLVs) to see how they have been expanded historically. For example, if one is defining a Capabilities TLV with a flags field, one could look at other Capability TLVs with flags fields to see what has occurred there. - As it is better to have the registry identified in the base document than elsewhere, one should err on the side of registry creation if there is some doubt as to which to pick. Thanks, Acee and Chris.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
