Re: [Agentx] Empty context in rfc2742

[Magnus Fromreide <[e-mail]>]

On Mon, 2009-08-31 at 12:06 -0700, Randy Presuhn wrote:
> Hi -
> 
> > From: "Magnus Fromreide" <[e-mail]>
> > To: "Mark Ellison" <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Monday, August 31, 2009 1:32 PM
> > Subject: Re: [Agentx] Empty context in rfc2742
> ...
> > 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.
> 
> 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.

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.

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

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

Thanks for your patience.

> > 
> > 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 ""
> > 
> > The question is what the value of the agentxRegContext column for
> > 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.

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