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

[Black_David@emc.com]

David,

Thanks for looking at this draft.

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

Section 3.4 says v3 over UDP by default.  If an older
version is necessary, that would be figured out via other
means (e.g., Manager knows or determines that the Agent
involved only supports v1), ditto for transports other than
UDP.  The Manager should know or be able to determine which
security model is to be used with v3.

The overall approach is that the URI says "what" to access
plus "where", and SNMP software figures out "how".  Specifically,
the entity that generates SNMP ops from an SNMP URI is supposed
to be a real SNMP Manager as opposed to a dumb mechanical
translator; the draft already relies on this for context engine
discovery when the engine is omitted.  Can you suggest additional
text to add if you think the draft plus RFC 3584 don't provide
sufficient guidance in SNMP version or transport selection?

In any case, putting something into a new URI syntax that
supports and potentially encourages continued use of older
versions of SNMP seems wrong when the security considerations
section labels those older versions as "NOT RECOMMENDED".

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

Simplicity, especially as URIs are supposed to be human-friendly,
and so the result of trying to express values in a natural
syntax could be a long adventure in dealing with DISPLAY-HINTs.
At one point in the design, we had a simple hex and string value
syntax ... and what it did to an IPv4 address was not pretty.

SNMP service URIs are in use today for roughly the situation
described in the draft - a non-IP device uses an SNMP URI to
say where its SNMP management interface is.  This draft started
out as an effort to standardize that, and was extended to include
OIDs at the request of the APP area.  We don't have a good grasp
on how SNMP URIs with OIDs are going to be used, but acquiesced
based on the rationale that OID syntax needed to be specified now
to forestall future incompatible extensions.  I'd like to resist
further "mission creep" if that's possible.

Omission of notifications was deliberate, as URIs are for data
access; they're not intended for notification generation.

> Also, I don't know "what would be displayed" in a browser
> that supported this URI.

If the browser has access to the MIB definition to get the
syntax and any display hint info, something useful is possible,
otherwise the result is liable to be in some default dump-like
syntax (e.g., hex and/or string), which may still be usable
for some purposes.

> 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".)

URIs are definitely for access, so the security name is
needed.
 
> 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.

Aside from what's discussed above plus security secrets
(passwords and the like are no longer allowed in URIs),
is anything else needed for access missing?

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------