Subject: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 8 Dec 2020 20:44:53 -0000

Hi,

Thanks to all for the useful input and sorry for the long delay while
"things" got in the way.

I made some changes to the draft according to Alvaro's comments and then
updated the DE guidance per the discussions on list.

Ketan noted that point 6 of the guidance in RFC 7370 talks about "timeouts"
per RFC 7120. That only applies to early allocations, and that's not what
we're doing. I think it is still worth carrying text about what happens if
the document never becomes an RFC, so I have retained something similar, but
different. I hope this is consistent with what Les said.

Acee additionally suggested that code point requests should be "fully
transparent to the LSR list". I haven't added this, but it would be simple
to do if there is support for it.

Since the text changes are pretty much the whole draft, the easiest thing
seems to be to post an update and then invite you to review and comment. So
that's what I have done.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-registry

Cheers,
Adrian

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 8 Dec 2020 17:21:15 -0500

Adrian: 

Since I do not want things to "get it the way", 
Let  me ask if you are ready for another WG LC on this text? 

Sue

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, December 8, 2020 3:45 PM
To: 'IDR List'
Cc: [email-masked]
Subject: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

Hi,

Cheers,
Adrian

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 9 Dec 2020 01:11:58 +0000

Adrian -

Thanx - as always - for your diligence.
I think this revision is consistent with the outcome of the email discussion.

I am concerned about Section 2.1 #8:

"In the event that the document fails to progress to RFC, the
       Working Group chairs or AD SHOULD contact the Designated Expert
       to coordinate with IANA over marking the code points as
       deprecated following similar principles to Section 3.3 of
       [RFC7120]."

I think the phrase "similar principles" leaves the door open to lots of ambiguity. If you do not want to follow RFC 7120 Section 3.3, what do you want to do? How much deviation from RFC 7120 Section 3.3 before "similar" does not apply? I do not think leaving this a bit vague is desirable.

I am also not clear on why you say (below) that we are not doing early allocations. If these aren't early allocations, what are they? Which also makes me wonder why you could not simply say "follow RFC 7120 Section 3.3"??

  Les

> From: Idr <[email-masked]> On Behalf Of Adrian Farrel
> Sent: Tuesday, December 08, 2020 12:45 PM
> To: 'IDR List' <[email-masked]>
> Cc: [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 9 Dec 2020 09:36:55 -0000

OK, thanks Les.

Best to start with "why aren't these early allocations?" 

Early allocation is a process to get around Standards Action, IETF Review,
and RFC Required by setting rules under which code points from those types
of registry can be allocated in advance of the completion of the RFC
process. 7120 includes that IANA timestamps the allocations, and that early
allocations expire automatically. They also require that I-Ds are
sufficiently stable that the meanings of code points will not change before
the RFC is published.

My understanding of the wishes of the IDR WG is that they consider early
allocation to be too restrictive. Firstly, it comes too late in the process
(IOW the stability of the draft normally requires that a code point cannot
be allocated until close to WG last call). Secondly, the process involves
the chairs and AD signing off along with the DEs, and so is too heavy and
laborious (aka slow). And additionally, early allocation requires that
attention is paid to renewing the allocations every year until the RFC is
published.

The change, therefore, was to make the registries Expert Review precisely to
not use 7120.

I agree "similar" is a Bad Word (TM). It was my intention only to indicate
that the use of deprecation was similar to deprecation in 7120, but in this
case, more words would be better. So...

OLD (-02)
   8.  In the event that the document fails to progress to RFC, the
       Working Group chairs or AD SHOULD contact the Designated Expert
       to coordinate with IANA over marking the code points as
       deprecated following similar principles to Section 3.3 of
       [RFC7120].
NEW
   8.  In the event that the document fails to progress to RFC, the
       Working Group chairs or AD SHOULD contact the Designated Expert
       to coordinate with IANA over marking the code points as
       deprecated.  A deprecated code point is not marked as allocated
       for use and is not available for allocation in a future document.
       The WG chairs may inform IANA that a deprecated code point can be
       completely de-allocated (i.e., made available for new
       allocations) at any time after it has been deprecated if there is
       a shortage of unallocated code points in the registry.
END

Cheers,
Adrian

-----Original Message-----
From: Les Ginsberg (ginsberg) <[email-masked]> 
Sent: 09 December 2020 01:12
To: [email-masked]; 'IDR List' <[email-masked]>
Cc: [email-masked]
Subject: RE: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

Adrian -

Thanx - as always - for your diligence.
I think this revision is consistent with the outcome of the email
discussion.

I think the phrase "similar principles" leaves the door open to lots of
ambiguity. If you do not want to follow RFC 7120 Section 3.3, what do you
want to do? How much deviation from RFC 7120 Section 3.3 before "similar"
does not apply? I do not think leaving this a bit vague is desirable.

I am also not clear on why you say (below) that we are not doing early
allocations. If these aren't early allocations, what are they? Which also
makes me wonder why you could not simply say "follow RFC 7120 Section 3.3"??

  Les

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 9 Dec 2020 09:38:51 -0000

Hi Sue,

Looks like Les and I are still fiddling with the words.

Give it another day or two and I'll shout.

Thanks,
Adrian

-----Original Message-----
From: Susan Hares <[email-masked]> 
Sent: 08 December 2020 22:21
To: [email-masked]; 'IDR List' <[email-masked]>
Cc: [email-masked]
Subject: RE: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

Adrian: 

Sue

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, December 8, 2020 3:45 PM
To: 'IDR List'
Cc: [email-masked]
Subject: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

Hi,

Cheers,
Adrian

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 9 Dec 2020 18:36:16 +0000

Adrian -

Inline.

> From: Adrian Farrel <[email-masked]>
> Sent: Wednesday, December 09, 2020 1:37 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>; 'IDR List' <[email-masked]>
> Cc: [email-masked]

[Les:] I think what  the draft is proposing is "early allocation". There are just some processes as defined in RFC 7120 that you do not want to follow - which I think is fine. IS-IS did much the same in RFC 7370.
To me, the more apt description is "early allocation with IDR specific guidance to the DEs".
But perhaps this is quibbling.

>        a shortage of unallocated code points in the registry.

[Les:] I am good with this revised text.
Thanx.

   Les

> > seems to be to post an update and then invite you to review and
> comment.
> > So
> > that's what I have done.
> >

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 9 Dec 2020 18:40:13 +0000

Hi Adrian,

+1 as well for the new/proposed text change.

Thanks,
Ketan

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: 10 December 2020 00:06
To: [email-masked]; 'IDR List' <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

Adrian -

Inline.

> Early allocation is a process to get around Standards Action, IETF 
> Review, and RFC Required by setting rules under which code points from 
> those types of registry can be allocated in advance of the completion 
> of the RFC process. 7120 includes that IANA timestamps the 
> allocations, and that early allocations expire automatically. They 
> also require that I-Ds are sufficiently stable that the meanings of 
> code points will not change before the RFC is published.
> 
> My understanding of the wishes of the IDR WG is that they consider 
> early allocation to be too restrictive. Firstly, it comes too late in 
> the process (IOW the stability of the draft normally requires that a 
> code point cannot be allocated until close to WG last call). Secondly, 
> the process involves the chairs and AD signing off along with the DEs, 
> and so is too heavy and laborious (aka slow). And additionally, early 
> allocation requires that attention is paid to renewing the allocations 
> every year until the RFC is published.
> 

> The change, therefore, was to make the registries Expert Review 
> precisely to not use 7120.
> 
> I agree "similar" is a Bad Word (TM). It was my intention only to 
> indicate that the use of deprecation was similar to deprecation in 
> 7120, but in this case, more words would be better. So...
> 
> OLD (-02)

   Les

> I think the phrase "similar principles" leaves the door open to lots 
> of ambiguity. If you do not want to follow RFC 7120 Section 3.3, what 
> do you want to do? How much deviation from RFC 7120 Section 3.3 before "similar"
> allocations. If these aren't early allocations, what are they? Which 
> also makes me wonder why you could not simply say "follow RFC 7120 
> Section 3.3"??
> 
>   Les
> 
> 
> 
> > Thanks to all for the useful input and sorry for the long delay 
> > while "things" got in the way.
> >
> > I made some changes to the draft according to Alvaro's comments and 
> > then updated the DE guidance per the discussions on list.
> >
> > per RFC 7120. That only applies to early allocations, and that's not 
> > what we're doing. I think it is still worth carrying text about what 
> > happens if the document never becomes an RFC, so I have retained 
> > something similar, but different. I hope this is consistent with 
> > what Les said.
> >
> > Acee additionally suggested that code point requests should be 
> > "fully transparent to the LSR list". I haven't added this, but it 
> > would be simple to do if there is support for it.
> >
> > Since the text changes are pretty much the whole draft, the easiest 
> > thing seems to be to post an update and then invite you to review 
> > and
> comment.
> > So
> > that's what I have done.
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 9 Dec 2020 19:36:12 -0000

Hi again, Sue.

-03 is now posted and I believe it addresses all outstanding issues.

A last call now would be perfect.

Alvaro, if you are able to pipeline your review, that would be handy.

Cheers,
Adrian

-----Original Message-----
From: Susan Hares <[email-masked]> 
Sent: 08 December 2020 22:21
To: [email-masked]; 'IDR List' <[email-masked]>
Cc: [email-masked]
Subject: RE: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

Adrian: 

Sue

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, December 8, 2020 3:45 PM
To: 'IDR List'
Cc: [email-masked]
Subject: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

Hi,

Cheers,
Adrian