Subject: RE: engineering discipline WAS: stats from the text conferencing experiment

From: "Harrington, David" <[email-masked]>
Date: Wed, 4 Dec 2002 18:14:20 -0500

Hi,

Comments inline.

> -----Original Message-----
> From: Frank Kastenholz [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2002 9:34 AM
> To: [email-masked]
> Subject: RE: engineering discipline WAS: stats from the text
> conferencing experiment
> 
> 
> 
> Here's a radical thought.
> 
> It seems to me that the problem with w.g. output is
> that it's design by committee. We all know that a
> camel is a flea that was designed by a committee...
> 
> So get rid of the committee-aspect of working groups.
> Make them dictatorships. Person X has a "bright idea"
> and wants to standardize it. X becomes the main 
> technical arbiter for what does and does not go into
> the proposal. The working group is there to provide 
> feedback and alternative views that X must consider 
> but need not adopt. for the most part, the decision is
> solely X's. <handwave-mode>Some things that the WG
> raises, X must adopt -- where those things are 'critical'
> to the Internet architecture/etc</handwave-mode>
> 
> The chair of the WG has a couple of roles. First is
> simply administrative (asking for meeting slots and so on).
> The second is to facilitate orderly discussion in the WG,
> keep the group on-charter, and so on. The third role
> is as someone who can direct X to do things, when those
> things are 'critical bits of internet architecture'
> (in other words, the WG Chair is the Keeper Of The
> Internet Architecture)
> 
> The WG chair can also recommend to the IESG that the WG 
> be terminated (or a new X/idea found) if the WG decides
> that X is being sufficiently open-minded about listening
> to and taking the critique of the working group.  X and the
> WG do not have a choice here. In other words, if X goes on 
> an ego-trip, the WG chair can shut it down. 
> 
> If there are competing visions to doing the same thing,
> instead of trying to merge them, then
> a) The competing vision gets its own X and its own
>    document set, etc, etc -- in effect we create parallel
>    efforts

I don't understand how this is much different than not having a standards body. Each vendor will create their own competing vision to doing the same thing. They document their own vision (using lots of nice marketing pablum) and the vendor community presents multiple parallel efforts to customers.

> b) Neither effort goes forward as a standards-track document
>    but they go as experimental (which they obviously are since
>    it's not obvious who the "winner" is). At some point in the
>    future the adoption of the ideas can be examined and both 
>    can be standardized, one standardized and one historicalized,
>    or both historicalized...

Isn't this the same as the current market approach of capitalist economies? So what role does the IETF play in the process? Why do we need an IETF in this scenario? What value-add do they bring to situation?
> 
> Yes, this multitracking is not to vendors liking since we all 
> want The One True Standard and all that. But let's face it,
> we vendors have been a big contributor to this mess, we should
> bear some of the costs of it...

I'm not sure I agree with you that this would not be to vendors' liking. If the vendors felt that the IETF was in any way relevant, they might be thrilled to have a standards body where they can bring their competing vision and have a bunch of people critique it, and they can choose to modify how they see fit, and can ignore suggestions they don't like. And it would get published as an RFC, which vendors could tout as being IETF "standards". 

It seems to me this would **encourage** the type of behavior we are concerned about in the current IETF approach.

In the meantime, the network operators would lose big time, because they would have to work to integrate all these competing visions, and would have no leverage to force vendors to play in an interoperable mode.

Such a "let the market decide" approach might work, but I don't that there would be a need for the IETF if that's the way things were done.

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks

> F

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 04 Dec 2002 15:45:02 -0800

David,

[clipped...]
 
> Isn't this the same as the current market approach of capitalist economies? 

And what's exactly wrong with that approach ? 

> So what role does the IETF play in the process? Why do we need an IETF in 
> this scenario? What value-add do they bring to situation?
> > 
> I'm not sure I agree with you that this would not be to vendors'
> liking. If t he vendors felt that the IETF was in any way relevant,
> they might be thrilled t o have a standards body where they can
> bring their competing vision and have a bunch of people critique
> it, and they can choose to modify how they see fit, an d can ignore
> suggestions they don't like. And it would get published as an RFC,
> which vendors could tout as being IETF "standards".
> 
> In the meantime, the network operators would lose big time, because they 
> would have to work to integrate all these competing visions, and would 
> have no leverage to force vendors to play in an interoperable mode.

The operators' leverage is $$$. And in a market economy that is the 
best leverage one could get.

> Such a "let the market decide" approach might work, but I don't that 
> there would be a need for the IETF if that's the way things were done.

Yakov.