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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf