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" <[email protected]> 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 <[email protected]> wrote: >> >> >>>> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes <[email protected]> >>> 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 >> >>
