Re: BCOP appeals numbering scheme -- feedback requested
On 3/13/15 5:14 PM, "mel@becknet.com" <mel@becknet.com> wrote:
Lee,
On the contrary, I think RFCs are pretty consistent about always referring you to any superseding RFCs, and superseding RFCs reference their predecessors, creating a very useful historical doubly-linked list. I've served on IEEE committees that follow a decimal/alpha/french numbering system, in which it is very hard to track the history of a standard.
RFCs, on the other hand, tend to be concisely written and well annotated with background materials. What's more, RFCxxxx makes an excellent unique internet-global search term.
You've made the assertion that RFC numbering is terrible. Can you provide some examples?
The canonical version of the RFC is the plain text version. So here's RFC6204: http://www.rfc-editor.org/rfc/rfc6204.txt No notes about being obsolete. If you want, you can find two other versions officially published, the "tools version" and the "datatracker version": https://tools.ietf.org/html/rfc6204 https://datatracker.ietf.org/doc/rfc6204/ Both of those tell you that this RFC has been obsoleted by RFC7084. But here's one: https://tools.ietf.org/html/rfc791 Let's say I want to implement this protocol. Looks pretty straightforward, once I've read the errata and the three RFCs that obsolete it. The first of those three is RFC1349, which also has been obsoleted by RFC2474, which in turn has been obsoleted by RFC3168 and RFC3260, the first of which is obsoleted by RFC4301 and RFC6040. I didn't follow the other chains of obsoleting documents. How many documents do I have to read if I want to implement this protocol? Ha, ha, you say, nobody's trying to write an IP implementation from scratch. Au contraire, IPv6 is defined in https://tools.ietf.org/html/rfc2460, which lists nine RFCs updating it, plus errata. And while I agree with you that "RFC2460" is an easy, unique search term, it isn't exactly memorable. "I need to write an IPv6 stack for my new ThingOS; what do I need to read?" And one of my least favorite comments at the mic at IETF is, "Have you even read RFC6214?" [1] Because the author is standing there with no way to look up what that particular number means. I know, I should really be having this rant in the RFC evolution WG, or with the RFC editor. It just came up here, and I want BCOP to make different mistakes on useful documents. Lee [1] I included this reference in an RFI, to catch vendors who were only cutting and pasting marketing materials.
-mel beckman
On Mar 13, 2015, at 12:50 PM, "Lee Howard" <Lee@asgard.org> wrote:
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 beckman
On 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 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
On Sun, Mar 15, 2015 at 11:40:27AM -0400, Lee Howard wrote:
I know, I should really be having this rant in the RFC evolution WG, or with the RFC editor. It just came up here, and I want BCOP to make different mistakes on useful documents.
Even if you suppose that the RFC series is arranged ideally, or for that matter if you assume that, given established practice, fixing the RFC series is impossible, that _still_ doesn't make the RFC series a good model. In fact, of course, the RFC series actually has an overlay on it that is intended to be much more like BCOP, which is the BCP series. The thing about the BCP series is that a BCP's number doesn't change even if the document(s) making it up do. That's why (say) BCP 9 is the Internet standards process regardless of whether that's RFC 1602 or 2026-and-updates or whatever. I think that sort of thing is useful, because people can learn the right shorthand for "whatever one is doing now on topic X" and just refer people to that. I don't care if it's "BCOP 32006.1234" or "BCOP on foobar of whazit", but a consistent reference people can go to for the current version is the important feature. I also think that trying to pack more bits of information into the numbering system is a mistake. But then, I would. I think you look those sorts of things up (in the DNS, of course ;-) ) A -- Andrew Sullivan Dyn asullivan@dyn.com
On Sun, 15 Mar 2015 19:14:05 -0400, Andrew Sullivan said:
I also think that trying to pack more bits of information into the numbering system is a mistake. But then, I would. I think you look those sorts of things up (in the DNS, of course ;-) )
DANE? :)
participants (3)
-
Andrew Sullivan -
Lee Howard -
Valdis.Kletnieks＠vt.edu