Re: [Agentx] Empty context in rfc2742
Mark Ellison <ellison@ieee.org> Tue, 01 September 2009 11:53 UTC
Return-Path: <mark@ellisonsoftware.com>
X-Original-To: agentx@core3.amsl.com
Delivered-To: agentx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209673A6997 for <agentx@core3.amsl.com>; Tue, 1 Sep 2009 04:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.327
X-Spam-Level:
X-Spam-Status: No, score=-101.327 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kZHiq0Z-tQ9 for <agentx@core3.amsl.com>; Tue, 1 Sep 2009 04:53:49 -0700 (PDT)
Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id 432A03A6880 for <agentx@ietf.org>; Tue, 1 Sep 2009 04:53:49 -0700 (PDT)
Received: by ywh4 with SMTP id 4so8987401ywh.17 for <agentx@ietf.org>; Tue, 01 Sep 2009 04:53:58 -0700 (PDT)
MIME-Version: 1.0
Sender: mark@ellisonsoftware.com
Received: by 10.150.240.15 with SMTP id n15mr11394626ybh.212.1251806038083; Tue, 01 Sep 2009 04:53:58 -0700 (PDT)
In-Reply-To: <1251750777.5149.52.camel@sara.home>
References: <1251623843.6043.6.camel@sara.home> <8a0268750908301048i2b4a477dod97e582238098bbe@mail.gmail.com> <1251668476.3736.14.camel@sara.home> <8a0268750908301523o390d9ff1kc951bfb24d49c9e1@mail.gmail.com> <1251750777.5149.52.camel@sara.home>
Date: Tue, 01 Sep 2009 07:53:58 -0400
X-Google-Sender-Auth: cd19456a50f72bd3
Message-ID: <8a0268750909010453ld959065ife382929301ace69@mail.gmail.com>
From: Mark Ellison <ellison@ieee.org>
To: Magnus Fromreide <magfr@lysator.liu.se>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: agentx@ietf.org
Subject: Re: [Agentx] Empty context in rfc2742
X-BeenThere: agentx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SNMP Agent Extensibility <agentx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/agentx>, <mailto:agentx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/agentx>
List-Post: <mailto:agentx@ietf.org>
List-Help: <mailto:agentx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/agentx>, <mailto:agentx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2009 11:53:50 -0000
Hi Magnus On Mon, Aug 31, 2009 at 4:32 PM, Magnus Fromreide<magfr@lysator.liu.se> 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
- [Agentx] Empty context in rfc2742 Magnus Fromreide
- Re: [Agentx] Empty context in rfc2742 Mark Ellison
- Re: [Agentx] Empty context in rfc2742 Magnus Fromreide
- Re: [Agentx] Empty context in rfc2742 Mark Ellison
- Re: [Agentx] Empty context in rfc2742 Magnus Fromreide
- Re: [Agentx] Empty context in rfc2742 Mark Ellison
- Re: [Agentx] Empty context in rfc2742 Randy Presuhn
- Re: [Agentx] Empty context in rfc2742 Magnus Fromreide