[178925] in North American Network Operators' Group
Re: BCOP appeals numbering scheme -- feedback requested
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Mar 13 20:57:50 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com>
Date: Fri, 13 Mar 2015 17:54:26 -0700
To: Phil Bedard <bedard.phil@gmail.com>
Cc: "bcop-support@nanog.org" <bcop-support@nanog.org>,
"nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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:
>=20
> 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. =20
>=20
> Phil
>=20
> -----Original Message-----
> From: "Lee Howard" <Lee@asgard.org>
> Sent: =E2=80=8E3/=E2=80=8E13/=E2=80=8E2015 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
>=20
> 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.
>=20
> I also agree with Joel, that assigning meaning to index numbers is a =
bad
> idea. It leads to crossed indexes and unclear references.
>=20
> 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.
>=20
> 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."
>=20
> Under no circumstances would I support a limited number space.
>=20
> Lee
>=20
> On 3/13/15 2:26 PM, "Mel Beckman" <mel@beckman.org> wrote:
>=20
>> 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 :)
>>=20
>> -mel beckman
>>=20
>>> On Mar 13, 2015, at 11:19 AM, "Rick Casarez" =
<rick.casarez@gmail.com>
>>> wrote:
>>>=20
>>> I like the idea of an index better than the proposed numbering =
scheme.
>>>=20
>>> -------------------
>>> Cheers, Rick
>>>=20
>>> Experiences not things.
>>>=20
>>>> On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong <owen@delong.com> =
wrote:
>>>>=20
>>>>=20
>>>>>> 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
>>>>> 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 ?
>>>>=20
>>>> 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?
>>>>=20
>>>> I also agree with Joel=C2=B9s comment about identifier/locator =
overload.
>>>> Have
>>>> we learned nothing from the issues created by doing this in IPv4 =
and
>>>> IPv6?
>>>>=20
>>>> Instead, how about maintaining a BCOP subject index which contains
>>>> titular
>>>> and numeric information for each BCOP applicable to the subjects =
above.
>>>>=20
>>>> e.g.:
>>>>=20
>>>> BCOP Subject Index:
>>>>=20
>>>> Subjects:
>>>> 1. EBGP
>>>> 2. IGP
>>>> 3. Ethernet
>>>> 4. Class of Service
>>>> 5. Network Information Processing
>>>> 6. Security
>>>> 7. MPLS
>>>> 8. Generalized
>>>>=20
>>>>=20
>>>> 1. EBGP
>>>> 104 lorem ipsum
>>>> 423 ipsum lorem
>>>>=20
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> Note, IMHO, a revised BCOP should get a new number and the previous
>>>> revision should be marked =C2=B3obsoleted by XXXXX=C2=B2 and it=C2=B9=
s document status
>>>> should reflect =C2=B3Obsoletes XXXX, XXXX, and XXXX=C2=B2 for all =
previous
>>>> revisions.
>>>> The index should probably reflect only BCOPs which have not been
>>>> obsoleted.
>>>>=20
>>>> Just my $0.02.
>>>>=20
>>>> Owen
>>>>=20
>>>>=20
>>=20
>=20
