Re: v 1.2, IETF material

John C Klensin <KLENSIN@infoods.mit.edu> Tue, 01 December 1992 20:24 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09182; 1 Dec 92 15:24 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09173; 1 Dec 92 15:24 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22245; 1 Dec 92 15:25 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09157; 1 Dec 92 15:24 EST
Received: from INFOODS.MIT.EDU by CNRI.Reston.VA.US id aa22235; 1 Dec 92 15:25 EST
Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #2603 ) id <01GRSZ3U181S0001WW@INFOODS.MIT.EDU>; Tue, 1 Dec 1992 15:24:01 EST
Date: Tue, 01 Dec 1992 15:24:00 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: v 1.2, IETF material
In-reply-to: <9212011528.AA20237@Mordor.Stanford.EDU>
To: dcrocker@mordor.stanford.edu
Cc: Erik.Huizer@surfnet.nl, carl@malamud.com, poised@CNRI.Reston.VA.US
Message-id: <723241440.932040.KLENSIN@INFOODS.UNU.EDU>
X-Envelope-to: poised@CNRI.RESTON.VA.US
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Content-transfer-encoding: 7bit
Mail-System-Version: <MultiNet-MM(330)+TOPSLIB(156)+PMDF(4.1)@INFOODS.UNU.EDU>

Dave and Carl,

   I think that the compelling argument on the design team issue is that
we will end up with them one way or the other: the only questions have
to do with what we call them and whether they function more or less in
the sunshine or by what could be perceived of as conspiracy.  As Dave
suggests, not mentioning them doesn't cause them to go away.

   If it is possible to make a translation from ANSI's tested-by-fire-
and-many-lawyers procedures, the trick is to avoid making of final
decisions in private.  If the output of a design team goes into a public
process (e.g., WG review) and the WG (and subsequently IESG) can, both
in theory and in practice, modify or even reject the design team's
output, then there should be little or no legal problem that we don't
have anyway (e.g., when we look at individual contributions).  

If one wanted to be extremely careful about this, the general rules for
design teams would require that their report be not only a set of
protocol suggestions but a rationale and justification for them.  That
would make the reasoning public and open (even if after the fact).  It
would, of course, have the important side-benefit of documenting the
reasoning behind the decisions for the community, something that I think
we concluded some months ago (in a non-POISED context) was a good idea
anyway.

   john