Subject: Re: [Isms] pre-08 for TSM document

From: "tom.petch" <[email-masked]>
Date: Wed, 2 Jul 2008 10:48:59 +0200

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 27, 2008 9:25 AM
Subject: Re: [Isms] pre-08 for TSM document

> On Thu, Jun 19, 2008 at 07:43:22PM +0800, David Harrington wrote:
>
> > I started calling this the snmpTsmUserTable, but that could be
> > misleading, so I changed it the snmpTsmLCDTable. Let me know which
> > you prefer, or if you have another name you prefer.
>
> I find snmpTsmLCDTable too broad; the snmpTsmLCDTransformTable is also
> stored in the LCD. The table really is a snmpTsmSecurityNameMappingTable
> or a snmpTsmTmMappingTable or a snmpTsmNameMappingTable. Or what about
> snmpTsmTmNameTable?
>

I was going to suggest SessionTable since it is indexed by the 4-tuple that is
used to determine which session is used, but then I recalled that s2.2 says that
there are no sessions in TSM, rather the 4-tuple is used to associate state; so
how about
snmpTsmStateTable?

Currently it is name only but it could acquire other columns, such as the
tmSecurityLevel in use at the transport level or even parameters related to the
underlying secure transport; I realise that this has been much discussed without
consensus but I still would want something more neutral than NameTable to
accommodate any gaps in our current understanding.  TsmMapping would do, but not
TsmNamemapping (too restrictive)

Tom Petch

> Nits:
>
> - s/2007/2008/
>
> - The import of TEXTUAL-CONVENTION is not used.
>
> - Missing dot at the end of the first sentence in section 6.3.2.
>
> /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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 10 Jul 2008 17:20:39 -0400

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Friday, June 27, 2008 3:12 AM
> To: tom.petch
> Cc: David Harrington; [email-masked]
> 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.

The initial WG discussion led to a design that took a securityName and
mapped it to a 
transport-specific ID. 

The discussion now makes it clearer that the securityName should map
to a tmSecurityName, and then the TM needs its own table to map from
tmSecurityName to a transport-specific ID.

personally, I think that's more levels of mapping than we need, and
all these mappings impact the predictability of the ultimate mapping
from the actual security ID to securityName.

>  
> > 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?

Changed to snmpTsmLCDTmSecurityName

> 
> 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?
> 
> > 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.

done. This might impact the default transformations, and the ultimate
mapping to securityNames used in the notification configurations.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 10 Jul 2008 17:25:46 -0400

Hi, 

> Sent: Friday, June 27, 2008 3:25 AM
> To: David Harrington
> Cc: [email-masked]

I am not crazy abotu any of these, so I didn't rename this yet.
Personally I think we should eliminate the table anyway.