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

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Adrian,

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

Thanks,
Ketan

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

Adrian -

Inline.

> -----Original Message-----
> From: Adrian Farrel <[e-mail]>
> Sent: Wednesday, December 09, 2020 1:37 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>; 'IDR List' 
> <[e-mail]>
> Cc: [e-mail]
> Subject: RE: [Idr] Changes to draft-ietf-idr-bgp-ls-registry
> 
> 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.
> 

[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.


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

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

   Les

> Cheers,
> Adrian
> 
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <[e-mail]>
> Sent: 09 December 2020 01:12
> To: [e-mail]; 'IDR List' <[e-mail]>
> Cc: [e-mail]
> 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 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
> 
> 
> 
> > -----Original Message-----
> > From: Idr <[e-mail]> On Behalf Of Adrian Farrel
> > Sent: Tuesday, December 08, 2020 12:45 PM
> > To: 'IDR List' <[e-mail]>
> > Cc: [e-mail]
> > Subject: [Idr] Changes to draft-ietf-idr-bgp-ls-registry
> >
> > 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
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr

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