Subject: Re: RFC 2741 clause 5.1

From: Randy Presuhn <[email-masked]>
Date: Tue, 12 Mar 2002 15:39:23 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> Date: Tue, 12 Mar 2002 18:22:51 -0500
> From: Mark Ellison <[email-masked]>
> To: [email-masked]
> Subject: Re: RFC 2741 clause 5.1
> References: <[email-masked]>
> List-Id: IETF Agentx Working Group mailing list <agentx.dorothy.bmc.com>
...
> >     - a zero-length object identifier;
> 
> >From my reading of clause 5.1 this is not possible.
> I interpret "A null object identifier consists of the 4-byte header with
> all bytes set to 0" as meaning "0.0"

The sentence seems backwards.  As it is currently worded, it
also seems to permit 0.0 to be encoded as 0x020000000000000000000000.

...
> >     - an object identifier consisting of a single element;
> > 
> >     - an object identifier in which the first element has
> >       a value other than 0, 1, or 2.
> 
> Could happen under clause 5.1.  When presented with this circumstance,
> EOP clause 7.1.(5) for admin messages provides a means to terminate
> processing with an error of processingError(268).
> 
> One could also interpret EOP clause 7.1.(2) as including malformed OIDs,
> so parseError(266) may also be a remedy for admin messages.
> 
> I do not see any admin messages where the master originates an OID and
> transfers to subagent.
> 
> > 
> > Three specific sub-cases for each of these come to mind:
> > 
> >     - notification (snmpTrapOID.0)
> > 
> >     - varbind values in general
> > 
> >     - varbind names in general
> > 
> > What is a master agent to do if it gets one of these beasts?
> > What is a subagent supposed to do with them?
> 
> Since the master provides the OIDs from the snmp-request to the subagent
> (EOP 7.2.1.*), it follows that a subagent would not see any malformed
> OID names or values during its processing (EOP 7.2.2, 7.2.3.*).

This assumes that master agents are bug-free.

> Should the master receive an agentx response (or agentx-Notify-PDU) with
> a malformed OID (EOP 7.2.5.*, 7.2.6), the directions are not
> particularly clear.  
> 
> If the malformed OID is a name, then the object "must be out of view"
> (my own interpretation).  
...

rather than treating it as a parse error, as suggested earlier?
If treated as "out of view", the mal-formed thing would have to
be sent back by the subagent.  I don't like requiring libraries
to be able to encode things that are arguably protocol errors.

> If the malformed OID is a value, then this may not be caught until the
> SNMP response PDU is being formed.  At this time, (RFC 1905 clause
> 4.2.*) the malformed value would be promoted to a genErr(5) for the
> error_status of the SNMP response PDU.  In a master implemtation that
> tracks subagent misbehavior, enough promotions to genErr during
> snmp-response encoding might cause the master to send an
> agentx-Close-PDU to the offending subagent with a
> c.reason=reasonOther(1).
...

For responses to set requests, the "WrongEncoding" error
status might be a less catastrophic way to signal these.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Mark Ellison <[email-masked]>
Date: Tue, 12 Mar 2002 19:28:18 -0500

Hi Randy,

A couple more comments inline.

> also seems to permit 0.0 to be encoded as 0x020000000000000000000000.

n_subid=2 with  each subid=0 is also a fine way to express "0.0"  Both
ways are good as far as I'm concerned.

> This assumes that master agents are bug-free.

Well, the subagent wouldn't see any malformed OID names or values
introduced by the AgentX processing within the master.
If there is a bug within the master causing such behavior, the fix would
be need to occur within the SNMP processing code of the master, and not
within the agentx processing code.  (Apologies for foisting a misguided
assumption when my intention was to reduce and partition the problem :-)

> rather than treating it as a parse error, as suggested earlier?

The parse error suggested earlier was for admin messages.  

The EOP for subagent responses to SNMP protocol messages does not
provide explicit text with respect to malformed OIDs. Clause 5.1 allows
some degree of freedom for the malformed OID to NOT be a parse error.

> to be able to encode things that are arguably protocol errors.

I agree.  However clause 5.1 does provide some leeway, so could happen. 
5.1 allows for OID fragments.

> status might be a less catastrophic way to signal these.

Assuming that the master is transferring malformed OID names and values
(how did these get encoded into the SNMP request in the first place?),
then a subagent response with wrongEncodingwrongLength/wrongValue would
be a good thing.  It would be even better if the master noticed this
before propagating and dispatching to the subagent.