Subject: RE: RFC 2741 clause 5.1

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 12 Mar 2002 23:27:27 +0100

Inline

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Tuesday, March 12, 2002 7:01 PM
> To: [email-masked]
> Subject: RFC 2741 clause 5.1
> 
> 
> Hi -
> 
> Dave Perkins' recent query on the SNMPv3 list prompted me
> to take a look at the AgentX specification's rules for
> object identifier encoding.  Specifically, the ad hoc
> encoding rules in clause 5.1 of RFC 2741 permit object
> identifier values that could not be represented in BER.
> Examples:
> 
>     - a zero-length object identifier;
> 
>     - 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.
> 
I think that we mean that they should be valid OIDs, or at least
translatable to valid OIDs (for example if we use prefix,
then the OID needs to be composed).
I do not quickly see where we spell it out though.
Maybe when we get our next chance (when/if we adavance to std?)
then we should/could add some words to clarify that.

> 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?
> 
Assuming that we agree that we only want to handle valid OIDs,
then I think that step 5 on page 46 migth apply.

Bert

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 12 Mar 2002 14:46:17 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: Randy Presuhn <[email-masked]>, [email-masked]
> Subject: RE: RFC 2741 clause 5.1
> Date: Tue, 12 Mar 2002 23:27:27 +0100
...
> I do not quickly see where we spell it out though.

Indeed, the definition that's currently there defines the
n_subid field as having a range of 0 to 128.

> then we should/could add some words to clarify that.

This seems reasonable to me.

...
> then I think that step 5 on page 46 migth apply.
...

This also seems reasonable to me.

Do anyone's test cases currently exercise these
syntactic possibilities?

 ------------------------------------------------------
 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: Randy Presuhn <[email-masked]>
Date: Tue, 12 Mar 2002 16:35:31 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> Date: Tue, 12 Mar 2002 19:28:18 -0500
> From: Mark Ellison <[email-masked]>
> Subject: Re: RFC 2741 clause 5.1
> References: <[email-masked]>
...
> > For responses to set requests, the "WrongEncoding" error
> > 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?),

They couldn't.  Either the master agent is getting something
ill-formed, is not treating it as a parse error (witness the
recent CERT advisory) and is producing a correspondingly bogus
agentx encoding; or it is getting something well-formed
and has an error in transforming it from BER into the funky
agentx encoding.

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

If all master agents are bug-free, these PDUs won't
be perpetrated, except perhaps by Finnish university
students.  :-)

---

From: "Natale, Robert C (Bob)" <[email-masked]>
Date: Fri, 15 Mar 2002 14:09:11 -0500

Hi folks,

> > i don't think anything else need be (over) specified.
> ...
> 
> I don't like overspecification, either, but your example
> illustrates a case where the protocol lets us do things
> that the AgentX MIB can't support.  I think this is a
> sub-optimal state of affairs. 

I agree.

I think the best way to remove this sub-optimality at this
point is to declare an "implementation agreement" that says
that white the protocol spec literally allows a single sub-
id OID value to be passed in an AgentX PDU it was nor the
intent of the WG to allow for representations that break
SNMP rules or established SNMP convention in this respect.

Hence:

  a) Sub-agents SHOULD NOT use the single sub-id
     representation; and

  b) Master agents MUST NOT use the single sub-id
     representations; and

  c) Master agents MUST accept the single sub-id
     representation from sub-agents but MUST treat
     it as though it were a minimally sized OID
     of the form n.m, where n is 0 and m is the
     single sub-id value passed by the sub-agent.

Forgive any gross errors in that suggestion...feel free
(anyone, everyone!) to revise it as needed or point out
why it must be discarded entirely.

Assuming it survives in some recognizable form, we can
record it, following WG consensus, in an update to our
charter (for posterity's sake) and address it as a
clarification change to the specs when they come up for
Full standard review down the road.

Cordially,

BobN