Subject: Re: Why have we gotten away from running code?

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 15 Aug 2005 08:52:11 +0200

Bill,

--On 11. august 2005 14:14 -0700 Bill Manning <[email-masked]> 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,
> 	or...  we.are.all.bozos.on.this.bus.

I think you are arguing about the principle of one single "blessed" tree 
versus "just let everyone do their own thing".

e164.arpa is an obvious choice if you think that "one is more equal than 
others". If you don't think so, it doesn't matter - since nothing's 
special, there will be 0, 1 or multiple instances of the beast (you have no 
way of knowing), and the users just have to deal with the results.

> 	this stuff is -HARDCODED- in the resolver libraries shipped with
> 	each end system.   the arbitrary change (after six years of deployed
> 	code) from ip6.int to ip6.arpa and -expecting- a mass change out of
> 	deployed code at zero cost to the folks "forcing" the change (guess who
> 	passed that change off on the unsuspecting?)  is enough to drive some
> 	endusers crazy... as well as service providers.

want to rehash that debate here, too?

None of these things were done in secret. None of these things were done 
without debate. They might be right, they might be wrong. But the claim 
that the change was "passed off on the unsuspecting" is simply silly.

                 Harald

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 22 Aug 2005 11:13:47 -0400

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: [email-masked] [mailto:[email-masked]] 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