Subject: [Isms] Name change

From: "David B Harrington" <[email-masked]>
Date: Mon, 19 Jun 2006 20:44:17 -0400

Hi,

Would anybody object to my changing tmStateReference to
tmSessionReference or simply sessionReference in both documents?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 23 Jun 2006 15:07:59 -0700

>>>>> On Mon, 19 Jun 2006 20:44:17 -0400, "David B Harrington" <[email-masked]> said:

David> Would anybody object to my changing tmStateReference to
David> tmSessionReference or simply sessionReference in both documents?

The state reference in the USM doc captures data, for example, as it
flows through the SM, through the agent and back out again and is then
discarded after processing a single message.  The concept of a
"session" is much longer lived (and I'd expect the state data of the
engine processing something to maybe cache a reference to the
longer-lived session data).

So...  I'd change it if it is being discussed as a long lived set of
data that is independent of the current processing.  But I wouldn't
change it if you're referring to state data that's used when processing
a single message.
-- 
Wes Hardaker
Sparta, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 23 Jun 2006 18:28:52 -0400

Hi Wes,

Yes.

securityStateReference is per-message, and used to ensure that a
response message with identical credentials can be generated even if
the credentials in the LCD have been modified by the request.

tmStateReference is about session information (assuming a
session-based TM), and is thus longer lived. The document discusses
this difference because there is a notion of cache release that must
be handled differently for the long-lived session data than for the
per-message data.

I would like to change tmStateReference to tmSessionReference so it is
easier to understand what is being cached at the other end of a
tmSessionReference, rather than some "State" reference..

dbh

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Friday, June 23, 2006 6:08 PM
> To: David B Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] Name change
> 
> >>>>> On Mon, 19 Jun 2006 20:44:17 -0400, "David B 
> Harrington" <[email-masked]> said:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 24 Jun 2006 06:57:31 +0200

> tmSessionReference or simply sessionReference in both documents?

Is the assumption correct that every transport mapping security model
will have a notion of a session?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David B Harrington" <[email-masked]>
Date: Sat, 24 Jun 2006 09:05:26 -0400

Hi,

No, and yes.

We discussed this at IETF65, where I had been requested to change some
text that said everything MUST be session-based. I disagreed because
it was possible some security model might be designed that did not
have a session as such, so I disagreed that the texst should be
changed that way. 

However, I do think that 99% of the protocols that might be used will
be session-based, all the existing IETF protocols that might be used
to provide a lower-layer secure transport are session-based, and those
that are not could be cast into a session concept. 

USM could be described as having a session, but the session is
short-lived (i.e the length of time it takes to process a request and
response pair) or it is a long-lived "session" (that lasts as long as
both sides are configured with the same shared keys). 

For practical considerations, it is likely that every TMSM will be
session-based, and tmSessionReference is more meaningful than
tmStateReference. 

I made the change in the two latest revisions of the documents. Let me
know if I need to change it back.

dbh

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Saturday, June 24, 2006 12:58 AM
> To: David B Harrington
> Cc: [email-masked]