Re: [Agentx] Empty context in rfc2742

"Randy Presuhn" <> Tue, 01 September 2009 19:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D06F228C72C for <>; Tue, 1 Sep 2009 12:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.663
X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yMhOamHZW4WM for <>; Tue, 1 Sep 2009 12:15:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ED0413A6C71 for <>; Tue, 1 Sep 2009 12:15:12 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327;; b=py4ZKcYi6igd8/AUWF2TXt1yVA4wLWqoFj/Qp2wN1e8ay7d2x5rB0Is/vX4KDlmO; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [] (helo=oemcomputer) by with esmtpa (Exim 4.67) (envelope-from <>) id 1MiYdY-0005og-0F for; Tue, 01 Sep 2009 15:03:24 -0400
Message-ID: <007801ca2a6e$2bc23f00$6801a8c0@oemcomputer>
From: "Randy Presuhn" <>
To: <>
References: <1251623843.6043.6.camel@sara.home><><1251668476.3736.14.camel@sara.home><> <1251750777.5149.52.camel@sara.home>
Date: Mon, 31 Aug 2009 12:06:38 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9a7e9e1b187221c911018c22155847ecf350badd9bab72f9c350badd9bab72f9c
Subject: Re: [Agentx] Empty context in rfc2742
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SNMP Agent Extensibility <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Sep 2009 19:15:39 -0000

Hi -

> From: "Magnus Fromreide" <>
> To: "Mark Ellison" <>
> Cc: <>
> 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.
> 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

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.