Subject: Re: [Agentx] Empty context in rfc2742

From: Mark Ellison <[email-masked]>
Date: Tue, 1 Sep 2009 07:53:58 -0400

Hi Magnus

On Mon, Aug 31, 2009 at 4:32 PM, Magnus Fromreide<[email-masked]> wrote:
>
> As I understand 2742 agentxRegistrationTable is a view into the set of
> registrations that the sessions have done with the master agent and thus
> the values of that table should match the values in the actual
> registrations as far as possible.

Agreed.

> While this is true it is also true that the agent is free to map the
> AgentX-contexts to SNMP-contexts however it wish so I think this impose
> no limits on the values of AgentX-contexts.

Disagreed.

> This question is only regarding the _values_ of the agentxRegContext
> column.
>
> As I said above it believe that agentxRegContext should represent the
> values of the AgentX-context for all AgentX-registrations that is made
> on the AgentX-side of the master agent.

Agreed.

> The problem is that the value set for AgentX-context contains one
> element more than the value set for OCTET STRING.
>
> I am asking how the AgentX-context value that don't fit into the mapping
> from AgentX-context to agentxRegContext should be handled.
>
> EXAMPLE:
>
> Assume that two AgentX registrations are made to a master agent that
> implements rfc 2741 and rfc 2742.
>
> 1: { r.flags = 0, <no r.context>, ... }
> 2: { r.flags = NON_DEFAULT_CONTEXT, r.context = "", ... }
>
> Now as I read 2742 the value of the agentxRegContext column for
> registration #1 is ""

Agreed.

> The question is what the value of the agentxRegContext column for
> registration #2 should be?

I think the agent should reject this registration and suggest that the
agent should accept registrations in the non default context only when
the r.context length > 0.

The zero-length context name is reserved for the default context.
This is because the AgentX context names are mapped from SNMP context
names - RFC 3411, section 3.3 shows the default context as being the
zero-length string.  Non-default context names have a string length
greater than zero.

As such, it stands to reason that an AgentX registration per #2 above
will not be visible to an SNMP client/manager/command-generator
application and serves no useful purpose.

-- Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 31 Aug 2009 12:06:38 -0700

Hi -

> From: "Magnus Fromreide" <[email-masked]>
> To: "Mark Ellison" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, August 31, 2009 1:32 PM
> Subject: Re: [Agentx] Empty context in rfc2742
...
> no limits on the values of AgentX-contexts.

This would be an incredibly bad idea.  Perhaps section 6.1.1 of RFC 2741
could be more explicit, but to my knowledge no one has ever come to a
different conclusion in deciding how to implement this.

Furthermore, 6.1.1 of RFC 2741 says:
   If the NON_DEFAULT_CONTEXT bit in the AgentX header field h.flags is
   clear, then there is no context field in the PDU, and the operation
   refers to the default context.  (This does not mean there is a zero-
   length Octet String, it means there is no Octet String present.)  If
   the NON_DEFAULT_CONTEXT bit is set, then a context field immediately
   follows the AgentX header, and the operation refers to that specific
   context.  The context is represented as an Octet String.  There are
   no constraints on its length or contents.

What does this mean?  It means that there happen to be two ways
to encode the default context. 
   (1) set the NON_DEFAULT_CONTEXT bit to 0, and omit the
         context field which would otherwise immediately follow.
   (2) set the NON_DEFAULT_CONTEXT bit to 1,  and follow it
         with the properly encoded zero-length string.

Obviously, (2) is not encouraged, since (1) provides a more efficient
encoding and we all know how parsimonious AgentX encodings are.  :-)

> element more than the value set for OCTET STRING.

No, it doesn't.  It merely provides two ways of encoding the zero-length
string, used to represent the default context.
 
> registration #2 should be?

Exactly the same.  These are two attempts to register for the same
context.

I seem to recall a long-ago discussion about whether the latter should
be treated as a protocol error.  I don't recall the outcome of that discussion.
As an implementor, my inclination would be to accept it, but never generate it.

Randy

---

From: Magnus Fromreide <[email-masked]>
Date: Wed, 02 Sep 2009 00:40:31 +0200

> different conclusion in deciding how to implement this.

Oh well, my mind must be twisted.

I would probably have treated the default context as the default value
for all contexts and then each distinct context would override it but I
haven't given the consequences of that much thought.

Now I am aware of the intended way.

> encoding and we all know how parsimonious AgentX encodings are.  :-)

Well, from the discussion I think it is obvious that I think that could
be stated clearer.

Thanks for your patience.

> As an implementor, my inclination would be to accept it, but never generate it.

I would prefer to generate an error in order to make for a less
forgiving protocol so that errors are caught earlier and the protocol is
kept smaller but I know that is against the "be lenient in what you
accept" motto.  

/MF