IETF Logo Mail Archive

Re: [netmod] AD review of draft-ietf-netmod-system-mgmt

Martin Bjorklund <mbj@tail-f.com> Fri, 13 December 2013 11:15 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA41AE2D1 for <netmod@ietfa.amsl.com>; Fri, 13 Dec 2013 03:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5g6Z13k4rFB for <netmod@ietfa.amsl.com>; Fri, 13 Dec 2013 03:15:17 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA461ADEDC for <netmod@ietf.org>; Fri, 13 Dec 2013 03:15:17 -0800 (PST)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A04B737C041; Fri, 13 Dec 2013 12:15:09 +0100 (CET)
Date: Fri, 13 Dec 2013 12:15:09 +0100
Message-Id: <20131213.121509.688716145908885068.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <m2sitxoy68.fsf@nic.cz>
References: <B386C034-A59A-4374-9846-6F2F821A0941@nic.cz> <CABCOCHTD_8kqHvqZGE8x1-bAWYZ4-1vRRXLpqdSRLH+tQV3eow@mail.gmail.com> <m2sitxoy68.fsf@nic.cz>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2013 11:15:19 -0000

Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.com> writes:
> 
> > On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka <lhotka@nic.cz>
> > wrote:
> >
> >> Hi,
> >>
> >> just an idea: would it help if the server simply records the mapped
> >> DisplayString version in state data?
> >>
> >>
> > No.  I am OK with the proposal to force the server to constrain the
> > objects
> 
> Why not, actually? I mean something like this:
> 
> { "system-state" : {
>     ...
>     "location" : "Schrödingerstraße",
>     "mib:sysLocation" : "Schroedingerstrasse",
>     ...
> }
> 
> This is similar to what Randy proposed with "legacy-location", but it
> is in *state*, so it doesn't introduce a second configuration object.

But why report the MIB object at all in this case?

If we decide these objects are really separate, I don't see the need
to report the MIB object.  A manager that wants to see the SNMP object
in addition to the NETCONF object (for some reason) can use SNMP.


/martin

v2.23.0 | Report a Bug | By Email