[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please review: draft-black-snmp-uri-06.txt

On Wed, Jul 28, 2004 at 04:25:48PM -0700, David T. Perkins wrote:

> I'm not sure how the URI is suppose to be translated into
> SNMP operations, since I couldn't figure out how you
> determined which SNMP protocol (SNMPv1, SNMPv2c, SNMPv3/USM,
> SNMPv3/SBSM, etc) you were suppose to use.

The service URIs are designed to be protocol (and transport) 
independent. For SNMPv3/USM, the obvious mapping is to map the
securityName to a USM user name. For other protocol versions
and security model combinations, you do whatever is needed.

The interpretation with SNMPv1/SNMPv2c is in particular not
considered since these protocol versions are not even on the
standards track. (My implementation of these URIs uses a 
heuristic mapping which at least seems to work well in my 
environment. But as I said before, this is outside the scope 
of this document.)
 
> Also, I'm curious why it doesn't support values. With values,
> you have a "concise" way to express a SET, or notification
> (TRAPv1, TRAPv2, or INFORM) operation.
> Also, I don't know "what would be displayed" in a browser
> that supported this URI.

The object URIs are used to identify resources, not to encode
SNMP operations in URI format nor do they specify how identified
resources (values) are represented.
 
> Note also, that if the URI is just to "name" (identify)
> management info (and not to access it), then the URI
> doesn't need a user name. (Just naming management info
> is a "good thing".)

The securityName (not the user name) is used for identifying
SNMP services. 
 
> So, I'm confused about the usage of the URIs, since they
> provide more info needed to just name (identify) management
> info, but yet they don't provide enough info to access
> management info. And they don't provide values of management
> info.

My prototype implementation does some heuristic probing to figure
out which SNMP version and also which transport it likes to use.
In fact, my implementation did such probing before the work on
these URIs started. But note that this is indeed implementation
specific and other implementations might prefer to avoid probing by 
consulting external information sources to determine the necessary 
parameters. Consulting external resources is unavoidable with 
SNMPv3/USM anyway since you need to get the passphrase/key.
Encoding such things in URIs is a bad idea and will rightfully 
never pass the IESG.

/js

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