Re: Empty context in rfc2742

> Hi -
>
> > From: "Magnus Fromreide" <magfr@...>
> > To: "Mark Ellison" <ellison@...>
> > Cc: <agentx@...>
> > 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.

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

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