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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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