RE: [Isms] tmsm issue #5: session table (p39)

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

Hi Randy,

There is another use case you didn't mention. 

An authenticated CG could cause the creation of a session from the
remote system to the local system for callback purposes. Such a
callback approach has not been well-specified, and I am not sure such
an approach is even viable, but it would require either read-write
access to the session table, or another object that would cause a
session to be created. Either way, the manager would probably want to
see if a suitable session already existed before creating a new
session.

Callback has been debated, and the WG has waffled between "this really
is needed for notifications when no session yet exists" to "we don't
care about this because there is no customer demand for this feature."

If all engines support mixing R/R and notification messages in the
same session, then a manager could open a two-way session to each
agent in case there are any notifications to be sent to it. I think
this compares to the subscription model being discussed in netconf.
There are issues with mixing that we have not yet discussed and which
have been discussed in netconf, such as whether a long response (say
to a getbulk) would block the delivery of notifications. There are
issues with subscriptions that we have not discussed, such as the
scalability of requiring managers to configure sessions to agents,
especially when a network is recovering from, say, a power outage -
with a subscription model, should the linkUp notifications be buffered
by the agent until a manager sets up a session?

In the meantime, I find the session table useful to try to understand
what session info needs to be kept in an LCD for use by the elements
of procedure, whether the LCD is in MIB format or a proprietary
format. Using an implementation-neutral session MIB makes this clearer
for me for now.

We will need to keep session info available, and specify how one does
a lookup based on the info available in the ASIs, in order to support
the reuse of sessions (mixed or not). SNMP applications and the
dispatcher and the message processing models do not know about
sessions, and SSH does not know about securityN/M/L, so SSHSM needs to
translate from the ASI parameters (transport + securityN/M/L) to SSH
username/subsystem/transport somehow. A session tabel seems an
appropriate place.

dbh

> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn at mindspring.com] 
> Sent: Friday, May 19, 2006 11:24 PM
> To: isms at ietf.org
> Subject: Re: [Isms] tmsm issue #5: session table (p39)
> 
> 
> Hi -
> 
> > From: "Juergen Schoenwaelder" <j.schoenwaelder at iu-bremen.de>
> > To: <isms at ietf.org>
> > Sent: Wednesday, May 17, 2006 11:58 AM
> > Subject: [Isms] tmsm issue #5: session table (p39)
> >
> > tmsm issue #5: session table (p39)
> > 
> >   Should it be possible for a manager to create or modify 
> rows in the
> >   session table?  If so, then we may need the rowstatus object.
If
> >   the session table is read-only then we can probably eliminate
the
> >   rowstatus.  If the tabel is not read-only, then we need 
> to list the
> >   tables and objects and state why they are sensitive.
> > 
> >   -> strawman: the session table is read-only
> ...
> 
> The only reasons I can think for having a session table visible to
> management are:
>     - to monitor who is accessing a system at the moment
>     - to provide a way for an administrator to terminate 
> other sessions
>     - for debugging
> 
> None of these seems very persuasive to me.  I suggest eliminating
> the table.
> 
> Randy
> 
> 
> _______________________________________________
> Isms mailing list
> Isms at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 


_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms