Re: [Isms] open issues

["David B Harrington" <dbharrington at comcast.net>]

I believe that could work. That means modifying RFC3584.
That would solve the problem for SNMPv1 and SNMPv2c.
And if a new SNMPv4 message is ever created, it can be written to
accommodate the presence or lack of tmStateReference.

dbh 

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:j.schoenwaelder at jacobs-university.de] 
> Sent: Saturday, April 12, 2008 9:00 AM
> To: David B Harrington
> Cc: 'Jeffrey Hutzelman'; isms at ietf.org
> Subject: Re: [Isms] open issues
> 
> On Fri, Apr 11, 2008 at 06:11:04PM -0400, David B Harrington wrote:
>  
> > For incoming messages, the transport model has no idea which
message
> > version is being used. The transport model only forwards the
> > wholeMessage as received from the network (e.g. passed by SSH).
> > Determining which message version does not happen until the
Message
> > Processing Subsystem decodes the message version from the ASN.1
> > format, and then passes the wholeMessage to the appropriate
message
> > processing model for processing. The transport subsystem should
not
> > care which mesage version is being carried.
> 
> The decision which security model is called is taken by the MPM; so
is
> it not sufficient to modify the community-based MPM to check the
> existance of a tmStateReference?
> 
> /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