Subject: [Idr] Debate about IANA assignment policies for BGP-LS registries

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 19 Nov 2020 08:25:41 -0000

Hi,

You may have noticed some recent debate about
draft-ietf-idr-bgp-ls-registries on the IDR list.

It is possible that, notwithstanding WG last call, the draft doesn't
correctly capture what the working group wanted.

Since I hold the pen for the draft and am one of the Designated Experts for
the registry, I will try to set out my understanding of what we currently
have, what the document says, and what questions the WG may need to address
next.

[For the avoidance of doubt: I'm just trying to serve the WG and clarify the
instructions to the DEs, I don't have much of an opinion about this.]

The registries were created by RFC 7752 and currently make assignments
according to "Specification Required." RFC 8126 (which post-dated RFC 7752)
defines these terms in section 4.6. "Specification Required" includes the
requirement for:
- review by a Designated Expert
- documentation in a permanent and readily available public specification

Debate rages about the meaning of "permanent" in this context. Does an
Internet-Draft count, does it expire, or is it archived by the tools page?
Does an individual I-D count, or does it need to be adopted first? Does IANA
track the I-D version, and if not what does it mean when a new version
changes the meaning of a code point?

As Alvaro, our AD remarks, IDR is not the place to have this debate. It is
probably an IETF-wide debate and anyone is welcome to take it up with IANA
and the IESG.

What we need to do is decide what we want as our policy for these registries
to be, and then work out how to achieve it. We can then set the DE guidance
(see section 5.1 of RFC 7752) to achieve the right results.

It seems, from various discussions on the list, that the WG (or some of its
more vocal participants) want to be able to assign code points based on I-Ds
and without requiring to do early allocation (RFC 7120). There seem (to me)
to be three ways to approach this:

1. Leave the assignment policies and DE instructions in place per 7752 and
state that they do what we want.
2. Leave the assignment policies in place per 7752, but change the DE
instructions to give explicit advice about Internet-Drafts.
3. Change the assignment policies to be simply "Expert Review" and change
the DE instructions to describe what the DE must do.

The current draft seeks to implement option 3.

I'd note that a secondary issue arises about requests for codepoints arising
from outside the IETF. Suppose another SDO or a vendor wants a code point:
Do they have to write an I-D? Does it have to gain adoption in the WG?

The chairs have a slide on this for the meeting on Friday. I'll leave it to
them to decide whether there is time in the meeting to discuss the topic,
but the agenda was previously full. Perhaps a discussion on this list would
be better.

Best,
Adrian

---

From: <[email-masked]>
Date: Thu, 19 Nov 2020 13:16:43 +0000

Hi Adrian,

First of all, I'm fine with whatever you write (in this document. let's not over commit;-) ).
(If one need arguments: the last called is passed, you know the subject, I trust you to do the right thing, better you doing the job than me)

Then you are raising potentially wide and interesting points.
I don't feel that I have a specific position nor specific knowledge to share. On other hand ignoring your email may actually be more impolite than wasting 5 minutes of your time.

As an operator, I'm very much interested in interoperability.
 
IMHO I would personally distinguish two things.
a) code points are here to avoid clashes in both syntax and semantic interpretations between the sender and the receiver. Ideally, the bigger the code point space, the better; in which case we should be happy to burn many codepoint if needed (i.e. any interop risk).
b) specifications are here for interop. They must be permanent, unchanged, public, complete. Ideally agreed upon, but this is a different subject.
 
Along this, a specification needs codepoints. A code point does not necessarily need a specification.
E.g. if implementer A says 'I burned code point X, I need another one' then we should probably trust him and give him another one to avoid clash. (cf point a).

Now, there is the question of:
- the size of the code point space: how much unlimited is it?
- the incentive for "fait accompli'. One implementer asks for a code point to do whatever it wants. And then go to the IETF to have it rubberstamped, unchanged. A là "I have running code, and reals customers asking for it. We/you can't change anything in the spec". That is not a theoretical risk.

Given this, I personally like the approach taken in RFC 8810  [1] with multiple sub-pools:
- one for experiment use. E.g. 5-10%. With which anyone can freely innovate in his lab.
- one for FCFS or DE. E.g. 50%.  With which anyone can ship its implementation. No red tape. Whether it's unlimited or not is under the responsibility of the community or popularity of the subject/protocol. Note that under the above opinion, for this pool a spec is "nice to have" but not mandated. Hence the discussion of its permanence is moot.
- one for IETF standard E.g. 45-50%. That pool is for real IETF standards.

I'm fully aware that this is not the questions that you asked for. But this is my answer ;-) [2]

Best regards,
Bruno

[1] https://www.rfc-editor.org/rfc/rfc8810.html#name-iana-considerations
[2] Private joke for French people of my generation.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Thursday, November 19, 2020 9:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Idr] Debate about IANA assignment policies for BGP-LS registries
> 
> Hi,
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 19 Nov 2020 13:32:05 +0000

Hi Adrian,

First, thanks for doing this.

You've provided 3 options:
	1. Leave the assignment policies and DE instructions in place per 7752 and state that they do what we want.
	2. Leave the assignment policies in place per 7752, but change the DE instructions to give explicit advice about Internet-Drafts.
KT> I don't believe the first two options can solve/address the main issue why we went down this path. i.e. the "permanency" point for "Specification Required" in RFC8126 and what is there today in the I-D boilerplate. That is a different battle.

	3. Change the assignment policies to be simply "Expert Review" and change the DE instructions to describe what the DE must do.
KT> I would vote for this one. "Expert Review" is what is already there in draft-ietf-idr-bgp-ls-registries. The only change required is the text for DE guidance and for that the text in RFC7370 (i.e. the way it is done in IS-IS) looks apt to me for BGP-LS.

If there is more tweaking that the WG requires, then let us remember that https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/ is following up right behind (hopefully very soon).

The goal of draft-ietf-idr-bgp-ls-registries was to get a "quick point fix" RFC for the allocation scheme for BGP-LS code-points. IMHO stretching it out much further just defeats its purpose.

Thanks,
Ketan

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Adrian Farrel
Sent: 19 November 2020 13:56
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] Debate about IANA assignment policies for BGP-LS registries

Hi,

You may have noticed some recent debate about draft-ietf-idr-bgp-ls-registries on the IDR list.

It is possible that, notwithstanding WG last call, the draft doesn't correctly capture what the working group wanted.

Since I hold the pen for the draft and am one of the Designated Experts for the registry, I will try to set out my understanding of what we currently have, what the document says, and what questions the WG may need to address next.

[For the avoidance of doubt: I'm just trying to serve the WG and clarify the instructions to the DEs, I don't have much of an opinion about this.]

The registries were created by RFC 7752 and currently make assignments according to "Specification Required." RFC 8126 (which post-dated RFC 7752) defines these terms in section 4.6. "Specification Required" includes the requirement for:
- review by a Designated Expert
- documentation in a permanent and readily available public specification

Debate rages about the meaning of "permanent" in this context. Does an Internet-Draft count, does it expire, or is it archived by the tools page?
Does an individual I-D count, or does it need to be adopted first? Does IANA track the I-D version, and if not what does it mean when a new version changes the meaning of a code point?

As Alvaro, our AD remarks, IDR is not the place to have this debate. It is probably an IETF-wide debate and anyone is welcome to take it up with IANA and the IESG.

What we need to do is decide what we want as our policy for these registries to be, and then work out how to achieve it. We can then set the DE guidance (see section 5.1 of RFC 7752) to achieve the right results.

It seems, from various discussions on the list, that the WG (or some of its more vocal participants) want to be able to assign code points based on I-Ds and without requiring to do early allocation (RFC 7120). There seem (to me) to be three ways to approach this:

1. Leave the assignment policies and DE instructions in place per 7752 and state that they do what we want.
2. Leave the assignment policies in place per 7752, but change the DE instructions to give explicit advice about Internet-Drafts.
3. Change the assignment policies to be simply "Expert Review" and change the DE instructions to describe what the DE must do.

I'd note that a secondary issue arises about requests for codepoints arising from outside the IETF. Suppose another SDO or a vendor wants a code point:
Do they have to write an I-D? Does it have to gain adoption in the WG?

The chairs have a slide on this for the meeting on Friday. I'll leave it to them to decide whether there is time in the meeting to discuss the topic, but the agenda was previously full. Perhaps a discussion on this list would be better.

Best,
Adrian

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 19 Nov 2020 13:37:55 +0000

Hi Bruno,

FYI - we also have a RFC7752bis coming up (hopefully shortly) behind this one : https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/ 😉

Thanks,
Ketan

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of [email-masked]
Sent: 19 November 2020 18:47
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Debate about IANA assignment policies for BGP-LS registries

Hi Adrian,

 

Best regards,
Bruno

> Since I hold the pen for the draft and am one of the Designated 
> Experts for the registry, I will try to set out my understanding of 
> what we currently have, what the document says, and what questions the 
> WG may need to address next.
> 
> [For the avoidance of doubt: I'm just trying to serve the WG and 
> clarify the instructions to the DEs, I don't have much of an opinion 
> about this.]
> 
> according to "Specification Required." RFC 8126 (which post-dated RFC 
> 7752) defines these terms in section 4.6. "Specification Required" 
> includes the requirement for:
> Does an individual I-D count, or does it need to be adopted first? 
> Does IANA track the I-D version, and if not what does it mean when a 
> new version changes the meaning of a code point?
> 
> As Alvaro, our AD remarks, IDR is not the place to have this debate. 
> It is probably an IETF-wide debate and anyone is welcome to take it up 
> with IANA and the IESG.
> 
> What we need to do is decide what we want as our policy for these 
> registries to be, and then work out how to achieve it. We can then set 
> the DE guidance (see section 5.1 of RFC 7752) to achieve the right results.
> 
> It seems, from various discussions on the list, that the WG (or some 
> of its more vocal participants) want to be able to assign code points 
> based on I-Ds and without requiring to do early allocation (RFC 7120). 
> There seem (to me) to be three ways to approach this:
> 
> 3. Change the assignment policies to be simply "Expert Review" and 
> change the DE instructions to describe what the DE must do.
> 
> I'd note that a secondary issue arises about requests for codepoints 
> arising from outside the IETF. Suppose another SDO or a vendor wants a code point:
> The chairs have a slide on this for the meeting on Friday. I'll leave 
> it to them to decide whether there is time in the meeting to discuss 
> the topic, but the agenda was previously full. Perhaps a discussion on 
> this list would be better.
> 
> Best,
> Adrian
> 

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 19 Nov 2020 14:26:53 +0000

Hi Adrian, 
I agree with Ketan and would vote for #3 - I thought the last thread was just wordsmithing the DE guidance and not grounds for a document reset. 
Thanks,
Acee

On 11/19/20, 8:34 AM, "Idr on behalf of Ketan Talaulikar (ketant)" <[email-masked] on behalf of ketant=[email-masked]> wrote:

    Hi Adrian,

    Thanks,
    Ketan

    -----Original Message-----
    From: Idr <[email-masked]> On Behalf Of Adrian Farrel
    Sent: 19 November 2020 13:56
    To: [email-masked]
    Cc: [email-masked]
    Subject: [Idr] Debate about IANA assignment policies for BGP-LS registries

    Hi,

    Best,
    Adrian

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Nov 2020 23:02:44 -0500

Hi Adrian

I agree with Ketan as well on option #3.

Thanks

Gyan

On Thu, Nov 19, 2020 at 9:29 AM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> Hi Adrian,
> I agree with Ketan and would vote for #3 - I thought the last thread was
> just wordsmithing the DE guidance and not grounds for a document reset.
> Thanks,
> Acee
>
> On 11/19/20, 8:34 AM, "Idr on behalf of Ketan Talaulikar (ketant)" <
> [email-masked] on behalf of ketant=[email-masked]>
> wrote:
>
>     Hi Adrian,
>
>         1. Leave the assignment policies and DE instructions in place per
> 7752 and state that they do what we want.
>         2. Leave the assignment policies in place per 7752, but change the
> DE instructions to give explicit advice about Internet-Drafts.
>     KT> I don't believe the first two options can solve/address the main
> issue why we went down this path. i.e. the "permanency" point for
> "Specification Required" in RFC8126 and what is there today in the I-D
> boilerplate. That is a different battle.
>
>     KT> I would vote for this one. "Expert Review" is what is already
> there in draft-ietf-idr-bgp-ls-registries. The only change required is the
> text for DE guidance and for that the text in RFC7370 (i.e. the way it is
> done in IS-IS) looks apt to me for BGP-LS.
>
>     If there is more tweaking that the WG requires, then let us remember
> that https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/ is
> following up right behind (hopefully very soon).
>
>     The goal of draft-ietf-idr-bgp-ls-registries was to get a "quick point
> fix" RFC for the allocation scheme for BGP-LS code-points. IMHO stretching
> it out much further just defeats its purpose.
>
>     Thanks,
>     Ketan
>
> Experts for the registry, I will try to set out my understanding of what we
> currently have, what the document says, and what questions the WG may need
> to address next.
>
> clarify the instructions to the DEs, I don't have much of an opinion about
> this.]
>
> Does IANA track the I-D version, and if not what does it mean when a new
> version changes the meaning of a code point?
>
> It is probably an IETF-wide debate and anyone is welcome to take it up with
> IANA and the IESG.
>
> registries to be, and then work out how to achieve it. We can then set the
> DE guidance (see section 5.1 of RFC 7752) to achieve the right results.
>
> of its more vocal participants) want to be able to assign code points based
> on I-Ds and without requiring to do early allocation (RFC 7120). There seem
> (to me) to be three ways to approach this:
>
> it to them to decide whether there is time in the meeting to discuss the
> topic, but the agenda was previously full. Perhaps a discussion on this
> list would be better.
>
>     Best,
>     Adrian
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD