Re: [Isms] pre-08 for TSM document

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

Hi, 

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:j.schoenwaelder at jacobs-university.de] 
> Sent: Friday, June 27, 2008 3:12 PM
> To: tom.petch
> Cc: David Harrington; isms at ietf.org
> Subject: Re: [Isms] pre-08 for TSM document
> 
> On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote:
> 
> > Focussing on this I-D, you say that the TM will not alter the LCD
> > table, but I think that it will struggle to read it, at least on
> > inbound messages, as it cannot be sure what the securityName is
and
> > so cannot index into the table.  It could walk the table looking
for
> > a matching snmpTsmLCDName ... well perhaps not.
> 
> I fail to see why a TM needs to read the table. The TM just passes
the
> name provided by the transport via the tmStateReferences and TSM
then
> does any mappings as needed.

A TM should not use this TSM table. This table is really all about
getting the securityName, which is an SM thing. 

As I began to update the secshell document, I decided the "security
ID" (snmpTsmLCDName) really should be in the TM, not the SM. The TM
should provide a mapping from secuity ID to tmSecurityName, ans TSM
should simply take tmSecurityName as securityName. Therefore, TSM
doesn't need a mapping table, TM does. So I have started moving the
mapping table to SSHTM.

The Transform table really belongs in TM as well. I think the
TM-disable belongs in TSM though, so I am splitting the TransformTable
into a TSM-disable-domain-table, and an
SSHTM-which-mapping-transform-table.

You are absolutely right that on an incoming message, the TM will have
a hard time reading the table because it is indexed by securityName,
so the transform will need to be done before the table can be read to
see if an entry already exists. I considered searching the table for 
address/LCDName, but since that is not an index, it is not guaranteed
to be unique, and it is reasonable that a given address might have
multiple SSH users.

>  
> > I assume that snmpTsmLCDName is tmSecurityName; could the names be
> > more similar or is there a subtle point that I am missing in them
> > being so different?

I think they really would be the same, but with the chnages I am
proposing, that will not be an issue.

> 
> I agree that finding good labels is important. I am not having a
good
> constructive idea yet... Checking RFC 3411 again, I see there it
makes
> a distinction between a securityName and a security ID, where the
> security ID seems to be pretty close to our tmSecurityName. Dave, do
> you agree with this reading of RFC3411?

When I move this to SSHTM, we could simply name this SSHTMPrincipal or
something similar. We have so many variations of securityName, this is
sure to be confusing to people.
> 
> > I am concerned at the length of snmpTsmLCDName, at 32 maximum.  I
am
> > aware of no such constraint for an SSH user name.
> 
> Since snmpTsmLCDName is not used in an INDEX, I think we can easily
> drop the length restriction.

Is there a limit to SSH user name? We should make sure they are
consistent.

> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 

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