Melinda,
Fully true. When you consider it, instead of talking of "running code" we
should in fact talk of "used code". BCP are becoming the architectural key
because they document the brainware: the way people use the technology to
network together. Real experimentation needs to therefore be ca
On 08/07/2005 17:58 PM, Melinda Shore allegedly wrote:
> Scott W Brim wrote:
>
>> Hi Melinda. Are you saying that people shouldn't comment on an idea
>> unless they are implementing it?
>
>
> No, clearly (I hope) not. Just that it seems likely
> that maybe if we did more implementation it coul
Scott W Brim wrote:
Hi Melinda. Are you saying that people shouldn't comment on an idea
unless they are implementing it?
No, clearly (I hope) not. Just that it seems likely
that maybe if we did more implementation it could
help end some of those round-and-round we go discussions
that can ofte
On 08/07/2005 13:43 PM, Melinda Shore allegedly wrote:
> That's an excellent point. To a great extent
> we suffer from what the FreeBSD community calls
> "bikeshed"
> (http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING)
>
> and while I think it's excellent that peopl
I think there is much software publicly released by vendors for
standards track protocols. And there's a lot more protocol work being
done by vendors than teams on public research grants. I know
personally that Brian Weis (RFC 3547) and David McGrew (RFC 3711) did
outstanding implementations
grenville armitage wrote:
I wonder if absence of running code, and the apparently weakened
impact of running code on WG debate when there is some, is contributing
to drawn-out document development?
That's an excellent point. To a great extent
we suffer from what the FreeBSD community calls
"b
On 8/7/05, Jeroen Massar <[EMAIL PROTECTED]> wrote:
> Maybe there should be requirement that before having going to Last Call
> there should at least be 2 separate implementations when a document is
> created by a working group?
The Routing Area is debating having this rule. Right now, the rules
Melinda Shore wrote:
[..]
On the question of running code, I agree with you in
theory but we do have a problem with the timeliness of our
documents and I'm not sure that we want to make the process
even slower unless we're certain that there's a real
problem here that needs to be solved.
On Sat, 2005-08-06 at 19:07 -0400, Brian Rosen wrote:
> I notice that we have stopped being interested in running code.
Not everywhere. For the IPFIX protocol, which is currently still in
draft status, there where 6 different implementations, both of collector
and meters, showing up at the Interop
But I believe we'd do well to establish a category for
specifications
which may or may not be ready for large-scale trials, but do not
qualify
for stable standards status.
(I'll be happy to discuss this on NEWTRK, BTW, if anyone's
interested.)
At least some are. The thread John Klensin sta
Brian Rosen wrote:
We still do operate with rough consensus.
Probably only in the sense that some decisions are made
by a consensus process, but I'd guess that there's more
voting going on than not. The lack of both rough
consensus and running code is something I've been wondering
about, too.
Brian Rosen <[EMAIL PROTECTED]> wrote:
>
> I notice that we have stopped being interested in running code.
Some of us, alas, seem to have lost interest in running code.
:^( :^( :^(
> I think that is to our community's detriment.
I could not agree more!
(Of course, Brian is almost
But that's specifically what "proposed" is for (currently). "Here's
something we think we want to make a standard -- now test it".
The problem with this notion is two-fold:
(1) Almost all protocols stay at "Proposed".
(2) The impact is particularly profound if there are multiple candidate
On 08/06/2005 19:07 PM, Brian Rosen allegedly wrote:
> If two groups are arguing with one another, and one has implemented code and
> the other has not, I think we would give great weight to the running code.
Weight yes, but "great" weight? Many things have been implemented
that only work in spec
Well, actually, there's one other point ...
IEEE 802 is meeting in Vancouver the week after IETF 64, so there will
be double-heading whether we ever try to hook up with NANOG (or the
moral equivalent of NANOG), and
I don't think I've EVER seen as many spouses at an IETF as I did last
week, a
--On fredag, august 05, 2005 16:10:49 -0700 Ole Jacobsen <[EMAIL PROTECTED]>
wrote:
Could this perhaps be an opportunity for the operations community (read
NANOG) to work with the standards community (read IETF)?
Maybe they could even, gasp, meet jointly or nearby in time/place...?
I know,
16 matches
Mail list logo
