Subject: [Lsr] Guidance for IANA flags field registry creation.

From: Christian Hopps <[email-masked]>
Date: Tue, 20 Apr 2021 20:23:37 -0400

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Apr 2021 13:57:21 +0000

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 <[email-masked]> On Behalf Of Christian Hopps
> Sent: Tuesday, April 20, 2021 5:24 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Lsr] Guidance for IANA flags field registry creation.
> 
> LSR WG,
>

---

From: Christian Hopps <[email-masked]>
Date: Wed, 21 Apr 2021 10:05:02 -0400

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=[email-masked]> wrote:
> 
> Chris/Acee -
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 21 Apr 2021 14:10:34 +0000

Hi Les, 

As stated in the guidance, it would be better for the IANA registry to be created by the document that creates the field. If there is a reasonable possibly of extension, we don't see any reason not to create a registry. It's not like IANA registries are a scarce commodity. 

Thanks,
Acee

On 4/21/21, 9:57 AM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

    Chris/Acee -

    <snip>

       Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Apr 2021 14:31:21 +0000

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

> From: Christian Hopps <[email-masked]>
> Sent: Wednesday, April 21, 2021 7:05 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Lsr] Guidance for IANA flags field registry creation.
> 
> Hi Les,
> 
> 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=[email-masked]> wrote:
> >
> > Chris/Acee -
> >
> > 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
> > The problem I have with your proposal is that it requires a degree of
> clairvoyance on the part of the original draft authors.
> > 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
> >
> >

---

From: Tony Li <[email-masked]>
Date: Wed, 21 Apr 2021 07:46:49 -0700

Les,

> 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 fie…

draft-ietf-isis-te-app defines the Application Specific Link Attributes TLV.  That includes the Standard Application Identifier Bit Mask and defines three bits.

draft-ietf-lsr-flex-algo extends this with one bit for FlexAlgo.

So there is one example.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Apr 2021 16:11:49 +0000

Tony -

Because this is shared between OSPF and IS-IS the related registry is in a different location.

https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#link-attribute-application-identifiers

as defined in 

https://www.rfc-editor.org/rfc/rfc8919.html#section-7.4 

For me, this falls into the same category as https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags . 
It is a general purpose flags field that was expected to be updated by a variety of otherwise unrelated documents and so we defined a registry for it.
This category of flags field was never under discussion - I thought you and I had agreed on this explicitly early on.

   Les

> From: Tony Li <[email-masked]>
> Sent: Wednesday, April 21, 2021 7:47 AM
> Cc: Christian Hopps <[email-masked]>; [email-masked]; [email-masked]; lsr-
> [email-masked]
> > 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.
> 
> 
> draft-ietf-isis-te-app defines the Application Specific Link Attributes TLV.
> That includes the Standard Application Identifier Bit Mask and defines three
> bits.
>

---

From: Christian Hopps <[email-masked]>
Date: Wed, 21 Apr 2021 12:36:13 -0400

Is this really that big of an issue? This seems to be taking a lot of the WGs time at this point for a fairly trivial thing.

Thanks,
Chris.

> On Apr 21, 2021, at 12:11 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Tony -
>