Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

["John G. Scudder" <[e-mail]>]

Robert,

> On Nov 1, 2016, at 10:30 AM, Robert Raszuk <[e-mail]> wrote:
> 
> Hi John,
> 
> From IDR WG standpoint could you state clearly the process for Early Allocation of Attribute Types, Message Types or AFI/SAFIs codepoints ? 

It's spelled out in RFC 7120. The RFC is short, so summarizing it is kind of redundant, basically just look at sections 2 and 3.1 (approx 1 page of text). 

> Does the process differ between IETF WGs ? Say if BESS will try to do also early allocation for given BGP Attribute Type ? 

There could be some variability between working groups since two of the RFC 7120 Section 3.1 steps involve working group chairs using their judgment:

   2.  The WG chairs determine whether the conditions for early
       allocations described in Section 2 are met, particularly conditions (c) and (d).

FYI, condition (c) requires there to be a stable specification, condition (d) requires there to be "sufficient interest in the community".

   3.  The WG chairs gauge whether there is consensus within the WG that
       early allocation is appropriate for the given document.

Sue and I have chosen to gauge this by means of a two-week consensus call, as we do with other working group consensus items. This also serves to confirm conditions (c) and (d). 

> I think this is the key here and root of the problem. 

FWIW, I don't.

> If we require interoperable implementations for any draft to proceed WG should enable authors to create those implementations in the first place. 

I'm not aware of there having been an early allocation request for any of the code points in question.

 Regards,

--John

> 
> Thx a lot,
> Robert.
> 
> 
> On Tue, Nov 1, 2016 at 3:23 PM, John G. Scudder <[e-mail]> wrote:
> AFAICT the function of the draft is simply to kick the IANA code point state to "deprecated". It doesn't anchor it there for all time. Presumably a later request can move the state to assigned or whatever, as we've previously discussed. I don't think any update to the current "deprecate" document would be needed to achieve this (I guess maybe the later document might list this one in its "updates" header).
> 
> I'll confirm this understanding with IESG and IANA before the end of the WG adoption call. (Unless someone can point me to chapter-and-verse of a reference that explains the process clearly enough, unfortunately I have not found such.)
> 
> Thanks,
> 
> --John
> 
>> On Nov 1, 2016, at 10:02 AM, Robert Raszuk <[e-mail]> wrote:
>> 
>> Hi Job,
>> 
>> Have you consider marking those codepoints as "RESERVED" rather then "DEPRECIATED". 
>> 
>> Reason being that if any of the applications they have been squatted on behalf of want to use them - it would be pretty easy to allocate them.
>> 
>> The other alternative would be to allocate them to those applications now (for which the drafts exist) as IANA early allocations. If you depreciate them now and we know that as example Contrail Multicast is important either your draft will need to quickly be moved to historic or yet another types will need to be allocated again. 
>> 
>> In any of the above Large Communities will get virgin BGP attribute type which I believe is the main point here.
>> 
>> Cheers,
>> R.
>> 
>> 
>> On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <[e-mail]> wrote:
>> Dear working group,
>> 
>> To prevent having multiple drafts in quick succession covering the same
>> style of issue - I'd like your feedback on the following:
>> 
>> I believe that bgp path attribute 241, 242, 243 should also be added to
>> this draft for the same reasons as 30, 31 and 129 are listed.
>> 
>> OLD:
>>     This document requests IANA to deprecate the following BGP Path
>>     attributes: 30, 31, and 129.
>> 
>> NEW:
>>     This document requests IANA to deprecate the following BGP Path
>>     attributes: 30, 31, 129, 241, 242, and 243.
>> 
>> Does anyone object? If so, why?
>> 
>> Unilaterally changing the document while in its mid-flight through the
>> working group adoption process might be considered bad form, hence my
>> request for feedback on the 241,242,243 topic.
>> 
>> Please note - the deprecation of an attribute can be undone if proper
>> process is followed. The priority here is to prevent IANA from assigning
>> tainted codepoints to innocent bystanders, thus a deprecation document
>> needs to exist. In time the working group has the power to undeprecate
>> them for specific purposes.
>> 
>> Kind regards,
>> 
>> Job
>> 
>> On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:
>> > Hi Everyone,
>> >
>> > The author has asked for the WG to adopt  draft-snijders-idr-deprecate-30-31-129.
>> >
>> > If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option of doing nothing, so if you oppose adoption please address what you think should be done instead.
>> >
>> > The adoption call will end November 13.
>> >
>> > Thanks,
>> >
>> > --John
>> >
>> > P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01
>> >
>> > Abstract
>> >
>> >    This document requests IANA to deprecate the following BGP path
>> >    attributes values: 30, 31 and 129.
>> >
>> >
>> > _______________________________________________
>> > Idr mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/idr
>> 
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>> 
> 
>