Subject: [Isms] snmpTransportModel

From: "David Harrington" <[email-masked]>
Date: Wed, 13 Dec 2006 11:19:18 -0500

Hi,

At ietf67, we agreed to use TDomain and TAddress (RFC3417) rather than
other addressing approaches. So the new revision will have a TDomain
of snmpSSHDomain  and a TAddress of snmpSSHAddress.

The SNMP-TRANSPORT-MIB (Transport-Subsystem-MIB in -04-) has no useful
objects so far, and at ietf67, we agreed to eliminate the MIB module.

The MIB module contains the Textual Convention SnmpTransportModel,
which parallels the SnmpSecurityModel and SnmpMessageProcessingModel
T-Cs from RFC3411. However, we never pass SnmpTransportModel anyplace,
or refer to it in any MIB module, so far.

So the only purpose, at this point, would be to use SnmpTransportModel
to define an IANA registry for IETF transport models, and to
standardize how enterprises can identify their own transport models,
but if it is never actually used, this may not be useful.

So we need to decide whether to keep the textual convention, on the
assumption it might be useful someday (not a very good justification
for a feature), or scrap it (and possibly need to define it in a
specific transport model, which makes document housekeeping and
functional modularity more complex).

There is one place where having an SnmpTransportModel might be useful.
A "session" is currently identified by transport[Domain,Address] and
security[Model,Name,Level]. If somebody wanted to define another
SSH-based transport model, which used the same addressing
domain/address, then this really should be expanded to be
transport[Model,Domain,Address] and security[Model,Name,Level]. There
is not necessarily a 1:1 mapping between transport models and
transport domain/addressing.

This would mean we would need to modify the ASIs (or make sure this
ends up in the cache and LCD, which is about the same thing) to pass
the transport model identifier.

Currently, transportDomain implies transportModel, and the dispatcher
uses transportDomain to determine how to dispatch outgoing messages to
the approrpiate transport model. This usage implicitly assumes a 1:1
mapping between transport model and transport domain/addressing. We
could make that explicit. 

If another transport model wants to use the same address format, they
could define a new domain and then they can utilize the same address
format. For example, if another SSH transport model were created (say
to use as the "SSH-VPN" approach), they would need to define a new
domain (snmpSSHVPNDomain), but could use the same snmpSSHAddress
specification used by snmpSSHDomain. If this is viable, then we do not
need the registration mechanisms for snmp transport models from
SNMP-TRANSPORT-MIB.

I will note that IANA does not maintain a registry for TDomains, so it
may be somewhat harder to prevent assignment collisions, or to find
definitons for enterprise-assigned domains (registered in
enterprise-specific subtrees). We could ask IANA to create a registry
of TDomains. I can envision seeing more development of Tdomains than
security models or messaging models, so a registry might be useful.

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Dec 2006 20:48:45 +0100

> the transport model identifier.

Lets not over-engineer this. I think the transportDomain is a perfect
way to tell which transport model to use.
 
> could make that explicit. 

Yes.

> need the registration mechanisms for snmp transport models from

Yes, I believe this is viable.

> security models or messaging models, so a registry might be useful.

RFC 4789 established a registry for OIDs below snmpDomains which are
used to identify SNMP transport domains. A specification is required
for new assignments. Since TDomain is an OID, there is no likelihood
of collisions. Enterprise assignments may be hard to find but then
they are probably not made with the intention to be interoperable in
the first place.

/js

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