ietf
[Top] [All Lists]

RE: Why have we gotten away from running code?

2005-08-22 08:15:41
IMHO, the problem is not so much "I have code that works in my private
network, so you should make it an Internet Standard", but "I have this
idea; I have no idea if it works; but I believe in it so much let's
spend a year of work group time to flesh it out."

The former case is handled well by a quick architectural review.
Moreover, there often is a gem of an approach in the working code.

The latter case has bogged down tons of work groups.  My REAL *PERSONAL*
opinion is this cost SIP/SIPPING a few hundred engineer years of effort.
[Flame to me personally if you think I'm off-base]

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] 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 running code?

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 any instance in recent IETF history (after 1995 or 
2000 or so) where having having running code early in the process 
would have made for a better _designed_ protocol?

Yes -- in the IMAPEXT WG we run into this frequently.  In the past 
year, implementation experience has led people to make useful 
suggestions and find issues, as you can see on the mailing list Jun 
1 and Jan 10 for example.

Also the *lack* of server implementations of the IMAPEXT annotations 
draft is leading us to make better choices (I hope) about how 
annotations are designed and how much of the feature is 
required.  It's hard to notice a lack of implementations unless the 
regular situation is to have implementations. So I certainly 
appreciate early implementations.

May I suggest a slightly different formulation for a "running 
something culture": the needs seem to be architectural consistency 
and technical inclusiveness. Architectural consistency should be the 
respect of the Charter and technical inclusiveness is more a spirit, 
a culture to look what exist or is projected (as status of the future 
art) and try to accomodate it. This can be base on running code, 
current usage, common thinking, common analysis, etc.

This is why I insist for these two aspects to be included in the 
PROTO procedure. _every_ WG will have a problem with that two points 
because WG are not simple technical writers of IESG/IAB respecting 
100% of their Charter. This is precisely in the different between the 
intent and the delivery that one can measure the WG value-added 
(which as every change may be wrong) or possible bias - this may also 
occur (RFC 3774).

In this I presuppose that IAB is the ultimate reference: it review 
the Charter for consistency with the past and should ultimatey review 
the deliverable for consistency with the "future" (all what has been 
approved and is under practical implementation). I know some think 
they know better but I think this should be covered with the IAB 
itself. However I do not know the procedure.

jfc


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



<Prev in Thread] Current Thread [Next in Thread>