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

From: Randy Presuhn <[email-masked]>
Date: Mon, 19 Feb 2007 11:26:07 +0700 (GMT+07:00)

Hi -

>From: Magnus Fromreide <[email-masked]>
>Sent: Feb 18, 2007 1:36 PM
>To: Randy Presuhn <[email-masked]>
>Cc: Frank Fock <[email-masked]>, [email-masked]
>Subject: Re: [Agentx] Clarification of RFC 2741, section 5.1
...
>> No.  There is no such thing as a zero-length OID in ASN.1
>> That is why 0.0 was usurped.
>
>Interesting. I have always interpreted the term "null Object Identifier"
>to mean "an object identifier that most certainly doesn't exist - a NULL
>value" and seen it as a placeholder value where an OID is needed.

Unfortunately, ASN.1 didn't define such a creature.  The 0.0
(which technically belongs to another organization!) has long
been used in the IETF to cover this case in SNMP.  But
AgentX, with its ad hoc encoding scheme, does something
different.  The "null", as something that just doesn't exist
in BER, is used for special semantics in ranges and lists.

...
>So a valid search range covering all oid's but 0.0 is one of
>
>0002 0000 0000 0000
>0000 0000 0000 0000
>0000 0000 0000 0000
>0002 0000 0000 0000
>0000 0000 0000 0000
>0000 0000 0000 0000

No, this is an empty search range.

>0000 0000 0000 0000
>0002 0000 0000 0000
>0000 0000 0000 0000
>0000 0000 0000 0000

This would be an ill-formed range, IMO.

>0002 0000 0000 0000
>0000 0000 0000 0000
>0000 0000 0000 0000
>0000 0000 0000 0000

This would be the entire OID space, including
the 0.0 subtree, but exluding 0.0 itself

>and
>0000 0000 0000 0000
>0000 0000 0000 0000

This would be an ill-formed range, IMO.

>and one that covers all oid's is either
>
>0002 0000 0001 0000
>0000 0000 0000 0000
>0000 0000 0000 0000
>0002 0000 0000 0000
>0000 0000 0000 0000
>0000 0000 0000 0000

No, this would be an error, IMO.  It says search the
0.0 subtree, including 0.0, but end the search before 0.0.

>or
>0002 0000 0001 0000
>0000 0000 0000 0000
>0000 0000 0000 0000
>0000 0000 0000 0000

This is correct.

>if I understand you correctly, or is it so that the two representations
>are unequal so that
>
>0002 0000 0000 0000
>0000 0000 0000 0000
>0000 0000 0000 0000
>
>isn't a null object identifier while
>
>0000 0000 0000 0000

The former { 0 0 }  is what frequently is *called* a null
object idea, since it serves that placehiolder function in BER.

The latter is a special AgentX invention.

>is? If that is the case then that seems inconsistent as well, as they
>are the same in al other ways.

The AgentX "null" is required in several cases in 2741, while
2741 never mentions 0.0, as far as I know.  I can't think of
a case where they are interchangeable, but perhaps someone
who's been around agentx more recently could chime in.
(There are cases where an AgentX null can show up as an
ASN.1 0.0 in BER, but those are MIB mappings.)

>I think the standard was cleaner with my interpretation of "null Object
>Identifier" as a non-existant oid.

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.

>/Magnus Fromreide

Randy

---

From: Frank Fock <[email-masked]>
Date: Mon, 19 Feb 2007 19:29:39 +0100

Hi,

I understand that the special null OID encoding
represented by four zero bytes has a different
meaning in AgentX search requests than a 0.0
OID.

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.

In my opinion, an AgentX subagent should encode
a 0.0 OID as 12 bytes with the first byte as 2.
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.

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?

Best regards,
Frank Fock