|
»
« Return to Thread: Empty context in rfc2742
Re: Empty context in rfc2742
by Randy Presuhn
::
Rate this Message:
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. :-)
> 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.
>
> The problem is that the value set for AgentX-context contains one
> 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.
> 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 ""
>
> 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.
Randy
> 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. :-)
> 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.
>
> The problem is that the value set for AgentX-context contains one
> 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.
> 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 ""
>
> 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.
Randy
« Return to Thread: Empty context in rfc2742
| Free embeddable forum powered by Nabble | Forum Help |
