BCOP appeals numbering scheme -- feedback requested
Rick Casarez
rick.casarez at gmail.com
Fri Mar 13 12:10:06 UTC 2015
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
>
>
More information about the NANOG
mailing list