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 <o...@delong.com> wrote: > > > On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes <yard...@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 > >
