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