Totally. Also, then what if something is in the intersection of multiple "areas". Complexity that's not needed. Tony On Thu, Mar 12, 2015 at 3:12 PM, Job Snijders <job@instituut.net> wrote:

On Mar 12, 2015 8:08 PM, "joel jaeggli" <joelja@bogus.com> wrote:

...

On 3/12/15 12:01 PM, Yardiel D. Fuentes wrote:

...

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

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

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

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

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

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

New subject so as to minimize threadjacking, not the least because this is important stuff. Harlan Stenn <stenn@ntp.org> writes:

...

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.

I think so too.

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

The check, as we say, is in the mail (literally). I wish I'd known about Network Time Foundation before you and I started corresponding a little over a week ago about GPS cores.

Harlan Stenn <stenn@ntp.org> http://networktimefoundation.org - be a member!

NANOG colleagues, I know it can be hard getting the employer to pony up for organizations like this, but if correct timestamps in your logs and being able to correlate your packet captures are something you find personally valuable and sanity-preserving, you might consider an individual membership. I know it's pretty important to me... http://nwtime.org/individual-membership-application/ -r

On 3/12/15, 7:48 PM, "Owen DeLong" <owen@delong.com> wrote:

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

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. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

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

On Mar 13, 2015, at 07:37, George, Wes <wesley.george@twcable.com> wrote:

...

On 3/12/15, 7:48 PM, "Owen DeLong" <owen@delong.com> wrote:

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

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

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.