Re: [NGO] external module properties
Jon Saperia <saperia@jdscons.com> Sun, 27 April 2008 14:15 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 0060B3A6A60; Sun, 27 Apr 2008 07:15:12 -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 A3D683A6A60 for <ngo@core3.amsl.com>; Sun, 27 Apr 2008 07:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 8Lr5LdF1roZt for <ngo@core3.amsl.com>; Sun, 27 Apr 2008 07:15:10 -0700 (PDT)
Received: from rs40.luxsci.com (rs40.luxsci.com [65.61.166.82]) by core3.amsl.com (Postfix) with ESMTP id 5871C3A6985 for <ngo@ietf.org>; Sun, 27 Apr 2008 07:15:10 -0700 (PDT)
Received: from [192.168.20.195] (c-24-91-195-79.hsd1.ma.comcast.net [24.91.195.79]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id m3REFBkT019224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 27 Apr 2008 09:15:12 -0500
Message-Id: <5D258F3C-D164-4759-B743-45B33CEF2A6E@jdscons.com>
From: Jon Saperia <saperia@jdscons.com>
To: j.schoenwaelder@jacobs-university.de
In-Reply-To: <20080427061550.GB22643@elstar.local>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Sun, 27 Apr 2008 10:15:11 -0400
References: <48137444.6070802@andybierman.com> <20080426203103.GA22324@elstar.local> <4813A0EC.50209@andybierman.com> <20080427061550.GB22643@elstar.local>
X-Mailer: Apple Mail (2.919.2)
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
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
From an application perspective, I would like to see both Version and Namespace as a standard/required part of the modules. I think the need for version is pretty obvious, Name space is an important discriminator for management applications. /jon On Apr 27, 2008, at 2:15 AM, Juergen Schoenwaelder wrote: > 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 > _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo
- [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Jon Saperia
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Balazs Lengyel
- Re: [NGO] external module properties Balazs Lengyel
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Balazs Lengyel
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Martin Bjorklund