Re: [Isms] wg last call followup - sshtm

["David Harrington" <ietfdbh at comcast.net>]

Hi Tom, 


> > Actually, I think it is incorrect to say that no mention is made
of
> > caching the tmSecurityName.
> >
> > The openSession takes a tmStateReference that already contains a
> > tmSecurityName, and openSession adds the corresponding 
> tmSessionID to
> > the tmStateReference cache. This binds the 
> tmTransportAddress and the
> > tmSecurityName and the tmSessionID together.
> >
> > When a response is received, it will be received over the existing
> > session. And by looking up the tmSessionID, we find both the
> > corresponding tmSecurityName and the correspnding "user@"
> > transportAddress to pass up the stack.
> >
> > Apparently you didn't find that obvious ;-)
> 
> Well now, you can if you have a session cache whose entries 
> remain invariant for
> the duration of the session.  Which is not what the I-Ds 
> currently say to me.

Hmmm. Is it the odd-numbered or even-numbered drafts that always have
the MIB reappear?

> 5.1 2) says create a tmStateReference cache and that is now 
> the thrust, that a
> tmStateReference cache entry is created per inbound message 
> and only lasts for
> the duration of the transaction as opposed to a cache entry 
> that is per session
> and lasts for the duration of the session.  I think that such 
> a cache must now
> exist but see it as too much of a stretch to read that 
> meaning into the current
> text.  

I think it is one of the many "implementation-dependent" cop-outs.

> We are, I hope, writing this for those who have not 
> spent five years
> working on it.

If we work on it a bit longer, maybe SNMP will be declared Historic
and we can all go home.

> 
> Recall too that in November you said .
> "The sessionID field that is contained in the tmState is used for
one
> and only one purpose - to match corresponding request and response
> sessions to ensure sameSecurity. It is never used for any other
> purpose. And it is opaque to the security model."

I was lost and now I'm found.
Yup, we'll have to clean up those types of statements in the text.

> 
> So I am now proposing - see another of my e-mails - a 
> different use for
> tmSessionID, that it is used as a session identifier between 
> sshtm and ssh in a
> Command Generator so as to match the request and response 
> sessions, nothing to
> do with sameSecurity in a Command Responder.

Yup.

> 
> Also note that s.3 says
> " SSH sessions are uniquely identified within the SSH Transport
Model
>    by the combination of tmTransportAddress and tmSecurityName
>    associated with each session."
> and this must now mean except when sessions are uniquely identified
by
> tmSessionID so I have a sentence to add there as well to the 
> effect that there
> must be a one-to-one correspondence between the unique
> tmTransportAddress+tmSecurityName and the unique tmSessionId.

Uh. maybe. I'm tired. I'll need sleep before concurring with this.

> 
> And as I already asked, why has openSession  been changed to
> 
>    statusInformation =
>    openSession(
>    IN   tmStateReference       -- transport information to be used
>    OUT  tmStateReference       -- transport information to be used
>    IN   maxMessageSize           -- of the sending SNMP entity
>     )
> 
> Or is this the obvious statement that the three parameters are
cached
> together:-)

Yup. The EOP gets hard to read (grin) if we pass individual parameters
in this interface.
> 
> Tom Petch
> > We'll try to make it more obvious.
> >
> > > -----Original Message-----
> > > From: tom.petch [mailto:cfinss at dial.pipex.com]
> > > Sent: Tuesday, March 03, 2009 9:05 AM
> > > To: Wes Hardaker; Jeffrey Hutzelman
> > > Cc: David Harrington; 'Juergen Schoenwaelder'; isms at ietf.org
> > > Subject: Re: wg last call followup - sshtm
> > >
> > > Wes
> > >
> <snip>
> 
>