Subject: [Isms] TSM nit

From: Wes Hardaker <[email-masked]>
Date: Tue, 18 Nov 2008 08:50:42 -0800

In section 4.2, Step 1 for an outgoing message we pull the securityLevel
out of the securityStateReference.

But...  In Step 5 of the incoming processing (5.2) we don't put the
securityLevel in the cache.  I'd suggest we be consistent about
documenting in both places what goes in and out (even though it could
easily be inferred).

-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "tom.petch" <[email-masked]>
Date: Wed, 19 Nov 2008 20:34:53 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 18, 2008 5:50 PM
Subject: [Isms] TSM nit

> documenting in both places what goes in and out (even though it could

But why use the securityStateReference at all?  Why not use tmStateReference
instead?

Tom Petch

---

From: "Dave Shield" <[email-masked]>
Date: Fri, 21 Nov 2008 09:01:31 +0000

2008/11/18 Wes Hardaker <[email-masked]>:
> securityLevel in the cache.

According to the draft I'm looking at, step 5 simply says

  "The security data is cached as cachedSecurityData....
   Then securityStateReference is set ... to this cached data."

There's no attempt to specify what is covered by "the security data"
so this may indeed include the message securityLevel value.

>  I'd suggest we be consistent about
> documenting in both places what goes in and out

I'd agree.
For comparison, the equivalent description of the cachedSecurityData
for USM *does* specify what should be included (RFC3414, 3.2 step 11))

Dave