nanog mailing list archives
Re: BCOP appeals numbering scheme -- feedback requested
From: Owen DeLong <owen () delong com>
Date: Fri, 13 Mar 2015 17:54:26 -0700
It does, but for BCOP, I do think it would be best if the new document completely obsoleted the previous document and still relevant content was copied into the new document rather than leaving merge as an exercise. Owen
On Mar 13, 2015, at 17:06 , Phil Bedard <bedard.phil () gmail com> wrote: The RFC index is updated when a new RFC updates or obsoletes one or more existing RFCs. The old entry has pointers to the new RFCs and vice-versa. Now which parts are updated is usually left as an exercise but it's usually not too hard to figure out. There is also an errata system in place. I think the system works fairly well. Phil -----Original Message----- From: "Lee Howard" <Lee () asgard org> Sent: 3/13/2015 3:51 PM To: "Mel Beckman" <mel () beckman org>; "Rick Casarez" <rick.casarez () gmail com> Cc: "bcop-support () nanog org" <bcop-support () nanog org>; "nanog () nanog org" <nanog () nanog org> Subject: Re: BCOP appeals numbering scheme -- feedback requested I think the RFC numbering system is a terrible scheme. As Wes described, you have a document purporting to describe something, with no indicator that parts of it have been rendered obsolete by parts of other documents. I pity implementors who have to figure it all out. I also agree with Joel, that assigning meaning to index numbers is a bad idea. It leads to crossed indexes and unclear references. For the documents to be useful, one should be able to read a single document on a topic. When that topic is too big for a single document, split the document. When something in one document supersedes something in another, confirm consensus and update the canonical document. If that's too dynamic for people, then maintain the index, and when part of a document is obsoleted, the entire updated document should be republished with a new number, and the old one marked "obsoleted by XXXX." Under no circumstances would I support a limited number space. Lee On 3/13/15 2:26 PM, "Mel Beckman" <mel () beckman org> wrote: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 beckmanOn Mar 13, 2015, at 11:19 AM, "Rick Casarez" <rick.casarez () 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 () 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 tobest 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 inthe 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 eachcategory 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 acounter-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
Current thread:
- Re: BCOP appeals numbering scheme -- feedback requested, (continued)
- Re: BCOP appeals numbering scheme -- feedback requested Job Snijders (Mar 12)
- Re: BCOP appeals numbering scheme -- feedback requested Tony Tauber (Mar 12)
- Re: BCOP appeals numbering scheme -- feedback requested Job Snijders (Mar 12)
- Re: BCOP appeals numbering scheme -- feedback requested Owen DeLong (Mar 12)
- Re: BCOP appeals numbering scheme -- feedback requested George, Wes (Mar 13)
- Re: BCOP appeals numbering scheme -- feedback requested Andrew Sullivan (Mar 13)
- Re: BCOP appeals numbering scheme -- feedback requested Owen DeLong (Mar 13)
- Re: BCOP appeals numbering scheme -- feedback requested Rick Casarez (Mar 13)
- Re: BCOP appeals numbering scheme -- feedback requested Mel Beckman (Mar 13)
- Re: BCOP appeals numbering scheme -- feedback requested Lee Howard (Mar 13)
- RE: BCOP appeals numbering scheme -- feedback requested Phil Bedard (Mar 13)
- Re: BCOP appeals numbering scheme -- feedback requested Owen DeLong (Mar 13)
- Re: BCOP appeals numbering scheme -- feedback requested William Norton (Mar 14)
- Re: BCOP appeals numbering scheme -- feedback requested Rob Seastrom (Mar 15)
- Re: BCOP appeals numbering scheme -- feedback requested Charles N Wyble (Mar 15)
- Re: BCOP appeals numbering scheme -- feedback requested Rob Seastrom (Mar 15)
- Re: BCOP appeals numbering scheme -- feedback requested Harlan Stenn (Mar 15)
- Supporting network time software development/maintenance (was: Re: BCOP appeals numbering scheme -- feedback requested) Rob Seastrom (Mar 16)
- Re: Supporting network time software development/maintenance (was: Re: BCOP appeals numbering scheme -- feedback requested) Harlan Stenn (Mar 16)
- Re: BCOP appeals numbering scheme -- feedback requested George, Wes (Mar 13)
- Message not available
- Re: BCOP appeals numbering scheme -- feedback requested Lee Howard (Mar 15)
- Re: BCOP appeals numbering scheme -- feedback requested Andrew Sullivan (Mar 15)
- Re: BCOP appeals numbering scheme -- feedback requested Valdis . Kletnieks (Mar 15)