Chris - I don’t mean to argue the point. If you are not actually inviting discussion...OK.
But since you say: " After some experience with the guidance, we could then choose to make it or some variation, the policy if that was still needed." I will provide you with this datapoint. I did (an admittedly casual) review of such fields in all TLVs defined during the existence of the IS-IS/LSR WGs - which covers over 20 years. I did not find a single occurrence where the flags field ever got extended. So I do not know why we should expect that experience during the next 20 years will be significantly different. This, to me, argues that Tony's proposal is better. Anyways, I am done...thanx for listening. Les > -----Original Message----- > From: Christian Hopps <cho...@chopps.org> > Sent: Wednesday, April 21, 2021 7:05 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: lsr@ietf.org; lsr-cha...@ietf.org; lsr-...@ietf.org > Subject: Re: [Lsr] Guidance for IANA flags field registry creation. > > Hi Les, > > This isn't a proposal, it is the guidance we have come up with based on what > we read in the WG discussion. > > We were asked to make this call so as to unblock the srv6 document, and so > we did. > > I’m not sure how we officially document this. It *is* meant to be revisited > after gaining some experience. The WG website seems like a good idea. > > Thanks, > Chris. > > > On Apr 21, 2021, at 9:57 AM, Les Ginsberg (ginsberg) > <ginsberg=40cisco....@dmarc.ietf.org> wrote: > > > > 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 > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
