Re: Concerns

John Lawler <jlawler@vpnet.com> Tue, 17 September 1996 21:11 UTC

Received: from cnri by ietf.org id aa02633; 17 Sep 96 17:11 EDT
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa08381; 17 Sep 96 17:11 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa10816; 17 Sep 96 16:52 EDT
Received: from [192.94.214.100] by neptune.TIS.COM id aa10785; 17 Sep 96 16:46 EDT
Received: by relay.hq.tis.com; id QAA14582; Tue, 17 Sep 1996 16:50:17 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma014546; Tue, 17 Sep 96 16:49:48 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA28586; Tue, 17 Sep 96 16:49:01 EDT
Received: by relay.hq.tis.com; id QAA14543; Tue, 17 Sep 1996 16:49:46 -0400
Received: from dns1.noc.best.net(206.86.8.69) by relay.tis.com via smap (V3.1.1) id xma014526; Tue, 17 Sep 96 16:49:26 -0400
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id NAA03292; Tue, 17 Sep 1996 13:50:34 -0700
Received: from info-10.noc.interop.net ([45.9.1.8]) by shellx.best.com (8.6.12/8.6.5) with SMTP id NAA26299; Tue, 17 Sep 1996 13:34:42 -0700
Message-Id: <2.2.32.19960917233303.00685998@best.com>
X-Sender: jlawler@best.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 17 Sep 1996 16:33:03 -0700
To: ipsec@tis.com
From: John Lawler <jlawler@vpnet.com>
Subject: Re: Concerns
Cc: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

>These two items are in conflict.  I don't see how you can assemble a
>concrete list of requirements *without* reexamining the goal of the
>working group.

My point is that if we are still at this stage of the game at this late
date, then something is seriously wrong with the process. And in any case,
without such a list, or without a serious chnage in the way things are
handled within the WG, the only decision that can reasonably be made is to
let both specs advance through the process. *Neither* spec should be chosen
or killed because they are allegedly in or out of compliance with a
non-existant and still-evolving set of criteria.

I still would much prefer to see a unified proposal--please see the separate
message I've posted with a proposal towards that end.

-John