Re: BCOP appeals numbering scheme -- feedback requested

[Lee Howard <Lee () asgard org>]

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