Subject: Re: [OPSAWG] REMINDER: A proposal about how to get the real cause of SNMP failed requests. Please feed back your comments, thanks.

From: banshimin 01376 <[email-masked]>
Date: Thu, 25 Sep 2008 11:56:06 -0300

Hello Randy,
Yes, the IP address to which the response was sent and the request-id can identify a SNMP request uniquely. We also thought it over. But we think the proposal is simpler than it. The proposal takes advantage of the protocol rather than modify it. You know, the error-status field has 4 bytes to store error status index. But at present only 0-18 values are used. The proposal just extends the usage of error status, not modify the protocol form
at. Maybe you think the protocol is modified because of the usage of error status being extended. 
How about the others' opinion?

About the age-out mechanism, you are right. The error messages are mainly real-time information. I'd like to provide a mibnode through which the user could configure the age-out time, default 5 minutes, that's, the old error messages will be removed after the age-out time.

Your comments are very good suggestions, I'll consider them carefully. I hope we could provide a simple way to get the detailed error message.

Thank you very much. 
Cheers
Shimin

----- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, September 25, 2008 12:33 PM
Subject: Re: [OPSAWG] REMINDER: A proposal about how to get the real cause of SNMP failed requests. Please feed back your comments, thanks.

> Hi -
> 
>> From: "Shimin Ban" <[email-masked]>
>> To: <[email-masked]>; <[email-masked]>
>> Sent: Wednesday, September 24, 2008 7:43 PM
>> Subject: [OPSAWG] REMINDER: A proposal about how to get the real cause of SNMP failed requests. ...
>> If you have any suggestions or opinions please don't hesitate to e-mail me. Thank you in advance.
> ...
> 
> You could avoid modifying the protocol if you indexed your table
> with the address to which the response was sent and the value of
> request-id (flattened into unsigned32 in order to work as an index).
> One nice benefit would be that the manager could look for the error
> if the response was lost on the wire, something not practical with
> randomly-assigned indexes.
> 
> In any case, you should think about providing some kind of age-out
> mechanism for the error table entries, and might also consider whether it
> would be worthwhile to support internationalization of the error
> messages.
> 
> You should also think about what kind of access control policy
> would be meaningful for this information.  One advantage of including
> the address to which the response was sent in the indexing would be
> that it would make sensible VACM configuration in multi-manager
> situations possible.
> 
> Finally, you might give some consideration to how you would deliver
> the error information from the instrumentation to the table in an
> AgentX, SMUX, or proprietary subagent environment.
> 
> Randy
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 25 Sep 2008 10:36:49 -0700

Hi -

> From: "banshimin 01376" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, September 25, 2008 7:56 AM
...
> You know, the error-status field has 4 bytes to store error status index.

No, it does not.  RFC 3416 page 8 defines it as being in the range 0 to 18.
Anything outside that range MUST be treated as an ASN.1 parse error,
as the protocol is currently defined.

BTW, I thought a bit more about you table's indexing.  To deal with
access control, multiple applications running on the same management
system, and so on, I think the indexes need to be (in this order):
security name, response address (containing protocol, addr, port),
and request id.

Randy

---

From: Shimin Ban <[email-masked]>
Date: Sat, 27 Sep 2008 11:59:29 +0800

Hi,

----- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, September 26, 2008 1:36 AM
Subject: Re: [OPSAWG] REMINDER: A proposal about how to get the real cause of SNMP failed requests. Please feed back your comments, thanks.

> security name, response address (containing protocol, addr, port),

I think the address, port and request-id are enough if multiple SNMP applications runs in the same management system, why use the security name and protocol?
BTW, using multiple indexs is a bit complicated to implement. Using the error status index is easy to understand and implement. Yes, you are right that the SNMP protocol has to be modified if use the error status as the table index. Is it possible to modify the protocol? If the current SNMP stacks could deal with the response-PDU with error status not in the range 0 to 18 (I think they should), for example, return 'unknown error', it is possible to modify the protocol and it can be backward-compatible with the current protocol.

Shimin

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 27 Sep 2008 11:37:35 -0700

Hi -

> Sent: Friday, September 26, 2008 8:59 PM
...
> I think the address, port and request-id are enough if multiple
> SNMP applications runs in the same management system,
> why use the security name and protocol?

There's no guarantee that all there's only one user of the management
system, and no guarantee that all those users trust each other or have
the same access rights.  Consequently, it would probably be desirable
to prevent them from accessing each others' error messages.  (An
error message could convey information to which another user should
not have access.)  Including security name in the indexing structure is
just an easy way of making it easy to configure VACM to do the right thing.
There are other was to make it happen, but they would be much more difficult
for the security administrator.

> BTW, using multiple indexs is a bit complicated to implement.

That depends on the tools you're using.  I've never found it to be
a problem, but I don't know what tools you have available.

> Is it possible to modify the protocol?

It's a question of whether the IETF collectively sees sufficient
benefit to doing this.  When we updated RFC 1905, issue #1905-37
was a request to add a single additional additional error code, and
there was not even consensus to make that small change.

> If the current SNMP stacks could deal with the response-PDU
> with error status not in the range 0 to 18 (I think they should),
> for example, return 'unknown error', it is possible to modify
> the protocol and it can be backward-compatible with the
> current protocol.

The implementations with which I am most familiar (the PEER
Networks / BMC Software ones) would have treated such an
error status as an ASN.1 parse error.  I'm not in a position to
say what others do, but I'd expect the same.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Sat, 27 Sep 2008 22:58:36 +0300

Hi, 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn

I think the current proposal would not be found acceptable because the
SNMP protocol would need to know all the new enumerated values, but
they really would be reporting MIB-specific error conditions. Each
time this has been discussed, consensus was reached that the existing
error codes adequately report SNMPv1,v2,and v3 processing errors.
Overloadong the functionality of the SNMP error code field to report
MIB-specific error codes could constrain the SNMP protocol from being
expanded with additional SNMP-specific error codes when needed. The
IETF management framework tries to keep a separation between the
protocol and the data models. So you would violate the IETF Management
Framework.

The number of possible MIB-specific error codes should not constrained
to one enumerated value; using an enumeration would probably require
organizing the numbers by type of error or the enumeration will become
unweildy. A better approach would be to have MIB-specific error codes
defined in relevant MIB modules, and carried in the PDU.  

There is also an issue of matching an error code to a specific varbind
in a multi-varbind message. What happens if there are two error
conditions for a single message? SNMP says there is no specific
processing order, so different implementations might report different
results for the same multiple error conditions.

MIB-specific error codes has been discussed multiple times.
Obvioiusly, it appears desirable, but having MIB-specific error codes
has consistently been found undesirable, mainly because it could lead
to increased complexity and a lack of interoperability. 

One point is that some of the conditions you are suggesting we get
information about are really implementation errors in the manager
application, not runtime network functionality errors. There are
better tools for debugging implementation errors than SNMP.

dbh

---

From: Shimin Ban <[email-masked]>
Date: Sun, 28 Sep 2008 14:55:43 +0800

----- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Sunday, September 28, 2008 2:37 AM
Subject: Re: [OPSAWG] REMINDER: A proposal about how to get the real cause of SNMP failed requests. Please feed back your comments, thanks.

> for the security administrator.

If a NMS has many users, the requests sent by the different users should have different request-id with same IP and port. And it should be SNMP stack that deals with the error information, not the user application. Thus, the application needn't care the rights of the different users, i.e. user A sends request-b and he only can get the error information of request-b. However, then everyone can get the error information by MIB browser if he has access.
The 'security name' is the user name of the application or of SNMPv3?
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 28 Sep 2008 17:03:53 -0700

Hi -

> Sent: Saturday, September 27, 2008 11:55 PM
...
> If a NMS has many users, the requests sent by the different users
> should have different request-id with same IP and port.

A big assumption.  I don't know whether this is true, for example,
on multi-homed hosts.

> And it should be SNMP stack that deals with the error information,
> not the user application.

Another big assumption, and certainly not the way we looked at in
in the architecture.

> Thus, the application needn't care the rights of the different users, i.e.
> user A sends request-b and he only can get the error information of
> request-b.

Not true at all, if the information is also stored in MIB objects as you propose.

> However, then everyone can get the error information by MIB browser if he has access.

This is a serious problem, in my view.

> The 'security name' is the user name of the application or of SNMPv3?

Not necessarily.  Its the name of the user on whose behalf that application
is operating, from the perspective of VACM.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Mon, 29 Sep 2008 10:33:49 -0400

Hi, 

> is operating, from the perspective of VACM.

securityName is the name of the principal on whose behalf an operation
is performed. The principal might be a user, an application, a host,
or some other identifiable (and preferably authenticatable) entity. 

Can we pick one venue for this discussion, and reduce the
cross-posting? Is any MIB Doctor that is following this discussion not
subscribed to opsawg? Can we have this discussion there?

dbh