[178883] in North American Network Operators' Group
Re: BCOP appeals numbering scheme -- feedback requested
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Mar 12 19:50:02 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com>
Date: Thu, 12 Mar 2015 16:48:18 -0700
To: "Yardiel D. Fuentes" <yardiel@gmail.com>
Cc: bcop-support@nanog.org, nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes <yardiel@gmail.com> =
wrote:
>=20
>=20
>=20
> Hello NANOGers,
>=20
> 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.
>=20
> The BCOP committee is looking for feedback and comments on this topic.
>=20
> Currently, the below numbering scheme is being considered:
>=20
> A proposed numbering scheme can be based on how the appeals appeals in =
the BCOP topics are presented as shown below:
>=20
> http://bcop.nanog.org/index.php/Appeals
>=20
> 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:
>=20
> BCP Range Area of Practice
> 100 - 199 EBGPs =09
> 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
>=20
> 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 ...
>=20
> 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=E2=80=99s 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 =E2=80=9Cobsoleted by XXXXX=E2=80=9D and =
it=E2=80=99s document status should reflect =E2=80=9CObsoletes XXXX, =
XXXX, and XXXX=E2=80=9D for all previous revisions. The index should =
probably reflect only BCOPs which have not been obsoleted.
Just my $0.02.
Owen
