Tue, 17 March 1998 21:36 UTC

Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15561; Tue, 17 Mar 98 16:36:45 EST
Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA08956 for cat-ietf-redist; Tue, 17 Mar 1998 15:21:06 -0500 (EST)
Message-Id: <20140418005449.2560.93582.ARCHIVE@ietfa.amsl.com>
X-Message-ID:
X-Date: (the original message had no date)
Date: Wed, 18 Mar 1998 05:36:45 -0000

<6B5344C210C7D011835C0000F801276601211137@exna01.securitydynamics.com>
From: "Linn, John" <jlinn@securitydynamics.com>
To: "Martin.Rex@sap-ag.de" <martin.rex@sap-ag.de>,
        "'Ted Ts'o'"
	 <tytso@mit.edu>
Cc: "Linn, John" <jlinn@securitydynamics.com>,
        "cat-ietf@MIT.EDU"
	 <cat-ietf@mit.edu>
Subject: RE: full-duplex message protection services
Date: Tue, 17 Mar 1998 15:22:57 -0500
X-Priority: 3
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Precedence: bulk

Ted wrote, replying to Martin:

>    From: Martin Rex <martin.rex@sap-ag.de>
>    Date: Thu, 12 Mar 1998 11:11:53 +0100 (MET)
> 
>    Since I personally think (1) has always been there implicitly,
>    I mainly wanted to find out if there is actually a significant
> installed
>    base of half-duplex restricted mechanisms that is actively used and
> can
>    not be fixed/migrated.
> 
> I agree with Martin.  The requirement for concurrent processing has
> always been in the draft, however implicitly.  My impression is that
> there isn't an installed base of half-duplex restricted mechanisms, so
> my preference would be to make this requirement explicit instead of
> implicit.
> 
I've now heard three commentators preferring a requirement for
concurrent protection in both directions (Martin, Ted, and my own
comment (wearing personal hat as individual, not as document editor)
earlier on the thread); it has also been asserted that such a
requirement has been assumed implicitly.  Before Martin's and Ted's
messages (at least in the order they arrived at my desktop), Graham
Bland had also suggested upgrading the statement, but to the level of
recommendation rather than requirement, also stating that mechanism
definitions should specify whether or not concurrent protection is
provided.  Given this discussion, I'll now revise my proposed approach
towards closure.  Absent further debate, I suggest that we adopt the
requirement.  If anyone comments to the list that this appears too
strong, we'll step to Graham's intermediate recommendation instead.
Discussion?

--jl
  •