Chris/Acee - Thanx for putting this proposal together.
As I have previously stated, I prefer no registries at all for this case. But if we are to have registries, I much prefer Tony Li's proposal: <snip> When a potentially shared field is created, the defining document specifies the name of a future registry, but does NOT request IANA create the registry at this time. When any document wishes to update the field, it requests that IANA create it and populate it with both legacy and updated values. <end snip> The problem I have with your proposal is that it requires a degree of clairvoyance on the part of the original draft authors. Tony's proposal avoids that. One other question - where/how will the final version of this guidance be documented? Historically, an RFC gets written for such things - but I would hope there is a lighter weight solution. Is it possible to have a "WG Policy" which is documented somewhere on the WG website? Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Christian Hopps > Sent: Tuesday, April 20, 2021 5:24 PM > To: lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > Subject: [Lsr] Guidance for IANA flags field registry creation. > > 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. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
