Re: [NGO] external module properties

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 28 April 2008 17:48 UTC

Return-Path: <ngo-bounces@ietf.org>
X-Original-To: ngo-archive@optimus.ietf.org
Delivered-To: ietfarch-ngo-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7743A6A18; Mon, 28 Apr 2008 10:48:48 -0700 (PDT)
X-Original-To: ngo@core3.amsl.com
Delivered-To: ngo@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6B43A6A18 for <ngo@core3.amsl.com>; Mon, 28 Apr 2008 10:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.933
X-Spam-Level:
X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 2dMmhTc-EiTs for <ngo@core3.amsl.com>; Mon, 28 Apr 2008 10:48:46 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C86823A69C7 for <ngo@ietf.org>; Mon, 28 Apr 2008 10:48:45 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EED92C000B; Mon, 28 Apr 2008 19:48:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ki9xx3YzCixu; Mon, 28 Apr 2008 19:48:42 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D9BEC0013; Mon, 28 Apr 2008 19:48:41 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 66DC754BCC5; Mon, 28 Apr 2008 19:48:41 +0200 (CEST)
Date: Mon, 28 Apr 2008 19:48:41 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: David Harrington <ietfdbh@comcast.net>
Message-ID: <20080428174841.GB24357@elstar.local>
Mail-Followup-To: David Harrington <ietfdbh@comcast.net>, 'Andy Bierman' <ietf@andybierman.com>, 'NETCONF Goes On' <ngo@ietf.org>
References: <4815D8DB.3040301@andybierman.com> <001a01c8a955$36392c50$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <001a01c8a955$36392c50$0600a8c0@china.huawei.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Cc: 'NETCONF Goes On' <ngo@ietf.org>
Subject: Re: [NGO] external module properties
X-BeenThere: ngo@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: j.schoenwaelder@jacobs-university.de
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <ngo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ngo>
List-Post: <mailto:ngo@ietf.org>
List-Help: <mailto:ngo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ngo-bounces@ietf.org
Errors-To: ngo-bounces@ietf.org

On Mon, Apr 28, 2008 at 01:27:59PM -0400, David Harrington wrote:
 
> It is important for an NMS to be able to tell which version of a data
> model is supported by a managed element, so when it makes changes to a
> configuration, it can make changes appropriate to the version
> supported.

> On a side note, keep in mind that some managed elements may have
> multiple components, such as blades in a chassis, and the versions
> supported might differ, so a Netconf server might also need to know
> which version to use to perform validation.

I seems you are talking about version information you won't get from
the YANG module itself; at least as long as we do not do versioned
imports. I hear you saying you want a definition of what the various
thingies in a managed element actually support; which is was we called
agent capabilities in the SMIv2. In fact, if you look how SMIv2
compliance and agent capabilities work, you will see that they do not
even refer to a specific version of a MIB module.

Perhaps people have a different versioning model in mind than what
SMIv2 used to have. Then I think this needs to be discussed first.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
NGO mailing list
NGO@ietf.org
https://www.ietf.org/mailman/listinfo/ngo