[178909] in North American Network Operators' Group
Re: BCOP appeals numbering scheme -- feedback requested
daemon@ATHENA.MIT.EDU (Mel Beckman)
Fri Mar 13 14:26:52 2015
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Rick Casarez <rick.casarez@gmail.com>
Date: Fri, 13 Mar 2015 18:26:46 +0000
In-Reply-To: <CAGWMUT7hHZ6VaQk9Sotzf2NyiqZ_M_wBX=ZGNdsWWAaLAjSaEA@mail.gmail.com>
Cc: "bcop-support@nanog.org" <bcop-support@nanog.org>,
"nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
The index scheme has worked very well with RFCs, and has the added advantag=
e of their index numbers becoming handy memes. I strongly urge Nanog to ta=
ke advantage of the RFC system's success. There is no shortage of monotonic=
ally ascending integers :)
-mel beckman
> On Mar 13, 2015, at 11:19 AM, "Rick Casarez" <rick.casarez@gmail.com> wro=
te:
>=20
> I like the idea of an index better than the proposed numbering scheme.
>=20
> -------------------
> Cheers, Rick
>=20
> Experiences not things.
>=20
>> On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong <owen@delong.com> wrote:
>>=20
>>=20
>>>> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes <yardiel@gmail.com>
>>> wrote:
>>>=20
>>>=20
>>>=20
>>> Hello NANOGers,
>>>=20
>>> The NANOG BCOP committee is currently considering strategies on how to
>> best create a numbering scheme for the BCOP appeals. As we all know, mos=
t
>> public technical references (IETF, etc) have numbers to clarify referenc=
es.
>> The goal is for NANOG BCOPs to follow some sort of same style.
>>>=20
>>> The BCOP committee is looking for feedback and comments on this topic.
>>>=20
>>> Currently, the below numbering scheme is being considered:
>>>=20
>>> A proposed numbering scheme can be based on how the appeals appeals in
>> the BCOP topics are presented as shown below:
>>>=20
>>> http://bcop.nanog.org/index.php/Appeals
>>>=20
>>> In the above page, the idea is to introduce a 100-th range for each
>> category and as the BCOPs. This way a 100th number range generally
>> identifies each of the categories we currently have. An example is:
>>>=20
>>> BCP Range Area of Practice
>>> 100 - 199 EBGPs
>>> 200 - 299 IGPs
>>> 300 - 399 Ethernet
>>> 400 - 499 Class of Service
>>> 500 - 599 Network Information Processing
>>> 600 - 699 Security
>>> 700 - 799 MPLS
>>> 800 - 899 Generalized
>>>=20
>>> An arguable objection could be that the range is limited...but a
>> counter-argument is that considering more than 100 BCOPs would be either=
a
>> great success or just a sign of failure for the NANOG community ...
>>>=20
>>> Comments or Thoughts ?
>>=20
>> The problem with any such numbering scheme is how you handle the situati=
on
>> when you exhaust the avaialble number space. What happens with the 101st
>> EBGP BCOP, for example?
>>=20
>> I also agree with Joel=92s comment about identifier/locator overload. Ha=
ve
>> we learned nothing from the issues created by doing this in IPv4 and IPv=
6?
>>=20
>> Instead, how about maintaining a BCOP subject index which contains titul=
ar
>> and numeric information for each BCOP applicable to the subjects above.
>>=20
>> e.g.:
>>=20
>> BCOP Subject Index:
>>=20
>> Subjects:
>> 1. EBGP
>> 2. IGP
>> 3. Ethernet
>> 4. Class of Service
>> 5. Network Information Processing
>> 6. Security
>> 7. MPLS
>> 8. Generalized
>>=20
>>=20
>> 1. EBGP
>> 104 lorem ipsum
>> 423 ipsum lorem
>>=20
>>=20
>>=20
>> Then, just like the RFCs, maintain the BCOP appeal numbering as a
>> sequential monotonically increasing number and make the BCOP editor
>> responsible for updating the index with the publishing of each new or
>> revised BCOP.
>>=20
>> Note, IMHO, a revised BCOP should get a new number and the previous
>> revision should be marked =93obsoleted by XXXXX=94 and it=92s document s=
tatus
>> should reflect =93Obsoletes XXXX, XXXX, and XXXX=94 for all previous rev=
isions.
>> The index should probably reflect only BCOPs which have not been obsolet=
ed.
>>=20
>> Just my $0.02.
>>=20
>> Owen
>>=20
>>=20
