Re: v 1.2, IETF material

"Barry M. Leiner" <leiner@nsipo.nasa.gov> Tue, 01 December 1992 20:29 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09252; 1 Dec 92 15:29 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09243; 1 Dec 92 15:29 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22557; 1 Dec 92 15:29 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09238; 1 Dec 92 15:28 EST
Received: from dscs.arc.nasa.gov by CNRI.Reston.VA.US id aa22517; 1 Dec 92 15:29 EST
Received: Tue, 1 Dec 92 12:29:00 PST from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T)
Message-Id: <9212012029.AA01044@dscs.arc.nasa.gov>
To: Dave Crocker <dcrocker@mordor.stanford.edu>
Cc: Erik Huizer <Erik.Huizer@surfnet.nl>, Carl Malamud <carl@malamud.com>, poised@CNRI.Reston.VA.US
Subject: Re: v 1.2, IETF material
In-Reply-To: Your message of "Tue, 01 Dec 92 07:28:41 PST." <9212011528.AA20237@Mordor.Stanford.EDU>
Date: Tue, 01 Dec 1992 12:28:59 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Barry M. Leiner" <leiner@nsipo.nasa.gov>

Dave,

The issue is more what do you specify and what do you just leave to work
however it will. We felt that the important thing to specify was how does
the ITTF deal with various proposals for solutions to problems. How those
proposals get generated in the first place just didn't seem that relevant
to the standardization process.

Hence, we didn't really see the need to talk about design teams. It just
appeared to be a place where we wind up overspecifying the system, and run
the risk of putting our feet in our collective mouths, to boot.

Barry

> Return-Path: @CNRI.Reston.VA.US:dcrocker@mordor.stanford.edu
> Return-Path: <@CNRI.Reston.VA.US:dcrocker@mordor.stanford.edu>
> Received: Tue, 1 Dec 92 07:42:32 PST from IETF.nri.reston.VA.US
(IETF.CNRI.RESTON.VA.US) by nsipo.arc.nasa.gov (4.1/1.5)
> Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03489;
>           1 Dec 92 10:29 EST
> Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa10080;
>           1 Dec 92 10:30 EST
> Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
> 	id AA20237; Tue, 1 Dec 92 07:28:41 -0800
> Message-Id: <9212011528.AA20237@Mordor.Stanford.EDU>
> To: Erik Huizer <Erik.Huizer@surfnet.nl>
> Cc: Carl Malamud <carl@malamud.com>, poised@CNRI.Reston.VA.US
> Subject: Re: v 1.2, IETF material 
> Org: The Branch Office, Sunnyvale CA
> Phone: +1 408 246 8253; fax: +1 408 249 6205
> In-Reply-To: Your message of Mon, 30 Nov 92 18:38:38 +0100.         
<"survis.sur.975:30.10.92.17.40.05"@surfnet.nl> 
> Date: Tue, 01 Dec 92 07:28:41 -0800
> From: Dave Crocker <dcrocker@mordor.stanford.edu>
> X-Mts: smtp
> 
> While the IESG/IAB meeting at the end of IETF week did conclude
> that there were basic legal difficulties with formal recognition of
> design teams, I continue to believe that we should/must find a
> way to incorporate them.
> 
> Attorneys have two modes of operation.  Their default mode is to
> find all of the things wrong.  But their other mode is to be told that
> a thing must be done and that the attorney's job is to find adequate
> justification for it.  We need to invoke this latter mode for
> developing the specification for design teams.
> 
> Design Teams are a fact of IETF life and much of the discomfort that
> we experience in working groups, I believe, is from their absence
> (design by committee) or by inadequately incorporating their work (folks
> feel coerced, for example.)
> 
> The concern for collusion is real and must be delt with directly.  But I
> do not believe that avoiding formal mention of design teams is the answer.
> I believe that explicit discussion of them -- and the obligations and
> limitations to their behavior -- is required.
> 
> Dave