[178907] in North American Network Operators' Group
Re: BCOP appeals numbering scheme -- feedback requested
daemon@ATHENA.MIT.EDU (Rick Casarez)
Fri Mar 13 14:18:59 2015
X-Original-To: nanog@nanog.org
In-Reply-To: <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com>
Date: Fri, 13 Mar 2015 08:10:06 -0400
From: Rick Casarez <rick.casarez@gmail.com>
To: nanog@nanog.org
Cc: bcop-support@nanog.org
Errors-To: nanog-bounces@nanog.org
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 reference=
s.
> 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 situatio=
n
> 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 overloa=
d. 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 titula=
r
> 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 p=
revious revisions.
> The index should probably reflect only BCOPs which have not been obsolete=
d.
>
> Just my $0.02.
>
> Owen
>
>
