Re: [Agentx] Empty context in rfc2742

Mark Ellison <ellison@ieee.org> Sun, 30 August 2009 22:23 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 7C2833A6D07 for <agentx@core3.amsl.com>; Sun, 30 Aug 2009 15:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.917
X-Spam-Level:
X-Spam-Status: No, score=-101.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 NDaDRvM24Tym for <agentx@core3.amsl.com>; Sun, 30 Aug 2009 15:23:19 -0700 (PDT)
Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id 7EEC23A6A2A for <agentx@ietf.org>; Sun, 30 Aug 2009 15:23:19 -0700 (PDT)
Received: by gxk26 with SMTP id 26so1988530gxk.18 for <agentx@ietf.org>; Sun, 30 Aug 2009 15:23:26 -0700 (PDT)
MIME-Version: 1.0
Sender: mark@ellisonsoftware.com
Received: by 10.151.28.10 with SMTP id f10mr7643485ybj.71.1251671006441; Sun, 30 Aug 2009 15:23:26 -0700 (PDT)
In-Reply-To: <1251668476.3736.14.camel@sara.home>
References: <1251623843.6043.6.camel@sara.home> <8a0268750908301048i2b4a477dod97e582238098bbe@mail.gmail.com> <1251668476.3736.14.camel@sara.home>
Date: Sun, 30 Aug 2009 18:23:26 -0400
X-Google-Sender-Auth: 571939c3c6f63cb4
Message-ID: <8a0268750908301523o390d9ff1kc951bfb24d49c9e1@mail.gmail.com>
From: Mark Ellison <ellison@ieee.org>
To: Magnus Fromreide <magfr@lysator.liu.se>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Sun, 30 Aug 2009 22:23:20 -0000

Hi Magnus-

On Sun, Aug 30, 2009 at 5:41 PM, Magnus Fromreide<magfr@lysator.liu.se> wrote:
> On Sun, 2009-08-30 at 13:48 -0400, Mark Ellison wrote:
>> On Sun, Aug 30, 2009 at 5:17 AM, Magnus Fromreide<magfr@lysator.liu.se> wrote:
>> > Hello.
>> >
>> > According to rfc2742 agentxRegContext (octet string) is
>> >     "The context in which the session supports the objects in this
>> >      region.  A zero-length context indicates the default context.
>> >     "
>> >
>> > Now I am would like to know how a zero-length context should be
>> > represented?
>> >
>> The default context is an OCTET STRING of zero-length.
>
> Not according to RFC 2741 6.1.1 §4.
>
> In agentxRegContext we are looking a AgentX registrations and in this
> domain it is explicitly stated that NON_DEFAULT_CONTEXT "" is distinct
> from DEFAULT_CONTEXT but I can see no provision for the MIB to represent
> that.

Thanks for this reference- your original question was in regard to RFC
2742.  As the agentxRegContext object-type definition states, "A
zero-length context indicates the default context".  I believe this is
consistent with my previous reply.

The 2741 section cited above applies to the AgentX header.
Effectively, for 2742 you won't have a zero-length context name for a
non default context.

In the SNMP, the AgentX context is mapped from the SNMPv3 contextName
in the scoped PDU (most current is 3411 sxn 3.3.3).  Since every
contextName within an SNMP entity MUST be unique there can not be both
the default context and a non default context with a zero-length
string.

>
>> How to represent this depends upon where it is being represented.
>>
>> On the wire, the tag is "OCTET STRING" the length is zero(0) and the
>> value occupies no octets.  There are numerous examples of OCTET
>> STRINGs that may be zero-length in IETF standard MIB modules.
>>
>> For example, in the UsmUserTable, the usmUserPublic may be a
>> zero-length string.  In the USM MIB module, tthe usmUserPublic object
>> definition shows he zero-length string as represented by the DEFVAL
>> clause:  { ''H }  -- the empty string.
>>
>> A zero-length string and the empty-string are synonymous.
>
> This is about the specific case of AgentX - we are talking about a
> zero-length string and a non-existing string.
>
>> - Mark
>> http://EllisonSoftware.com
>