if you think I'm off-base]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
JFC (Jefsey) Morfin
Sent: Sunday, August 21, 2005 6:19 PM
To: Lisa Dusseault; Iljitsch van Beijnum
Cc: IETF General Discussion Mailing List
Subject: Re: Why have we gotten away from runn
At 02:32 20/08/2005, Lisa Dusseault wrote:
On Aug 10, 2005, at 1:40 AM, Iljitsch van Beijnum wrote:
I've been thinking about this on and off for a day, and I'm not
convinced that having running code at the time a specification is
first fleshed out would be all that helpful.
Can you point to a
On Aug 10, 2005, at 1:40 AM, Iljitsch van Beijnum wrote:
I've been thinking about this on and off for a day, and I'm not
convinced that having running code at the time a specification is
first fleshed out would be all that helpful.
Can you point to any instance in recent IETF history (after
On Mon, 15 Aug 2005, Margaret Wasserman wrote:
>
> Hi Iljitsch,
>
> At 3:54 PM +0200 8/15/05, Iljitsch van Beijnum wrote:
> >So you have reached consensus on forcing everyone who wants to look
> >up DNS information over IPv6 transport to use DHCPv6?
>
> As far as I know, nothing that we publish fo
On 15-aug-2005, at 18:05, Margaret Wasserman wrote:
So you have reached consensus on forcing everyone who wants to
look up DNS information over IPv6 transport to use DHCPv6?
As far as I know, nothing that we publish forces anyone to do
anything (or not to do anything).
But what's the alte
Hi Iljitsch,
At 3:54 PM +0200 8/15/05, Iljitsch van Beijnum wrote:
So you have reached consensus on forcing everyone who wants to look
up DNS information over IPv6 transport to use DHCPv6?
As far as I know, nothing that we publish forces anyone to do
anything (or not to do anything).
Marga
On 15-aug-2005, at 14:57, Margaret Wasserman wrote:
People may also want to read RFC 3646 which defines DHCPv6 options
to configure a DNS resolver.
We have considered _other_ ways to automatically configure a DNS
resolver in IPv6, but we haven't managed to reach consensus on any
of those
People may also want to read RFC 3646 which defines DHCPv6 options to
configure a DNS resolver.
We have considered _other_ ways to automatically configure a DNS
resolver in IPv6, but we haven't managed to reach consensus on any of
those proposals yet.
Margaret
At 9:55 AM +0200 8/15/05, Ha
Bill,
--On 11. august 2005 14:14 -0700 Bill Manning <[EMAIL PROTECTED]> wrote:
no you don't get it. ask yourself, why is in-addr.arpa special?
or, in the more modren wolrd... where should the enum space
be anchored, e164.arpa, e164.int, e164.bti.gov.uk,
o
Since nobody's mentioned the draft name yet, and we generally tell people
"go read the drafts"
draft-ietf-dnsop-ipv6-dns-configuration-06.txt
Or - "there are 3 options. We can't pick one".
The document was approved by the IESG in July (but seems to be waiting for
an IESG note).
Bill Manning wrote:
> thats -one- reason that DNSSEC has gestated these long months/years.
> operational feedback killed the first three attempts and may cripple the
> current version beyond repair.
Remember that the current DNSSEC protocol was, without much
discussion, chosen without
I think that's right. However, what may well be missing in the mix
is input from people who actually deploy and operate our stuff, and
live with its limitations and quirks every day. We need to understand
the indirect consequences of our choices: not "can it be coded and will
it interoperate?" but
Bill Manning wrote:
>
> On Aug 11, 2005, at 7:09, Alexandru Petrescu wrote:
>
>> Iljitsch van Beijnum wrote:
>>
>>> On 11-aug-2005, at 11:22, Brian E Carpenter wrote:
>>>
However, what may well be missing in the mix
is input from people who actually deploy and operate our stuff, and
>>>
On Aug 11, 2005, at 7:09, Alexandru Petrescu wrote:
Iljitsch van Beijnum wrote:
On 11-aug-2005, at 11:22, Brian E Carpenter wrote:
However, what may well be missing in the mix
is input from people who actually deploy and operate our stuff, and
live with its limitations and quirks every day.
On Aug 11, 2005, at 2:22, Brian E Carpenter wrote:
I think that's right. However, what may well be missing in the mix
is input from people who actually deploy and operate our stuff, and
live with its limitations and quirks every day. We need to understand
the indirect consequences of our choic
Iljitsch van Beijnum wrote:
> On 11-aug-2005, at 11:22, Brian E Carpenter wrote:
>
>> However, what may well be missing in the mix
>> is input from people who actually deploy and operate our stuff, and
>> live with its limitations and quirks every day. We need to understand
>> the indirect consequ
That was one of the very best reasons for the bake-offs: you got to eat
your own dog food! There is nothing like trying to get your own software
(and hardware) to work! It tends to show all the bad decisions that were
made during the development.
Chuck Wegrzyn
Brian E Carpenter wrote:
> Dave Sin
On 11-aug-2005, at 11:22, Brian E Carpenter wrote:
However, what may well be missing in the mix
is input from people who actually deploy and operate our stuff, and
live with its limitations and quirks every day. We need to understand
the indirect consequences of our choices: not "can it be coded
Dave Singer wrote:
I hear the opposite complaint enough to believe that the truth lies
somewhere in between ("the ietf is dominated by academics who have no
idea what it takes to design, deploy, and maintain large complex
networks"). I only see a tiny portion of the ietf myself, agreed (I
dou
On Wed, 2005-08-10 at 15:25 -0400, Henning Schulzrinne wrote:
> The next SIPit event is in about a month; see http://www.sipit.net/
>
> There was a GIMPS (now GIST) + NSIS NSLP interop event just before the
> IETF meeting (pre-RFC).
>
> I wish there were more, but there are some.
The NSIS intero
The next SIPit event is in about a month; see http://www.sipit.net/
There was a GIMPS (now GIST) + NSIS NSLP interop event just before the
IETF meeting (pre-RFC).
I wish there were more, but there are some.
C Wegrzyn wrote:
Perhaps they are more "regionalized". I know there are some "labs" l
Don't forget the organizations that adopt IETF specs. ISMA has a
regular interop and conformance program for RTSP + RTP + the codecs
used, both 'virtual' over the internet and face to face at most
meetings. Likewise IMTC does testing of 3GPP SA4 multimedia specs,
again using RTSP, RTP, codecs
Perhaps they are more "regionalized". I know there are some "labs" like
at the UNH that hold them but the attendance isn't nearly as universal
as they once were.
As for statistics, no I don't have any. But I bet there aren't any more
-- in fact -- I would bet there are a lot less. I can't remember
C Wegrzyn wrote:
Hey, we not only had code that ran we also had "bake-offs" to make sure
all the stuff worked together. The idea was to work out the nuances (the
20% of the inaccuracies) and produce a damn good system. Today the idea
is to slap something together - damn the interop - and get out
>From my experience over the last 25 years I have seen the number go from
almost all "academics" (and some truly impressive geeks) to more a mix
like OSI The people that attend are there to represent the position of
their management (or manager) and their companies not look for the best
solution. T
My experience has been that implementations help improve the quality of
the specifications, and formal security analyses help fix design
errors. I implemented two recent SEC area protocols, but unfortunately
in both cases, my implementations were partial (due to lack of time,
interest etc.,),
On Aug 10, 2005, at 6:36 PM, Simon Josefsson wrote:
I think that is a good point. A variation on that theme is that the
IETF is no longer run by people who actually implement protocols. The
relevance and impact of the IETF on what is actually used on the
Internet is marginalized through that
I hear the opposite complaint enough to believe that the truth lies
somewhere in between ("the ietf is dominated by academics who have no
idea what it takes to design, deploy, and maintain large complex
networks"). I only see a tiny portion of the ietf myself, agreed (I
doubt many people see m
I think that is a good point. A variation on that theme is that the
IETF is no longer run by people who actually implement protocols. The
relevance and impact of the IETF on what is actually used on the
Internet is marginalized through that change of membership. The
attitude of "That is not how
In <[EMAIL PROTECTED]> Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes:
> --On onsdag, august 10, 2005 02:46:57 -0500 wayne <[EMAIL PROTECTED]> wrote:
>
>> The working group was shut down because no consensus could be
>> reached. I think the lack of working code was one of the core causes
>> o
Iljitsch van Beijnum wrote:
There are also specifications that would have been good to have
implementations before leaving the WG, because they are not
implemented-able as is (spkm).
Is that because the designers did a bad job or because there was no
way to anticipate the implementation dif
I think a big part of the issue is that the IETF has been taken over
little by little by corporate interests. Before it used to be for the
"love of doing it". Today it is more for "the benefit of one".
Chuck Wegrzyn
Marc Manthey wrote:
> morning experts,
>
>
>> (Note that I haven't implemented
morning experts,
(Note that I haven't implemented any IETF protocols myself, but I
did once do an implementation of a badly designed protocol.)
a, is this why you think that there is no need for any new or
old protocol at all ?
have a great day
marcM.
--
"Reality is what, when
On 10-aug-2005, at 11:14, Love Hörnquist Åstrand wrote:
I don't agree, several IETF protocols that I've implemented while
still
drafts have had major design changes done them because of an
implementation
exposed serious flaws in them (secsh-gss, pk-init).
Hm, I'm not familiar with those. S
Bruce Lilly wrote:
Date: 2005-08-09 09:16
From: Brian E Carpenter <[EMAIL PROTECTED]>
The question on the table since RFC 3774 is: why don't we
execute the transition to Draft Standard more often,
otherwise known as: why are there so few implementation
reports at http://www.ietf.org/IESG/impl
--On onsdag, august 10, 2005 02:46:57 -0500 wayne <[EMAIL PROTECTED]> wrote:
The working group was shut down because no consensus could be
reached. I think the lack of working code was one of the core causes
of the lack of consensus.
Don't be shy about naming names
The MARID WG had on
"us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[EMAIL PROTECTED]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Subject: Re: Why have we gotten away from running code?
X-BeenThere: ietf
> Date: 2005-08-09 09:16
> From: Brian E Carpenter <[EMAIL PROTECTED]>
> The question on the table since RFC 3774 is: why don't we
> execute the transition to Draft Standard more often,
> otherwise known as: why are there so few implementation
> reports at http://www.ietf.org/IESG/implementation.h
Iljitsch van Beijnum <[EMAIL PROTECTED]> writes:
> Sure, trying to implement something brings out bugs in the
> specification, but those are usually relatively minor things that
> don't go to the design of the protocol. And wide deployment generally
> shows that a protocol could have been better
On 7-aug-2005, at 1:07, Brian Rosen wrote:
I notice that we have stopped being interested in running code.
I think that is to our community's detriment.
[...]
Probably more importantly, I think we should be VERY suspicious of
new,
complex specifications before we have running code.
I'
In <[EMAIL PROTECTED]> "Brian Rosen" <[EMAIL PROTECTED]> writes:
> I notice that we have stopped being interested in running code.
>
> I think that is to our community's detriment.
I confess that while I've watched the IETF from afar for about a
decade, I am relatively new to actually doing anyth
Melinda Shore 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 could
help end some of those round-and-round we go d
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
At 01:21 07/08/2005, Spencer Dawkins wrote:
I agree with almost everything that Brian Rosen says in his note - the
only thing that made me wonder, after Steve Bellovin talked at the IAB
plenary about a crypto protocol that got blown twice in a specification
that had only three message (message-
I agree with almost everything that Brian Rosen says in his note - the
only thing that made me wonder, after Steve Bellovin talked at the IAB
plenary about a crypto protocol that got blown twice in a
specification that had only three message (message-equivalents? sorry
if I misunderstood), that
I notice that we have stopped being interested in running code.
I think that is to our community's detriment.
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.
I don't see that happening. This h
59 matches
Mail list logo
