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
On 3/12/15 12:01 PM, Yardiel D. Fuentes 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 referen
On Mar 12, 2015 8:08 PM, "joel jaeggli" 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 examp
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 wrote:
> On Mar 12, 2015 8:08 PM, "joel jaeggli" wrote:
> >
> > On 3/12/15 12:01 PM, Yardiel D. Fuentes wrote:
> > > In the above
> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes 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 c
On 3/12/15, 7:48 PM, "Owen DeLong" 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 s
On Fri, Mar 13, 2015 at 10:37:10AM -0400, George, Wes wrote:
> 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
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 wrote:
>
> > On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes
> wrote:
> >
> >
> >
> > Hello NANOGers,
> >
> > The NANOG
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
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, tha
You'll get more comments about the numbering scheme than any actual BCOP...
On Thu, Mar 12, 2015 at 1:01 PM, Yardiel D. Fuentes
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 al
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 wrote:
>
>> On 3/12/15, 7:48 PM, "Owen DeLong" wrote:
>>
>>
>> Then, just like the RFCs, maintain the BCOP appeal numbering as a
>> sequentia
place. I think the
system works fairly well.
Phil
-Original Message-
From: "Lee Howard"
Sent: 3/13/2015 3:51 PM
To: "Mel Beckman" ; "Rick Casarez"
Cc: "bcop-supp...@nanog.org" ; "nanog@nanog.org"
Subject: Re: BCOP appeals
m in place. I
> think the system works fairly well.
>
> Phil
>
> -Original Message-
> From: "Lee Howard"
> Sent: 3/13/2015 3:51 PM
> To: "Mel Beckman" ; "Rick Casarez"
> Cc: "bcop-supp...@nanog.org" ; "nanog@nan
> On Mar 13, 2015, at 5:54 PM, Owen DeLong wrote:
>
> 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
William Norton 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 requireme
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.
On March 15, 2015 8:24:49 AM CDT, Rob Seastrom wrote:
>
>Wi
On 3/13/15 5:14 PM, "m...@becknet.com" wrote:
>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 committe
Charles N Wyble 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
ri
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 softwa
On Sun, Mar 15, 2015 at 11:40:27AM -0400, Lee Howard wrote:
>
> 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.
Even if you suppose that the RFC series is arrang
On Sun, 15 Mar 2015 19:14:05 -0400, Andrew Sullivan said:
> I also think that trying to pack more bits of information into the
> numbering system is a mistake. But then, I would. I think you look
> those sorts of things up (in the DNS, of course ;-) )
DANE? :)
pgpxZQL3U0mjq.pgp
Description: P
New subject so as to minimize threadjacking, not the least because this is
important stuff.
Harlan Stenn 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 everyb
Rob Seastrom writes:
> New subject so as to minimize threadjacking, not the least because
> this is important stuff.
>
> Harlan Stenn 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.
>>
24 matches
Mail list logo
