Re: [Idr] Early allocations and other ways to avoid squatting on code points

+1. 

Regards,
Keyur

Sent from my iPhone

> On Nov 1, 2016, at 9:44 AM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> I support an early attribute code allocation for wide communities.
> I'm happy for it to have 129 if that's what it's been using.
> Of course, it's not my call to make, just my opinion.
> 
> Thanks,
> Jakob.
> 
> 
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder
>> Sent: Tuesday, November 01, 2016 8:05 AM
>> To: Robert Raszuk <robert@raszuk.net>
>> Cc: IETF IDR Working Group <idr@ietf.org>
>> Subject: [Idr] Early allocations and other ways to avoid squatting on code points
>> 
>> I have changed the subject line to reflect the fact we are off on a tangent and no longer relevant to adoption of
>> the draft in question.
>> 
>>> On Nov 1, 2016, at 10:41 AM, Robert Raszuk <robert@raszuk.net> wrote:
>>> Few days back You and others complained that Wide was not implemented by anyone for so many years. Now when we see
>> it actually was implemented at least by few BGP code basis it is again bad.
>> 
>> I'm not sure what you mean by "it is again bad" but see the message I just sent -- we were not asked for an
>> allocation for the code base in question (not sure what other code bases you are including in "few", I think one was
>> reported).
>> 
>> When the question of early allocation for wide came up recently (I don't recall if it was on the list, in private
>> email, in conversation or what, sorry) my feedback was to ask whether wide satisfies the stability requirement given
>> in RFC 7120 Section 2 (c). Certainly if there is need for an allocation for wide and it can satisfy the RFC 7120
>> requirements, let's do it. If it can't satisfy the requirements, read on:
>> 
>>> So to me the problem we need to solve is how to allow early implementations for any proposal on the table
>> especially now when we have no two but at least 8 production BGP implementations (and growing). Forbidding it does
>> not seems to me like a solution to the main problem.
>> 
>> I expect we will be discussing this at our upcoming meeting, although that's no reason not to continue the
>> conversation on the list right now, on the contrary. Jeff has also written a draft that tries to address the problem,
>> he posted a pointer to it yesterday, https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/
>> 
>> Thanks,
>> 
>> --John
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr