Message-Id: <6.2.3.4.2.20050821100740.03c0ec60@mail.jefsey.com>
Date: Mon, 22 Aug 2005 00:18:42 +0200
To: Lisa Dusseault <lisa@osafoundation.org>,
	Iljitsch van Beijnum <iljitsch@muada.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <159f7de8a4d3d4f0e209e1545006f4a6@osafoundation.org>
References: <200508062307.TAA18855@ietf.org>
	<F7B171F5-52DD-4AAB-BFD1-CCD4203D652B@muada.com>
	<159f7de8a4d3d4f0e209e1545006f4a6@osafoundation.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: IETF General Discussion Mailing List <ietf@ietf.org>
Subject: Re: Why have we gotten away from running code?
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf