Re: [NGO] external module properties

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 28 April 2008 08:06 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 E074E3A6AC9; Mon, 28 Apr 2008 01:06:41 -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 210C23A6CD7 for <ngo@core3.amsl.com>; Mon, 28 Apr 2008 01:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.356, 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 wA0EPGWt-K02 for <ngo@core3.amsl.com>; Mon, 28 Apr 2008 01:06:33 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 89EC628C231 for <ngo@ietf.org>; Mon, 28 Apr 2008 01:06:29 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B51D1C0017; Mon, 28 Apr 2008 10:06:30 +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 ZYlpxb364XLX; Mon, 28 Apr 2008 10:06:26 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 158C0C001A; Mon, 28 Apr 2008 10:06:24 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8B1D054AE0B; Mon, 28 Apr 2008 10:06:25 +0200 (CEST)
Date: Mon, 28 Apr 2008 10:06:25 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <ietf@andybierman.com>
Message-ID: <20080428080625.GA23300@elstar.local>
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>, Jon Saperia <saperia@jdscons.com>, NETCONF Goes On <ngo@ietf.org>
References: <48137444.6070802@andybierman.com> <20080426203103.GA22324@elstar.local> <4813A0EC.50209@andybierman.com> <20080427061550.GB22643@elstar.local> <5D258F3C-D164-4759-B743-45B33CEF2A6E@jdscons.com> <4814A0A1.4040507@andybierman.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4814A0A1.4040507@andybierman.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 Sun, Apr 27, 2008 at 08:49:53AM -0700, Andy Bierman wrote:

> My point is that we need to thinking more holistically about the
> entire management system, which includes problems such as human factors
> and module life-cycle.

A data modeling language specification is the wrong place to address
human factors.

> We tried the 'blinders-on' approach with SMING/EOS and that didn't
> work out so well.  Focusing on the DML and ignoring the protocol (or
> vice versa) leads to incomplete or broken solutions.

YANG is NETCONF very specific; it is by its very design a domain
specific language for NETCONF data models and not comparable to
SMING/EOS.

> Of course the namespace URI is mandatory, because it is needed
> to properly implement the NETCONF protocol.  The 'YANG philosphy'
> (whatever that is) has nothing to do with it.  Likewise, the
> revision date is needed to properly implement NETCONF applications.

There is a fine distinction here between a language definition their
implementations and the usage of a language in a larger context. For
me, a missing revision statement is something I like to generate a
warning for but it is not an error since NETCONF continues to function
without the revision information.

Note that I am not concerned about this particular case so much; I am
concerned the logic behind. The SMI has been full of CLRs in order to
make this a better world and with YANG we tried to get over this and
we tried to reduce CLRs to a minimum, leaving the specification of
CLRs to CLR documents (called coding styles in the software world and
guidelines in this space).

> YANG is not decoupled from NETCONF, and NETCONF is not decoupled
> from the actual CM problem space.  One needs to consider that sometimes
> CLRs are really CBRs, and important for real interoperability.

Which one of <http://en.wikipedia.org/wiki/CBR> do you mean? I guess
you mean the "Comic_Book_Resources". ;-)

/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