Re: [NGO] external module properties
Wes Hardaker <wjhns1@hardakers.net> Tue, 29 April 2008 15: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 0E1DB28C332; Tue, 29 Apr 2008 08:06:54 -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 E91CC28C332 for <ngo@core3.amsl.com>; Tue, 29 Apr 2008 08:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.124
X-Spam-Level:
X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[AWL=0.864, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611]
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 lHPs9DsspYBT for <ngo@core3.amsl.com>; Tue, 29 Apr 2008 08:06:47 -0700 (PDT)
Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D818D28C32B for <ngo@ietf.org>; Tue, 29 Apr 2008 08:06:12 -0700 (PDT)
Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 87C61399A86; Tue, 29 Apr 2008 08:05:04 -0700 (PDT)
DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=q/GQnQsnmgxMLw+xzoHIkJYaSSs=; b=hTVeHqBrLWlzd3eSo/y/ERZgQKhFw4To1uk4XBnn/W0OgB8HYSmNXNhSA9vMnSsFKfVL7Lfe9Fy0T6qWzNfcT7Un5+vC1OmMMnZbBiVj+VM+pDH3Mqd9ZWpN0vnQY1zH+LGYJ31SsRiEWwbgQG/ceQ05LIdLVMpNyTpgEzr3e60=
Received: by wes.hardakers.net (Postfix, from userid 274) id 69250399B9B; Tue, 29 Apr 2008 08:05:04 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Andy Bierman <ietf@andybierman.com>
Organization: Sparta
References: <48137444.6070802@andybierman.com> <sdr6cq83d2.fsf@wes.hardakers.net> <4815EA5E.60607@andybierman.com>
Date: Tue, 29 Apr 2008 08:05:04 -0700
In-Reply-To: <4815EA5E.60607@andybierman.com> (Andy Bierman's message of "Mon, 28 Apr 2008 08:16:46 -0700")
Message-ID: <sdprs8vh0f.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE)
MIME-Version: 1.0
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
>>>>> On Mon, 28 Apr 2008 08:16:46 -0700, Andy Bierman <ietf@andybierman.com> said: AB> I believe 2 independent YANG implementations are deriving the version AB> from the most recent revision date. In my code, the current date AB> will be used (for the internal version) if no revision clauses are AB> provided. A numerical date meets my needs too... I'd be tempted not to even define the required formatting of the version number. Simply say it must be sortable using a standard comparison function (strcmp or >). DNS does this with the SOA serial number. The format is up to the network operator. Some use date/time based serial numbers. Some (especially those with > 256 pushes a day) use an incrementing number approach. In the end, all the software that needs to look at the serial number is never confused: it just does a comparison to decide if their local copy is newer or older than the currently published zone file. AB> The first order problem I want to solve is a standard mechanism AB> for distinguishing between multiple versions of the same module. Do you mean multiple vendors publishing a single yang module? How is that even possible (namespace definitions alone should take care of those conflicts think). >> 2) How about we do the inverse of normal SMIv2 modules and optimize for >> the reader... Most of this type of meta information, which I do >> agree is critical, isn't of huge interest to the average technical >> reader (which 99% of the time are trying to get to the technical >> cruft). How about we put it at the bottom (or anywhere after the >> real data definitions)? >> AB> I suppose a long list of revision statements gets in the way, AB> but not 1 or 2. I would like to reserve the 'bottom' for the granular AB> conformance specification that is missing from YANG. I don't really care how the bottom stuff is organized. We likely have multiple sets of information that need to go into a YANG module. Lets say that boils down to: technical stuff, an ever growing list of meta-data, conformance statements. I don't care about the order beyond the fact I want the technical stuff to go first. Because that's what 99% of the population cares the most about getting to. Anything else gets in their way. Now... don't read into this that I'm proposing a CLR sorting rule. I'm not. I actually think the file should be more flexible in it's required ordering. But IETF documents and the resulting YANGnits tool should suggest that non-technical sort of stuff needs to be lower in the document. Which makes it a CLS (suggestion). -- Wes Hardaker Sparta, Inc. _______________________________________________ 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