Subject: [Agentx] Clarification of RFC 2741, section 5.1

From: Frank Fock <[email-masked]>
Date: Thu, 15 Feb 2007 22:43:34 +0100

Hi,

I have been pointed to an interoperability problem between
two different AgentX implementations regarding the encoding
of a zeroDotZero (0.0) object identifier on the wire.

 From the AgentX object identifier encoding rules, I would
expect an encoding as:

0002 0000 0000 0000
0000 0000 0000 0000
0000 0000 0000 0000

However section 5.1 of RFC 2741 says:

    "A null Object Identifier consists of the
     4-byte header with all bytes set to 0."

which would be:

0000 0000 0000 0000

I think the term "null Object Identifier" refers to a zero
length OID rather than the 0.0 OID, because otherwise
the length field would be inconsistently used. Is this
assumption true?

If yes, in an upcoming update of the RFC 2741 "null"
should be rephrased as "zero length", shouldn't it?

Because in SNMP BER a zero length OID cannot be
encoded, I am not sure if it is wise to allow such an
OID to be encoded for AgentX?

Regards,
Frank Fock

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 20 Feb 2007 02:49:45 -0500 (EST)

Hi -

>From: Frank Fock <[email-masked]>
>Sent: Feb 19, 2007 1:29 PM
>To: Randy Presuhn <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [Agentx] Clarification of RFC 2741, section 5.1
...
>However, the original interoperability problem
>arose because a subagent encoded a 0.0 OID for
>an ifSpecific instance with four zero bytes
>which the master agent did not accept because
>it interpreted it as a zero length OID which
>cannot be mapped to BER.

I think we're in agreement -

Returning the "null" (rather than the 0.0 object identifier)
as the value portion of a variable binding which is supposed
to have an OBJECT IDENTIFIER as its value is clearly
an error.

>In my opinion, an AgentX subagent should encode
>a 0.0 OID as 12 bytes with the first byte as 2.

Yes.

>Otherwise there would be two possible encodings
>for 0.0 since RFC2471 does not forbid the 12 byte
>representation and master as well as sub-agents
>would need additional code that handles the
>special null encoding.

Yes.  Adding this option would increase complexity but
add very little value.

>I agree with the quote below and thus, I think
>we can reach consensus if we explicitly limit
>the usage of the AgentX null OID encoding to
>AgentX specific values (i.e., search range
>boundaries and the agent OID in a AgentXOpenPdu).
>As a consequence of this, an AgentX sub-agent
>would need to always encode a variable binding's
>OID value of 0.0 with 12 bytes.
>
>Any comments?

I agree that this special null should only be used in the
cases described in the specification.  I'm wary of your
clarification as currently worded, since the strings "null", "Null",
and "NULL" appear in several other locations in the
document.  In particular, we don't want to inadvertantly
break the language about null in a VarBindList.

>Best regards,
>Frank Fock
>
>Randy Presuhn wrote:
>
>> 
>> The problem is that the two phrases are not interchangeable.
>> The (only) cases where null Object Identifier can be used are
>> the ones specifically identified in RFC 2741.  It really is a sentinel
>> value that is outside the range of possible object identifiers,
>> rather than an oid that doesn't exist.

Randy