BCOP appeals numbering scheme -- feedback requested

Fri Mar 13 18:26:46 UTC 2015

The index scheme has worked very well with RFCs, and has the added advantage of their index numbers becoming handy memes. I strongly urge  Nanog to take advantage of the RFC system's success. There is no shortage of monotonically ascending integers :)

 -mel beckman

> On Mar 13, 2015, at 11:19 AM, "Rick Casarez" <rick.casarez at gmail.com> wrote:
> 
> I like the idea of an index better than the proposed numbering scheme.
> 
> -------------------
> Cheers, Rick
> 
> Experiences not things.
> 
>> On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong <owen at delong.com> wrote:
>> 
>> 
>>>> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes <yardiel at gmail.com>
>>> wrote:
>>> 
>>> 
>>> 
>>> Hello NANOGers,
>>> 
>>> The  NANOG BCOP committee is currently considering strategies on how to
>> best create a numbering scheme for the BCOP appeals. As we all know, most
>> public technical references (IETF, etc) have numbers to clarify references.
>> The goal is for NANOG BCOPs to follow some sort of same style.
>>> 
>>> The BCOP committee is looking for feedback and comments on this topic.
>>> 
>>> Currently, the below numbering scheme is being considered:
>>> 
>>> A proposed numbering scheme can be based on how the appeals appeals in
>> the BCOP topics are presented as shown below:
>>> 
>>> http://bcop.nanog.org/index.php/Appeals
>>> 
>>> 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:
>>> 
>>> 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
>>> 
>>> 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 ...
>>> 
>>> Comments or Thoughts ?
>> 
>> The problem with any such numbering scheme is how you handle the situation
>> when you exhaust the avaialble number space. What happens with the 101st
>> EBGP BCOP, for example?
>> 
>> I also agree with Joel’s comment about identifier/locator overload. Have
>> we learned nothing from the issues created by doing this in IPv4 and IPv6?
>> 
>> Instead, how about maintaining a BCOP subject index which contains titular
>> and numeric information for each BCOP applicable to the subjects above.
>> 
>> e.g.:
>> 
>> BCOP Subject Index:
>> 
>> Subjects:
>>        1.      EBGP
>>        2.      IGP
>>        3.      Ethernet
>>        4.      Class of Service
>>        5.      Network Information Processing
>>        6.      Security
>>        7.      MPLS
>>        8.      Generalized
>> 
>> 
>> 1.      EBGP
>>        104             lorem ipsum
>>        423             ipsum lorem
>> 
>> 
>> 
>> 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.
>> 
>> Note, IMHO, a revised BCOP should get a new number and the previous
>> revision should be marked “obsoleted by XXXXX” and it’s document status
>> should reflect “Obsoletes XXXX, XXXX, and XXXX” for all previous revisions.
>> The index should probably reflect only BCOPs which have not been obsoleted.
>> 
>> Just my $0.02.
>> 
>> Owen
>> 
>> 