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, 1 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