Re: [NGO] external module properties

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Sun, 27 April 2008 06:16 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 591113A6AD2; Sat, 26 Apr 2008 23:16:19 -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 78A143A69EE for <ngo@core3.amsl.com>; Sat, 26 Apr 2008 23:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.869
X-Spam-Level:
X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.380, 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 MJRaZvNG5ACJ for <ngo@core3.amsl.com>; Sat, 26 Apr 2008 23:16:17 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 445403A6AD2 for <ngo@ietf.org>; Sat, 26 Apr 2008 23:15:53 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 087A1C0017; Sun, 27 Apr 2008 08:15:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JXxFNfz06n+B; Sun, 27 Apr 2008 08:15:51 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26958C0008; Sun, 27 Apr 2008 08:15:50 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 658B054A5A9; Sun, 27 Apr 2008 08:15:50 +0200 (CEST)
Date: Sun, 27 Apr 2008 08:15:50 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <ietf@andybierman.com>
Message-ID: <20080427061550.GB22643@elstar.local>
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>, NETCONF Goes On <ngo@ietf.org>
References: <48137444.6070802@andybierman.com> <20080426203103.GA22324@elstar.local> <4813A0EC.50209@andybierman.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4813A0EC.50209@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 Sat, Apr 26, 2008 at 02:38:52PM -0700, Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
> > On Sat, Apr 26, 2008 at 11:28:20AM -0700, Andy Bierman wrote:
> >  
> >> LAST-UPDATED and REVISION are optional in SMIv2.
> > 
> > This is not correct. The SMIv2 does mandate a LAST-REVISION clause
> > (see section 5 and 5.1 of RFC 2578).  The IETF guidelines in addition
> > mandate the presence of REVISION clauses and the LAST-UPDATED clause
> > becomes redundant when you have REVISION clauses. That is why YANG
> > only has revision statements.
> 
> some modules like SNMPv2-TC have no MODULE-IDENTITY section

The modules SNMPv2-SMI, SNMPv2-TC, SNMPv2-CONF defintion the language
itself and are not proper MIB modules anyway. And in any case, a
counter example would not invalidate what is written down in RFC 2578.
 
> > The YANG language itself does not mandate the presence of one or more
> > revision statements. This is consistent with YANG's philosophy of
> > mandating only those things that are essential for the language to
> > function and leave other things to guidelines or applicability
> > definitions.
> 
> I think the NETMOD philosophy should consider the entire
> network configuration problem, which includes properties like
> module version.

It does. There is a revision statement and all the other stuff needed
for the entire network configuration problem.

> > PS: If YANG were to support versioned imports, revision clauses
> >     would have to be mandatory because without version information,
> >     a compiler would not be able to resolve imports. Right now,
> >     compilers can do the right thing without having revision
> >     statements and hence they are optional.
> 
> External entities (humans, applications) need to be able to distinguish
> between multiple versions of the same module.  Why does a YANG module
> need to include a 'namespace' clause?  Maybe some vendors want to
> ignore namespaces.  IMO, it should not be optional to provide a version
> identifier.  This is a separate issue from requiring the version identifier
> to change under certain conditions.

Namespace information is needed for parsers to work properly in case
of identifier clashes. And I am sure the IETF will require that
revision clauses are present in YANG modules. But this is not a
technical requirement of the language itself; it is a usage guideline
requirement. I believe this distinction is worthwhile to make.

/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