Re: IP Security......

John C Klensin <klensin@mail1.reston.mci.net> Mon, 20 March 1995 20:49 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13083; 20 Mar 95 15:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13078; 20 Mar 95 15:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17873; 20 Mar 95 15:49 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13070; 20 Mar 95 15:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13066; 20 Mar 95 15:49 EST
Received: from mail1.Reston.mci.net by CNRI.Reston.VA.US id aa17867; 20 Mar 95 15:49 EST
Received: from jck (jck.Reston.mci.net) by MAIL1.RESTON.MCI.NET (PMDF V4.3-10 #8388) id <01HOD4O95OXS000EXI@MAIL1.RESTON.MCI.NET>; Mon, 20 Mar 1995 15:50:10 -0500 (EST)
Date: Mon, 20 Mar 1995 15:49:21 -0500
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John C Klensin <klensin@mail1.reston.mci.net>
Subject: Re: IP Security......
X-Sender: klensin@mail1.reston.mci.net
To: pvm@isi.edu
Cc: Mike O'Dell <mo@uunet.uu.net>, sob@harvard.edu, iesg@CNRI.Reston.VA.US
Message-id: <01HOD4ODLNMA000EXI@MAIL1.RESTON.MCI.NET>
X-Envelope-to: iesg@CNRI.Reston.VA.US
MIME-version: 1.0
X-Mailer: Windows Eudora Version 2.1a9
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit

Paul,

To my knowledge, we have never "allowed" the publication of proposed
Informational material if it was the part of the topic matter of an active
WG.  (More precisely, we have requested that the RFC Editor not publish such
material, and the RFC Editor has agreed.)   We have been willing to publish
such material after the WG reaches its conclusion, but then have been able
to attach disclaimers identifying the "non-standard" status.  It is, for
example, exactly what we did with the intermediate IPng products.

If we ask them to wait, and they insist on publication, we can include the
nature of that process in the disclaimer.  If we get it into the WG, and the
WG rejects it, we can include _that_ fact in the disclaimer.   While I'd
prefer to never see it as an RFC, if we do have to see it, I'd like to see
NetScape pushed back on hard enough that we can responsibly attach
"considered and rejected" or "deliberate end run" language, not just the
usual "not a standard" language.   If we can get strong language on a
disclaimer, I bet we could arrange a press leak about what is going on that
would produce unambiguous negative reinforcement.

If there is a slippery slope here, we are already partway down it.

    john

p.s. For amusement, read the SSL announcement pointed to from 
   http://home.netscape.com
You will discover all sorts of people and organizations who have "endorsed"
the protocol.   If you read the statements in the press release (carefully),
you will find a lot of things that are more nearly "we believe that there
should be security solutions, and SSL should be looked at along with
others".   It also discusses the submission of the thing to W3C, but fails
to note that W3C's security WG has already rejected it.   If our procedures
require us to encourage this sort of stuff, then the procedures are broken.