BCOP appeals numbering scheme -- feedback requested

Mailman List Mirror (Read Only)
1

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 ?

Yardiel Fuentes

2

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:

identifier/locator overload.

giving intergers intrinsic meaning is generally a mistake imho.

3

> 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:

identifier/locator overload.

giving intergers intrinsic meaning is generally a mistake imho.

I agree with Joel

4

Totally. Also, then what if something is in the intersection of multiple
"areas".

Complexity that's not needed.

Tony

5

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

6

I like the idea of an index better than the proposed numbering scheme.

7

A note of caution:
Please don't exactly replicate the RFC series's model where the existing
document can only be updated by new documents but is not always completely
replaced/obsoleted such that the reader is left following the trail of
breadcrumbs across multiple documents trying to figure out what the union
of the two (or 3 or 14) "current" documents actually means in terms of the
complete guidance. If what you're suggesting is actually a full
replacement of the document so that the new version is complete and
standalone, I think that's better, but really I don't understand why these
can't be more living documents (like a Wiki) instead of just using the
server as a public dropbox for static files. The higher the drag for
getting updates done, the more likely they are to go obsolete and be less
useful to the community.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.

8

I have to agree with this. RFCs are the way they are because they
represent an archival series (and even so, probably we could do a
better job with this). The whole reasoning to create a completely new
series with separate ways of creation was supposedly that the RFC
series and BCPs didn't do what the community needed. It seems to me
that one of the most important differences in operational guidance is
that old operational guidance goes away when it is superseded by
changed operational conditions, so there's no reason to keep the old
documents around except as historical artifacts. If people want an
archive for historians' use, I'm ok with it. But it seems to me that
updating a document of the same number (and making them version
numbered too) would be more useful. Then you could always refer to
"BCOP 1234" for "Carrier Pigeon Operational Practices", and wouldn't
need to update references and so on.

Best regards,

A

9

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 :slight_smile:

-mel beckman

10

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

11

You'll get more comments about the numbering scheme than any actual BCOP...

12

Agreed. A new document should be a complete replacement and represent the full text recommendation.

Owen

13

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

14

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

15

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.

Agreed - Hence the “Current” in the title. Maybe the date of the document will be the key to let people know that they have the most current version.

16

William Norton <wbn@drpeering.net> writes:

Agreed - Hence the “Current” in the title. Maybe the date of the
document will be the key to let people know that they have the most
current version.

The date of a single document is of scant use in determining its
currency unless there is some sort of requirement for periodic
recertification and gratuitous reissue of BCOPs (for instance,
anything with a date stamp more than 18 months in the past is
by definition invalid). That seems like busy work to periodically
affirm that a good idea is still a good idea, and I don't volunteer
for this job. :slight_smile:

I'm on board for wholesale replacement of the document (with revision
history preserved) rather than the RFC series approach.

The wiki/living document approach others have suggested seems like a
poor one to me, for the same reason that I dislike the current trend
of "there's no release tarball, major release, point release, or
regression testing - just git clone the repository" in free software
development. Releng is hard and thankless but adds enormous value and
serves as a forcing function for some level of review, cursory though
it may be.

-r

17

Use a git repository.
Make tagged releases.

This enables far easier distributed editing, translating, mirroring etc. And you can still do whatever release engineering you want.

A wiki is a horrible solution for something like this.

18

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.

19

Charles N Wyble <charles@thefnf.org> writes:

Use a git repository.
Make tagged releases.
This enables far easier distributed editing, translating, mirroring etc. And

A fine idea in theory, but not quite as much traction in reality as bcp38.

Creating a need for a BCP for retrieving BCPs so that you get the
right version rather than typing "git clone" and erroneously referring
to whatever is tagged "-develop" seems like a Bad Plan.

It's also not a really reasonable method for distributing
point-in-time documents once people are done with collaborating on
creating them. Most end consumers will not care about the change
history.

you can still do whatever release engineering you want.

Sure.

A wiki is a horrible solution for something like this.

Agree 100%

-r

20

Rob Seastrom writes:

The wiki/living document approach others have suggested seems like a
poor one to me, for the same reason that I dislike the current trend
of "there's no release tarball, major release, point release, or
regression testing - just git clone the repository" in free software
development.

And I like wikis for some things, here it might work (I haven't looked)
and I still do release tarballs with version numbers and some (we're
actively adding more) regression/unit/functional testing.

Releng is hard and thankless

:slight_smile:

but adds enormous value and
serves as a forcing function for some level of review, cursory though
it may be.

I think so too.

Hey everybody, please support Network Time. Spread the word. OK, I said it.