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

On Mon, 30 Aug 2004 19:26:29 -0400 [email protected] wrote:
BC> > 1) like it or not, the vast majority of users I deal with 
BC> > still use v1.
BC> 
BC> For better or worse, the MIB boilerplate says "deployment of
BC> SNMP versions prior to SNMPv3 is NOT RECOMMENDED."  Specifying
BC> something new in support of a NOT RECOMMENDED protocol seems
BC> like a bad idea.

Yeah, I knew that one wouldn't fly, but I had to throw in my 2 cents.

BC> The generic "snmp:" will work fine with v1,
BC> and the extra "/" for empty context provides forward
BC> compatibility when the RECOMMENDED upgrade to v3 happens.

Right. I just know that if/when we add support for it to net-snmp, it is going
to end up being a FAQ.

BC> --- Community name and security ---
BC> 
BC> > Since community names are the only security measure available 
BC> > in v1, [they should be prohibited in SNMP URIs]
BC> 
BC> I see the concern - can you suggest appropriate text to cover
BC> this case (saying precisely what MUST NOT be done under what
BC> circumstances), keeping in mind that the context and engine
BC> are also mapped to/from the community name?

No, not really. The best idea I had was the addition of the snmpv1 uri to
sidestep the issue.

The problem is that the mapping is going to be done by a machine, with no
knowledge of what, exactly, is being mapped. Without additional complexity in
the URI to make the mapping algorithm explicit, it will require application
specific hints. And additional complexity is rarely a good idea. So what you
wrote is about as best we can do - make the implementors aware of the potential
issue and hope they do the right thing.


BC> On the topic of syntax allowed for writing:
BC> 
BC> > Telling a user than they can say
BC> > 	snmp snmp://snmp.example.com//1.3.6.1.2.1.1.3+
BC> > but not
BC> > 	snmpset snmp://snmp.example.com//1.3.6.1.2.1.1.3+
BC> > seems confusing.
BC> 
BC> But that's how SNMP works; there is no SetNext.

I know that. You know that. But the users I deal with don't know that. If they
can use the magic text '1.3.6.1.2.1.1.3+' to get a value, it seems logical that
they should be able to use that same text to change the value they just got.
They do not know (or care) that their application used GetNext to satisfy their
request.

This is an issue of aesthetics. A user without SNMP experience will look at a
URI, and think that '1.3.6.1.2.1.1.3+' is a valid OID. They will try to plug it
into anyplace they want to use an OID, and when legacy applications don't
accept it, they will complain. Aesthetic issues are easy to deal with. Simply
adding a delimiter helps with this problem. eg 

	snmp://snmp.example.com//1.3.6.1.2.1.1.3/+


BC> --- Use of wildcards ---
BC> 	
BC> > My second comment is that I don't think the wildcard tokens 
BC> > in the URI are a very good idea. Deciding what to do with the
BC> > object specified in a URI (ie what protocol operation to map to)
BC> > should be left to the application.  I think using wildcards
BC> > to imply protocol operations is a bad idea.

While my first post was due to a feeling of "I don't like the looks of this",
my sub-concious is now feeding more details to my brain.


BC> The authors are in violent agreement with you that wildcards
BC> should not directly encode/imply protocol operations.


BC> > IMHO, the URI should limit itself to specifying the
BC> > destination (host, port) and the varbinds, and leave the 
BC> > protocol out of it.
BC> 
BC> That was roughly the intent (leave it to the implementation
BC> to select protocol operations), but:

Note that we are saying slightly different things. I'm saying "leave the
protocol out of it" (it must be specified externally), and you are saying "let
the implementation select the protocol" (the exact protocol operation isn't
specified, but the end result should be XXX).


BC> - The semantics of a varbind depend on whether it's
BC> 	used in Get vs. GetNext, so that intention has to be
BC> 	specified in some fashion to avoid ambiguity.

The semantics of a varbind do not depend on the protocol operation. What the
agent does with a varbind in a request, and the resulting varbind it returns
in the response does depends on the protocol. So the URI is trying to let the
user specify what is in the returned varbind. 

I don't mind the '+' syntax so much, since it does map directly to a SNMP
protocol operation.


BC> - Bulk Retrieval - ".*" is a natural data space concept that
BC> 	does not directly imply protocol operations [...]

BC> - We wanted to provide access to bulk retrieval in some
BC> 	form, and ".*" seems to be a reasonable way to do
BC> 	that in terms of the structure of the data.  The
BC> 	alternative of encoding GetBulk in all its repeating
BC> 	and non-repeating glory would have been truly ugly.

You are representing information in the URI that can not be conveyed to the
agent by the SNMP protocol, and thus must be implemented by the application. I
think this is a bad idea.

As an analogy, a case can be made for '*' in a ftp url, since file globbing is
a concept understood and defined on the server side. But it does not make sense
for a http url, since the protocol doesn't allow for it. Sure, you could define
the http url to specify some behavior for a uri that contains a magic character
like '*' [eg, the application should get the specify page minus the '*', and
then recursively get each page linked to in the original page]. But IMHO, the
interaction between a http client and a http sever should be specified in the
http standard, no the "http://" uri standard.


>      These three examples are provided for illustrative purposes only,
>      as multiple syntactically distinct URIs SHOULD NOT be used to
>      designate the same MIB object instance in order to avoid
>      unexpected results in URI-based systems that use string comparison
>      to test URIs for equality.

This paragraph also set off warning bells. To paraphrase, "here are 3 different
ways to do the same thing. But only use one, for consistency."  What are the
odds that every application developer everywhere is going to choose the same
method? What happens when a Textual Convention is written for the SNMP URI, and
it is used as an index for a table?

Specifications and standards should eliminate ambiguity, not introduce it.



So, to sum it up, either leave protocol completely out of the URI, or else make
sure it maps directly to the protocol. Don't do something in between that
imposes addition burden on application developers.

Handling GetBulk might not be pretty, but it could be done. It could follow the
fairly well know format for http cgi scripts:

	snmp://example.com//(1.3.6.1.2.1.1.3,1.3.6.1.2.1.1.3)?nr=1;r=10


On a grammatical note, this sentence doesn't quite make sense:

> These three examples all designate the sysUpTime.0 object instance
> in the SNMPv2-MIB or RFC1213-MIB for the default SNMP context ("")
> at example.com as sysUpTime.0 is:


-- 
Robert Story; NET-SNMP Junkie
<irc://irc.freenode.net/#net-snmp>   <http://www.net-snmp.org/>

You are lost in a twisty maze of little standards, all different.