Re: [NGO] external module properties

David Harrington wrote:
> Hi,
> 
> So there are two questions to answer that might require different
> solutions.
> 1) are these two versions the same or different?

this is the minimum standard functionality

> 2) which is newer?

this is a harder problem.
YANG solves it by not allowing the vendor to have
any sort of version string within the language.
You get one release per day per module. Period.

This is good enough for standard documents, but
I suspect vendors will need additional flexibility,
in both the number of releases per day, and adding
extra content besides the date.  Unix SW versions
are often strings like '1.3.0' or '1.4.0alpha2', '1.2.1-precommit', etc.
There is no standard structured version string that works
for every situation.

IMO, a standard version MUST be the revision date,
and a vendor version SHOULD be the revision date,
and that's all that is standardized.

> 
> The first is simply a "do the verson identifier match?" 
> The second requires a standard progression mechanism, such as rev1.2
> vs. rev2.1 or a standardized format for the revision date. And if you
> are going to compare strings, then we need to pay attention to
> character sets, etc.
> 
> Which use cases are we trying to address?
> 
> dbh

Andy

> 
>> -----Original Message-----
>> From: ngo-bounces@ietf.org [mailto:ngo-bounces@ietf.org] On 
>> Behalf Of Wes Hardaker
>> Sent: Tuesday, April 29, 2008 11:05 AM
>> To: Andy Bierman
>> Cc: NETCONF Goes On
>> Subject: Re: [NGO] external module properties
>>
>>>>>>> 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 mailing list
NGO@ietf.org
https://www.ietf.org/mailman/listinfo/ngo