Re: BCOP appeals numbering scheme -- feedback requested

[Rick Casarez <rick.casarez () gmail com>]

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 () delong com> wrote:

> > On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes <yardiel () 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