Subject: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

From: Alvaro Retana <[email-masked]>
Date: Mon, 16 Nov 2020 07:53:17 -0800

Adrian:

Hi!  Thanks for your work on this document.

I have some concerns about the text related to the motivation and the
DE guidance, along with some minor comments and nits.  Please see
in-line below.

Thanks!

Alvaro.

[Line numbers from idnits.]

...
12	Abstract

14	   RFC 7752 defines Border Gateway Protocol - Link State (BGP-LS).  IANA
15	   created a registry consistent with that document called the "Border
16	   Gateway Protocol - Link State (BGP-LS) Parameters Registry" with a
17	   number of sub-registries.  The allocation policy applied by IANA for
18	   those policies is "Specification Required" as defined in RFC 8126.

[minor] s/allocation policy applied by IANA for those
policies/allocation policy applied by IANA for those registries/g

...
66	1.  Introduction

68	   Border Gateway Protocol - Link State (BGP-LS) [RFC7752] requested
69	   IANA to create a registry consistent called the "Border Gateway
70	   Protocol - Link State (BGP-LS) Parameters Registry" with a number of
71	   sub-registries.  The allocation policy applied by IANA for those
72	   policies is "Specification Required" as defined in [RFC8126].

[nit] s/a registry consistent called/a registry called

74	   The "Specification Required" policy requires evaluation of any
75	   assignment request by a "Designated Expert" and guidelines for any
76	   such experts are given in section 5.1 of [RFC7752].  In addition,
77	   this policy requires "the values and their meanings must be
78	   documented in a permanent and readily available public specification,
79	   in sufficient detail so that interoperability between independent
80	   implementations is possible" [RFC8126].  Further, the intention
81	   behind "permanent and readily available" is that "a document can
82	   reasonably be expected to be findable and retrievable long after IANA
83	   assignment of the requested value" [RFC8126].

[nit] s/requires "the values/requires that "the values

85	   It is often considered that it is the responsibility of the
86	   Designated Expert to make a determination as to whether a
87	   specification meets the requirement to be permanent and readily
88	   publicly available.  A degree of contention arises in this case
89	   because Internet-Drafts are now permanently archived in the IETF&s
90	   tools archive, yet each such document is marked with a piece of
91	   boilerplate text as follows that brings doubt about its suitability
92	   as a permanent record:

[nit] s/IETF&s/IETF's

94	      Internet-Drafts are draft documents valid for a maximum of six
95	      months and may be updated, replaced, or obsoleted by other
96	      documents at any time.  It is inappropriate to use Internet-Drafts
97	      as reference material or to cite them other than as "work in
98	      progress."

[major] Related to the use of IDs to satisfy Specification Required.

The general practice is to let the DEs decide if an ID is sufficient.
Clear instructions go a long way.

The motivation discussed on the list is focused only on speeding up
allocations by eliminating the rfc7120-related part of the process.
This document is not the best place to introduce a discussion about
the boilerplate, or the interpretation of other documents.

Please reword the motivation.

[] I know the conversation about IDs, their boilerplate, and the
Specification Required policy has come up several times, and that
rfc8126 didn't include the best possible text.  I will bring this up
to the IESG (again), but I suspect that the result will be to hold any
potential changes until rfc8126bis (I think Michelle @ IANA mentioned
that she was working on it).

...
129	2.1.  Guidance for Designated Experts

131	   Section 5.1 of [RFC7752] gives guidance to Designated Experts.  This
132	   section replaces that guidance.

134	   In all cases of review by the Designated Expert (DE) described here,
135	   the DE is expected to check the clarity of purpose and use of the
136	   requested code points.  Additionally, the DE must verify that any
137	   request for one of these code points has been made available for
138	   review and comment within the IETF: the DE will post the request to
139	   the IDR Working Gorup mailing list (or a successor mailing list
140	   designated by the IESG).  If the request comes from within the IETF,
141	   it should be documented in an Internet-Draft.  Lastly, the DE must
142	   ensure that any other request for a code point does not conflict with
143	   work that is active or already published within the IETF.

[nit] s/Gorup/Group

[major] "the DE must verify that any request for one of these code
points has been made available for review and comment within the IETF:
the DE will post the request to the IDR..."

The text in rfc7752 asks that "any specification produced in the IETF
that requests one of these code points has been made available for
review by the IDR..."   But the updated text talks about the
*request*, not the *specification*, which is what I assume is what you
want idr to see, and is in line with the original instructions.
Right?

[major] On the same text...  What is the expectation when posting the
specification to idr?  Can the DE move on once he/she sends a message
to idr, or is there some feedback/discussion/confirmation expected?
The text explicitly talks about being "available for review" -- what
type of review is expected?

[major] Related to possible WG feedback...  How much attention are the
DEs expected to pay to the WGs review?  The Expert Review policy can
clearly result in the allocation of codepoints to specifications that
don't have IETF consensus/approval/favorable reviews...

[major] "If the request comes from within the IETF..."  How is it
determined that the request comes from "within the IETF"?  For
example, the case where a draft is discussed/adopted in a WG, and the
WG (not just the authors) decide to ask for an allocation seems like a
case where the request comes from "within the IETF": the WG making the
request is part of the IETF.  What are other cases?

[major] Do you really want all the sub-registries to use the same DE
instructions?  An important difference between Expert Review and
Specification Required is that the former is not covered by the early
allocation process in rfc7120 -- which, I think is part of the
objective.  The space in the registries is large (so there shouldn't
be significant issues with unused codepoints), except for the "BGP-LS
Protocol-IDs" one which only has 255 possible values; that is still
pretty big for its purpose.  Just want to check everyone is ok with
this.

An alternative would be to still use Expert Review, and to add
rfc7370-like instructions.  In short: the DE would follow an Early
Allocation process akin to rfc7120 (just for this sub-registry)...not
only when assigning a value, but also if deallocation is needed.

[major] Why isn't rfc2119 language used in the DE instructions?  As
written, the DEs, for example, can decide to not enforce the ID
requirement for no good reason.

145	3.  Security Considerations
...
149	   Note that the change to the expert review guidelines make the
150	   registry and the Designated Experts slightly more vulnerable to
151	   denial of service attacks through excessive and bogus requests for
152	   code points.  It is expected that the registry cannot be effectively
153	   attacked because the Designated Experts would, themselves, fall to
154	   any such attack first.  Designated Experts are expected to report to
155	   the IDR working group chairs and responsible Area Director if they
156	   believe an attack to be in progress, and should immediately halt all
157	   requests for allocation.  This may temporarily block all legitimate
158	   risks until mitigations have been put in place.

[nit] s/the change...make/the change...makes

[minor] s/block all legitimate risks/block all legitimate requests

160	   This change in allocation policy should not have any effect on the
161	   integrity of BGP-LS since there is no change to the review
162	   requirements for the work that underlies the request.

[major] Yes, there is!!  Specification Required asks for a
specification to be stable (discussion, adoption in a WG, etc.) before
granting (early) allocation -- this document leaves that decision to
the DEs and what they may consider to be "clear".

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Nov 2020 08:15:32 -0000

Hi Alvaro,

Thanks for this. As usual, nits are an embarrassment.

Inline for the detailed discussion.

A

> that she was working on it).

I know that you had a conversation with IANA about it being up to the DEs to determine what is “permanent and readily available”…and that it could include I-Ds (if the DEs determined that was ok). 

The problem with this statement is that the DEs might take a view on the appropriateness of using an I-D for this purpose. 

Hence, this document makes it clear to the DE that they are expected to allow assignment resulting from an I-D. It removes that element of determination from the DE.

[In this case of these registries and their DEs, this is a good thing. I am one of the DEs for the registries and I (in general) do not consider that permanent assignment based on an I-D is a good thing. In fact, I think it is a bad idea. However, this document gives me clear instructions that for these registries I must not take that into account.

But, do we need the motivation in this document? Probably not.

I think we can safely just delete...
   It is often considered that it is the responsibility of the Designated
   Expert to make a determination as to whether a specification meets the
   requirement to be permanent and readily publicly available.  A degree
   of contention arises in this case because Internet-Drafts are now permanently
   archived in the IETF's tools archive, yet each such document is marked
   with a piece of boilerplate text as follows that brings doubt about its
   suitability as a permanent record:

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."

> want idr to see, and is in line with the original instructions.

The text is as intended. This is indicative of the change from "Specification Required" (a specification must exist and so can be shown to the WG) to "Expert Review" (no specification is required, so when there is no specification, only the request can be shown).

No change to text.

> type of review is expected?

Was not setting any expectations on the DE here. They can do what they consider reasonable.
Personally, I would expect comments over one or two weeks and would accept any type of review (of the request).

No change to text proposed. We *could* codify this if someone has a proposal.

> don't have IETF consensus/approval/favorable reviews...

I would expect DEs to listen to feedback, but make their own decision. If, for example, some feedback said, "Hey, this conflicts with the work we are doing in the WG," I would expect the DE to check this out. If some feedback said, "This will cause the Internet to crash," the DE is also expected to check it out. But, it is not a request for consensus, it is a request for review. 

Again, I am not proposing any text change for this.

> request is part of the IETF.  What are other cases?

Agree, this is ambiguous. Not trying to say, "The request comes from the IETF," but, "From within the IETF." That is, in any way from within the IETF process. I think that includes, on an IETF mailing list. 

It's more of an expression of the converse. "Requests that come direct to the DEs or IANA without first approaching the IETF."

Any suggestions of how to express this?

> pretty big for its purpose.  Just want to check everyone is ok with

This is my understanding of what IDR wanted. 

> only when assigning a value, but also if deallocation is needed.

So, no change proposed.

> requirement for no good reason.

I don't think 2119 language is any more legally enforceable than regular English. There is "must" and "should" in these instructions, and my expectation is that a DE would use them in the correct meanings of the words. 

AFAIK, the purpose of 2119 is to clarify (or make bold) implementation behaviors for protocol specs.

> the DEs and what they may consider to be "clear".

Hmmmm, no, I don't think so. The change is for code point assignment, not for protocol specification. 
This is, of course, the area of debate when reducing the requirements for code point assignment. IDR likes the idea of making code points readily available so as to reduce squatting, help avoid clashes, and make it clear what code points are being used for.

We could possibly reword this as...

   This change in allocation policy is not expected to not have any
   effect on the integrity of BGP-LS standards track specifications 
   since there is no change to the review requirements for the
   work that underlies the request if it is to become an RFC.

Would that help?

Cheers,
Adrian

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 17 Nov 2020 07:41:56 -0800

On November 17, 2020 at 1:15:34 PM, Adrian Farrel wrote:

Hi!

You mentioned below that you expect the DEs to apply the instructions
using "the correct meanings of the words".  You are the current DE, I
have no doubt you'll apply the "correct meaning" -- you know what that
is: you wrote it!   My concerns are mostly about future DEs, or people
requesting allocations correctly interpreting the meaning.

To be honest, I read through your answers and I still have a lot of
concerns.  It is too late/early for me to come up with more text...I
may also be overthinking it.  I would love to get a 3rd party opinion.

In the meantime, I put some more comments/concerns inline.

Thanks!

Alvaro.

...
> I know that you had a conversation with IANA about it being up to the DEs to
> determine what is “permanent and readily available”…and that it could include
> I-Ds (if the DEs determined that was ok).
...
> material or to cite them other than as "work in progress."

As I offered, I started a conversation with the IESG about this topic.
The responses so far (only 2) agree with (1) a DE can determine an ID
is enough, and (2) we should update the boilerplate.

My proposal was to replace the last sentence of the boilerplate with
"Internet-Drafts should be referenced as "work in progress.", or
something similar.  Other suggestions are welcome of course.

> The text is as intended. This is indicative of the change from "Specification
> Required" (a specification must exist and so can be shown to the WG) to
> "Expert Review" (no specification is required, so when there is no
> specification, only the request can be shown).

Aside: Expert Review is not Specification Required...but that doesn't
preclude the instructions from requiring one; e.g. rfc7370.

The text says that the "DE is expected to check the clarity of purpose
and use of the requested code points".  No specification is required,
but a (short) description is.  So, the DE would send a note to idr
saying: "There's a request for a BGP-LS TLV."  Maybe include who
requested it, and the description.  Is that it?  Should the
description always be included?  Maybe you're considering that to be
part of the request...can we please be clear on what idr should know?

> any type of review (of the request).

One or two weeks sound reasonable.  I would like to see that in the
text: either specifically call out a time frame for review/comments,
or at least say "the DE must accept comments/reviews over a reasonable
amount of time".

> I would expect DEs to listen to feedback, but make their own decision. If,
> for example, some feedback said, "Hey, this conflicts with the work we are
> doing in the WG," I would expect the DE to check this out. If some feedback
> said, "This will cause the Internet to crash," the DE is also expected to
> check it out. But, it is not a request for consensus, it is a request for
> review.

Fair point, it is a request for comments, not consensus.

Should the DE reply to the comments on the list?  There's a
possibility that the DE doesn't agree with the feedback related to
"Hey, this conflicts with the work we are doing in the WG," and
decides to approve the request.  Should the WG be informed of the
allocation and any reasoning?

What does it mean for work to be in "conflict"?  Is an alternate
solution to work being done in the WG a conflict?  For example, the DE
thinks that the proposal to advertise a sw version in a new TLV is not
in conflict with a potential alternate solution to add it to an
existing TLV...just an example.

How are conflicts of opinion resolved?

A significant driver for the change in policy (as I understand the
discussion from the mailing list) is to speed up allocations, not
having to prove WG interest (rfc7120).  I am concerned about cases
where the WG discusses other potential ways to achieve a solution,
potential in the sense that they are theoretical and not active
work...but that could become active -- we may end up in some sort of
"race condition".

BTW, what is considered "active work"?  Is that published draft or an
adopted one?

Also, I'm assuming that "published within the IETF" means an RFC in
the IETF stream.  Is that a good assumption?

Having idr know that there is a request with just a short description,
and not setting a clear expectation that comments will matter (or at
least be addressed seems useless to me.  In fact, it sounds as if it
could be a source of conflict.

Maybe I'm missing the point.

> Agree, this is ambiguous. Not trying to say, "The request comes from the
> IETF," but, "From within the IETF." That is, in any way from within the IETF
> process. I think that includes, on an IETF mailing list.
>
> It's more of an expression of the converse. "Requests that come direct to the
> DEs or IANA without first approaching the IETF."

If I propose something on the list and no one pays attention to me,
and I then ask for a codepoint, is that from "within the IETF"?  What
if my idea was not accepted (people just didn't like it, but there's
no alternate proposal)?  In both of these cases I didn't write a
draft, just posted a (short) description to the list asking for
feedback.

There seems to be an incentive to ask for allocation first and then
come to the WG.  Granted that some manufacturers may want to implement
their idea first (strategic advantage), but this can also be used as a
lever: my idea may not be the best, but I already have an
implementation with an approved codepoint...

...
> I don't think 2119 language is any more legally enforceable than regular
> English. There is "must" and "should" in these instructions, and my
> expectation is that a DE would use them in the correct meanings of the
> words.

Yeah...just like with a lot of the process RFCs, I think there's room
for  interpretation.  As I said, I worry the interpretation that
(future) DEs may have.

I'll grant you that it is better to use must/should than other words
to try to get a similar interpretation (e.g. rfc8200).

> Hmmmm, no, I don't think so. The change is for code point assignment, not for

...there may not be a specification.

> This is, of course, the area of debate when reducing the requirements for
> code point assignment. IDR likes the idea of making code points readily
> available so as to reduce squatting, help avoid clashes, and make it clear
> what code points are being used for.
>

Pfft...sure.

There is no required direct link between the allocation policy and the
underlying work becoming an RFC...which could still result in
affecting the integrity of BGP-LS (the original text).

I don't think this paragraph needs to be included at all.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 17 Nov 2020 22:51:16 +0000

Adrian (and Alvaro) -

Apologies for inserting myself in this discussion...but as regards "Section2.1.  Guidance for Designated Experts"

It seems you have largely retained the text from https://tools.ietf.org/html/rfc7752#section-5.1 - but I am wondering why you don't replace this text with text similar to https://www.rfc-editor.org/rfc/rfc7370.html#section-4 ?
(which - as you may recall - you actually wrote)

What I don’t like about the current text in Section 2.1 is:

1)It seems to be somewhat ambiguous as to whether a document is required.

Saying 

"any  request for one of these code points has been made available for
   review and comment within the IETF" 

suggests that it might be allowed to request/assign a codepoint w/o a document.
Is this really what you intend?

2)I do not know why the DE needs to:

"post the request to  the IDR Working Gorup mailing list (or a successor mailing list
   designated by the IESG)"

NIT: s/Gorup/Group

I suppose this might relate to my point #1 in that if it were allowed to request a codepoint w/o a document then the relevant WG might not know about the request. So if you agree to point #1 then the need for this text goes away.

Something I DO like is the statement:

"the DE must
   ensure that any other request for a code point does not conflict with
   work that is active or already published within the IETF."

RFC 7370 does not make this explicit statement, but clearly this is desirable/required.

    Les

> -----Original Message-----
> From: Idr <[email-masked]> On Behalf Of Adrian Farrel
> Sent: Tuesday, November 17, 2020 12:16 AM
> To: 'Alvaro Retana' <[email-masked]>; draft-ietf-idr-bgp-ls-
> [email-masked]
> Cc: 'idr@ietf. org' <[email-masked]>; [email-masked]
> Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01
> 
> Hi Alvaro,
> 
> determine what is “permanent and readily available”…and that it could
> include I-Ds (if the DEs determined that was ok).
> 
> The problem with this statement is that the DEs might take a view on the
> appropriateness of using an I-D for this purpose.
> 
> Hence, this document makes it clear to the DE that they are expected to
> allow assignment resulting from an I-D. It removes that element of
> determination from the DE.
> 
> [In this case of these registries and their DEs, this is a good thing. I am one of
> the DEs for the registries and I (in general) do not consider that permanent
> assignment based on an I-D is a good thing. In fact, I think it is a bad idea.
> However, this document gives me clear instructions that for these registries I
> must not take that into account.
> 
> Personally, I would expect comments over one or two weeks and would
> accept any type of review (of the request).
> 
> I would expect DEs to listen to feedback, but make their own decision. If, for
> example, some feedback said, "Hey, this conflicts with the work we are doing
> in the WG," I would expect the DE to check this out. If some feedback said,
> "This will cause the Internet to crash," the DE is also expected to check it out.
> But, it is not a request for consensus, it is a request for review.
> 
> available so as to reduce squatting, help avoid clashes, and make it clear what
> code points are being used for.
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 18 Nov 2020 02:43:39 +0000

+1 to what Les mentioned and it does look to me that the text from RFC7370 Sec 4 (which is also not surprisingly Adrian's product 😊) aligns more closely to the original intention (at least what I had in mind) when we started down this path.

In my view, the goal of this update is not to allow the IDR WG review to be bypassed for allocation. The issue was more about the RFC7120 requirements and the "non-permanent" nature of IDs.

https://mailarchive.ietf.org/arch/msg/idr/dJ3n_8VGC5kYYkBqX4Z6138IZao/

Thanks,
Ketan

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: 18 November 2020 04:21
To: [email-masked]; 'Alvaro Retana' <[email-masked]>; [email-masked]
Cc: 'idr@ietf. org' <[email-masked]>; [email-masked]
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Adrian (and Alvaro) -

Saying 

NIT: s/Gorup/Group

"the DE must

    Les

> > to the IESG (again), but I suspect that the result will be to hold 
> > any potential changes until rfc8126bis (I think Michelle @ IANA 
> > mentioned that she was working on it).
> 
> I know that you had a conversation with IANA about it being up to the 
> DEs to determine what is “permanent and readily available”…and that it 
> could include I-Ds (if the DEs determined that was ok).
> 
> The problem with this statement is that the DEs might take a view on 
> the appropriateness of using an I-D for this purpose.
> 
> Hence, this document makes it clear to the DE that they are expected 
> to allow assignment resulting from an I-D. It removes that element of 
> [In this case of these registries and their DEs, this is a good thing. 
> I am one of the DEs for the registries and I (in general) do not 
> consider that permanent assignment based on an I-D is a good thing. In fact, I think it is a bad idea.
> However, this document gives me clear instructions that for these 
> registries I must not take that into account.
> 
> > The text in rfc7752 asks that "any specification produced in the 
> > IETF that requests one of these code points has been made available for
> > *request*, not the *specification*, which is what I assume is what 
> > you want idr to see, and is in line with the original instructions.
> > Right?
> 
> The text is as intended. This is indicative of the change from 
> "Specification Required" (a specification must exist and so can be 
> shown to the WG) to "Expert Review" (no specification is required, so 
> when there is no specification, only the request can be shown).
> 
> No change to text.
> 
> > [major] On the same text...  What is the expectation when posting 
> > the specification to idr?  Can the DE move on once he/she sends a 
> > message to idr, or is there some feedback/discussion/confirmation expected?
> > [major] Related to possible WG feedback...  How much attention are 
> > the DEs expected to pay to the WGs review?  The Expert Review policy 
> > can clearly result in the allocation of codepoints to specifications 
> > that don't have IETF consensus/approval/favorable reviews...
> 
> I would expect DEs to listen to feedback, but make their own decision. 
> If, for example, some feedback said, "Hey, this conflicts with the 
> work we are doing in the WG," I would expect the DE to check this out. 
> If some feedback said, "This will cause the Internet to crash," the DE is also expected to check it out.
> > example, the case where a draft is discussed/adopted in a WG, and 
> > the WG (not just the authors) decide to ask for an allocation seems 
> > like a case where the request comes from "within the IETF": the WG 
> > making the request is part of the IETF.  What are other cases?
> 
> Agree, this is ambiguous. Not trying to say, "The request comes from 
> the IETF," but, "From within the IETF." That is, in any way from 
> within the IETF process. I think that includes, on an IETF mailing list.
> 
> It's more of an expression of the converse. "Requests that come direct 
> to the DEs or IANA without first approaching the IETF."
> 
> > Specification Required is that the former is not covered by the 
> > early allocation process in rfc7120 -- which, I think is part of the 
> > be significant issues with unused codepoints), except for the 
> > "BGP-LS Protocol-IDs" one which only has 255 possible values; that 
> > is still pretty big for its purpose.  Just want to check everyone is 
> > ok with this.
> 
> > Allocation process akin to rfc7120 (just for this 
> > sub-registry)...not only when assigning a value, but also if deallocation is needed.
> 
> So, no change proposed.
> 
> I don't think 2119 language is any more legally enforceable than 
> regular English. There is "must" and "should" in these instructions, 
> and my expectation is that a DE would use them in the correct meanings 
> of the words.
> 
> > specification to be stable (discussion, adoption in a WG, etc.) 
> > before granting (early) allocation -- this document leaves that 
> > decision to the DEs and what they may consider to be "clear".
> 
> This is, of course, the area of debate when reducing the requirements 
> for code point assignment. IDR likes the idea of making code points 
> readily available so as to reduce squatting, help avoid clashes, and 
> make it clear what code points are being used for.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 18 Nov 2020 04:58:45 -0000

Hi Alvaro,

3rd party is a good idea. I may be under-thinking it.

I'll respond to the rest in the morning when I'm more awake.

A

-----Original Message-----
From: Alvaro Retana <[email-masked]> 
Sent: 17 November 2020 15:42
To: [email-masked]; [email-masked]
Cc: [email-masked]; idr@ietf. org <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Subject: RE: AD Review of draft-ietf-idr-bgp-ls-registry-01

Hi!

Thanks!

Alvaro.

...
...

...

Pfft...sure.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 18 Nov 2020 05:49:33 -0000

Hey Les,

> Apologies for inserting myself in this discussion...but as
> regards "Section2.1.  Guidance for Designated Experts"

Not at all! As you may have seen, Alvaro and I had reached the point of needing additional eyes.

> It seems you have largely retained the text from https://tools.ietf.org/html/rfc7752#section-5.1
> - but I am wondering why you don't replace this text with text similar to
> https://www.rfc-editor.org/rfc/rfc7370.html#section-4 ? (which - as you may recall - you actually
> wrote)

Hah! Well, I had a hand in both 7370 and 7752 😊

Is that schizophrenia? Not completely. In 7752 and now in this document, I am not representing my opinion on what the IANA section should say or how DE guidance should be expressed; I am trying to represent the IDR view of how they want their registries run.

> suggests that it might be allowed to request/assign a codepoint w/o a
> document. Is this really what you intend?

I believe you have correctly captured the intent of the text. 

My understanding of what the WG wanted was to allow a request for a codepoint to be made from "outside" the IETF by simply making a request. Since "the DE is expected to check the clarity of purpose and use of the requested code points" I would expect some brief documentation (probably an email).

But if "the request comes from within the IETF, it should be documented in an Internet-Draft."

> "post the request to  the IDR Working Gorup mailing list (or a successor mailing list

It is a mixture of:
- politeness
- allowing people working on the protocol to know what is going on
- an opportunity for useful input to the DEs

The bit about the successor mailing list is in case IDR is closed at some point.

> NIT: s/Gorup/Group
Ack

> I suppose this might relate to my point #1 in that if it were allowed to
> request a codepoint w/o a document then the relevant WG might not
> know about the request. So if you agree to point #1 then the need for
> this text goes away.

Yes, up to a point 😊
Even if #1 ends up requiring documentation, that documentation is not necessarily:
- an I-D
- an I-D that anyone has shared with IDR

>   work that is active or already published within the IETF."

Glad to have *something* right.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 18 Nov 2020 06:11:30 -0000

Thanks Ketan,

It has been so long that I really can't recall the root of this work, so thanks for the mail archive pointer.

Alvaro (probably wisely) doesn't want to open the discussion of whether an I-D is suitable to meet the conditions of a "permanent and readily available public specification".

We should, maybe, take a further pass at working out what the WG really wants. For example, we could stick with "Specification Required" and clarify the case with DE guidance that says "for the purpose of these registries, any Internet-Draft in any state of processing shall be considered to meet the requirements of an available specification."

Cheers,
Adrian
-----Original Message-----
From: Ketan Talaulikar (ketant) <[email-masked]> 
Sent: 18 November 2020 02:44
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; 'Alvaro Retana' <[email-masked]>; [email-masked]
Cc: 'idr@ietf. org' <[email-masked]>; [email-masked]
Subject: RE: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Thanks,
Ketan

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: 18 November 2020 04:21
To: [email-masked]; 'Alvaro Retana' <[email-masked]>; [email-masked]
Cc: 'idr@ietf. org' <[email-masked]>; [email-masked]
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Adrian (and Alvaro) -

Saying 

NIT: s/Gorup/Group

"the DE must

    Les

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 18 Nov 2020 06:22:21 +0000

Hi Adrian,

I do see the option you came up with in the case of RFC7370 as good for us here - i.e. switch to "Expert Review" and the DE procedure/guideline is effectively similar to what the motivation was "Specification Requirement". The motivation (in my view) being to simplify and speed up the allocation process for WG adopted BGP-LS drafts.

This way, we carve out our way past what I (personally) see as issues with the ID boilerplate and the language for "Specification Required" in RFC8126.

Definitely, taking WG view would be necessary on this.

Thanks,
Ketan

-----Original Message-----
From: Adrian Farrel <[email-masked]> 
Sent: 18 November 2020 11:42
To: Ketan Talaulikar (ketant) <[email-masked]>; 'Les Ginsberg (ginsberg)' <ginsberg=[email-masked]>; 'Alvaro Retana' <[email-masked]>; [email-masked]
Cc: 'idr@ietf. org' <[email-masked]>; [email-masked]
Subject: RE: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Thanks Ketan,

Cheers,
Adrian
-----Original Message-----
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: 18 November 2020 02:44
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; 'Alvaro Retana' <[email-masked]>; [email-masked]
Cc: 'idr@ietf. org' <[email-masked]>; [email-masked]
Subject: RE: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Thanks,
Ketan

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: 18 November 2020 04:21
To: [email-masked]; 'Alvaro Retana' <[email-masked]>; [email-masked]
Cc: 'idr@ietf. org' <[email-masked]>; [email-masked]
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Adrian (and Alvaro) -

Saying 

NIT: s/Gorup/Group

"the DE must

    Les

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 18 Nov 2020 01:26:05 -0500

Adrian and Ketan: 

Do you wish a direct query of the WG from the chairs and/or shepherd?  Or do you want an informal query first? 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Wednesday, November 18, 2020 1:22 AM
To: [email-masked]; 'Les Ginsberg (ginsberg)'; 'Alvaro Retana'; [email-masked]
Cc: 'idr@ietf. org'; [email-masked]
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Hi Adrian,

Thanks,
Ketan

-----Original Message-----
From: Adrian Farrel <[email-masked]>
Sent: 18 November 2020 11:42
To: Ketan Talaulikar (ketant) <[email-masked]>; 'Les Ginsberg (ginsberg)' <ginsberg=[email-masked]>; 'Alvaro Retana' <[email-masked]>; [email-masked]
Cc: 'idr@ietf. org' <[email-masked]>; [email-masked]
Subject: RE: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Thanks Ketan,

Cheers,
Adrian
-----Original Message-----
From: Ketan Talaulikar (ketant) <[email-masked]>
Sent: 18 November 2020 02:44
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; 'Alvaro Retana' <[email-masked]>; [email-masked]
Cc: 'idr@ietf. org' <[email-masked]>; [email-masked]
Subject: RE: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Thanks,
Ketan

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: 18 November 2020 04:21
To: [email-masked]; 'Alvaro Retana' <[email-masked]>; [email-masked]
Cc: 'idr@ietf. org' <[email-masked]>; [email-masked]
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Adrian (and Alvaro) -

Saying 

NIT: s/Gorup/Group

"the DE must

    Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 18 Nov 2020 06:41:22 +0000

Adrian -

Inline.

> Sent: Tuesday, November 17, 2020 9:50 PM

> To: Les Ginsberg (ginsberg) <[email-masked]>; 'Alvaro Retana'

> <[email-masked]>; [email-masked]

> Not at all! As you may have seen, Alvaro and I had reached the point of

> needing additional eyes.

> > It seems you have largely retained the text from

> https://tools.ietf.org/html/rfc7752#section-5.1

> > https://www.rfc-editor.org/rfc/rfc7370.html#section-4 ? (which - as you

> may recall - you actually

[Les:] You are clearly a "man for all WGs". 😊

> Is that schizophrenia? Not completely. In 7752 and now in this document, I

> am not representing my opinion on what the IANA section should say or how

> DE guidance should be expressed; I am trying to represent the IDR view of

> how they want their registries run.

> > 1)It seems to be somewhat ambiguous as to whether a document is

> required.

> My understanding of what the WG wanted was to allow a request for a

> codepoint to be made from "outside" the IETF by simply making a request.

> Since "the DE is expected to check the clarity of purpose and use of the

> requested code points" I would expect some brief documentation (probably

> an email).

> But if "the request comes from within the IETF, it should be documented in

> an Internet-Draft."

[Les:] Speaking for myself, I do not really want an assignment to be made w/o a document - nor do I see the need to do so. I think the text in RFC 7370 provides sufficient flexibility - but if the WG wants to allow some other form of document not specified there that could certainly be discussed and added.

> > "post the request to  the IDR Working Gorup mailing list (or a successor

> mailing list

[Les:] I agree that IDR need not be the only WG. We seem to be encouraging the inclusion of BGP-LS codepoint definitions in non-IDR documents as a means of reducing the number of documents needed - so I think this point is relevant even if IDR is still alive.

   Les

> Even if #1 ends up requiring documentation, that documentation is not

> necessarily:

> > RFC 7370 does not make this explicit statement, but clearly this is

> > desirable/required.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 18 Nov 2020 17:52:47 +0000

I agree with Les that Designated Expert (DE) guidance similar to RFC 7370 is better. Also, such allocation requests should be fully transparent to both the IDR and LSR WG lists.

Thanks,
Acee

From: Idr <[email-masked]> on behalf of "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
Date: Wednesday, November 18, 2020 at 1:43 AM
To: Adrian Farrel <[email-masked]>, Alvaro Retana <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: IDR List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-registry-01

Adrian -

Inline.

   Les