Subject: [NGO] external module properties

From: Andy Bierman <[email-masked]>
Date: Sat, 26 Apr 2008 11:28:20 -0700

Hi,

There is so much focus on the contents of a NETCONF data module,
that little attention has been paid to the 'external' properties.
I have already brought up module/submodule name uniqueness.

YANG does not have a concept of a module version, which is a mistake.
SMIv2 has LAST-UPDATED.  IMO, all YANG modules should have at
least 3 standard external properties:

   - name (matches import or include directive)
   - version (derived from most recent 'revision')
   - authoritative online module repository location

This implies that at least one revision-stmt MUST be present.
IMO, especially thinking for the long-term, it is not acceptable
to use ad-hoc non-standard mechanisms to identify the actual
module version.  LAST-UPDATED and REVISION are optional in SMIv2.
This is a mistake that should be fixed in YANG.

Another controversial external module property is 'schemaLocation' ;-)

Andy

_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 26 Apr 2008 22:31:03 +0200

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.

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.

/js

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.

-- 
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Andy Bierman <[email-masked]>
Date: Sat, 26 Apr 2008 14:38:52 -0700

> only has revision statements.

some modules like SNMPv2-TC have no MODULE-IDENTITY section

> function and leave other things to guidelines or applicability

I think the NETMOD philosophy should consider the entire
network configuration problem, which includes properties like
module version.

>     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.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 27 Apr 2008 08:15:50 +0200

> 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.
 
> network configuration problem, which includes properties like

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

> 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

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Apr 2008 03:19:53 -0700

> requirement. I believe this distinction is worthwhile to make.

no -- the prefix is needed for the language parser.
The namespace URI string isn't used anywhere in YANG.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 27 Apr 2008 13:19:19 +0200 (CEST)

> The namespace URI string isn't used anywhere in YANG.

It is needed in the NETCONF data that YANG defines.  Thus it is an
essential property in a YANG module.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Apr 2008 06:21:33 -0700

> essential property in a YANG module.

not really.  I don't think RFC 4741 says so.
YANG does not need to make it mandatory.
YANG is arbitrarily enforcing a CLR outside
the language for the module namespace, but not for module version.

Andy

---

From: Jon Saperia <[email-masked]>
Date: Sun, 27 Apr 2008 10:15:11 -0400

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

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Apr 2008 08:49:53 -0700

Jon Saperia wrote:
> 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.

Agreed.

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.

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.

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.

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.

Andy

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 27 Apr 2008 18:53:07 +0200 (CEST)

> not really.  I don't think RFC 4741 says so.

It is needed to avoid name clashes in the XML, e.g. if two modules have
the same top-level element name.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Apr 2008 10:06:20 -0700

> the same top-level element name.

I know that, but it is mandatory in NETCONF, not YANG.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Apr 2008 08:37:57 +0200

>    - authoritative online module repository location

These two items can be specified in an external directory, and instead
of a traditional version number, I'd prefer to use e.g., MD5 sum of the
YANG module.
 
> Another controversial external module property is 'schemaLocation' ;-)

If the controversy is about whether to include schemaLocation in NETCONF
data, then I am strongly against doing so.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Apr 2008 10:06:25 +0200

> entire management system, which includes problems such as human factors

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

> 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.

> 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).

> 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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Apr 2008 07:02:03 -0700

> A data modeling language specification is the wrong place to address

Really?  I thought YANG existed to provide the human-friendly data modeling
interface that XSD and DSDL cannot provide.  It seems to me human factors
are critical to CM.  Configuration errors are a big problem in real
networks.  Providing an API and operational environment which is
resistant to human-introduced errors is a very high priority to me.

> specific language for NETCONF data models and not comparable to

I think there are plenty of similarities and lessons to be learned
from SMING and EOS.  I believe you wrote an RFC on the subject. ;-)
The YANG and 'Why YANG?' drafts cite the SMIng language
as the starting point for YANG.

> guidelines in this space).

I disagree.
This is a known problem in XML and CM, which needs to be addressed.
Should we standardize on the namespace URI as the version ID?
I hope not.  IMO, we need a standard version field that can be
retrieved with the the schema-discovery DM, and is deterministically
derived from the YANG module (or explicitly entered, like LAST-UPDATED).

IMO, it is a bad idea to mix modules with and without versions.
The namespace-stmt is mandatory because YANG is forcing good XML usage.
Forcing the use of a version ID for good XML usage is no different.

> you mean the "Comic_Book_Resources". ;-)

Not Constant Bit Rate either.

Crappy Big Rule.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 28 Apr 2008 07:23:53 -0700

>>>>> On Sat, 26 Apr 2008 11:28:20 -0700, Andy Bierman <[email-masked]> said:

AB> YANG does not have a concept of a module version, which is a mistake.

I agree in general that information like this is needed.  Two thoughts
though:

1) Let's use an easily sortable version number (could be date based).
   From a machine-readability point of view it's much easier to sort
   through a bunch of revision files if the files are versioned in a way
   that allows simple compare operators.  (as an example, this is the
   reason that perl modules uploaded to the central CPAN repository are
   supposed to use floating point numbers only (IE, 1.2 is legal but
   1.2.3 isn't)).

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)?

-- 
Wes Hardaker
Sparta, Inc.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Apr 2008 08:16:46 -0700

>    supposed to use floating point numbers only (IE, 1.2 is legal but

I believe 2 independent YANG implementations are deriving the version
from the most recent revision date.  In my code, the current date
will be used (for the internal version) if no revision clauses are
provided.

Obviously, the '1-release-per-day' limitation might be a problem
for some vendors, so full dateTime will be needed (yuch!)

The more we try to do with this string, the harder it will
be to standardize as 'mandatory'.

The first order problem I want to solve is a standard mechanism
for distinguishing between multiple versions of the same module.
The solution should not add any significant burden to implementors,
especially those which choose to use the 'default' version ID,
derived from the module or current date, etc.

>    cruft).  How about we put it at the bottom (or anywhere after the

I suppose a long list of revision statements gets in the way,
but not 1 or 2.  I would like to reserve the 'bottom' for the granular
conformance specification that is missing from YANG.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Apr 2008 09:01:19 -0700

> data, then I am strongly against doing so.

No it is not about schemaLocation in XSD.
It is the IANA registry vs. repository issue.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 28 Apr 2008 18:06:18 +0200

Hello,
mandatory versioning was the most frequent request I got from potential users of YANG, so I 
agree with Andy it is needed.
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 28 Apr 2008 18:07:47 +0200

> of a traditional version number, I'd prefer to use e.g., MD5 sum of the
I think we should keep the version human readable and possible to memorize.
Balazs
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: "David Harrington" <[email-masked]>
Date: Mon, 28 Apr 2008 13:27:59 -0400

Hi,

It is important for an NMS to be able to tell which version of a data
model is supported by a managed element, so when it makes changes to a
configuration, it can make changes appropriate to the version
supported.

On a side note, keep in mind that some managed elements may have
multiple components, such as blades in a chassis, and the versions
supported might differ, so a Netconf server might also need to know
which version to use to perform validation.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Andy Bierman
> Sent: Monday, April 28, 2008 10:02 AM
> To: Andy Bierman; Jon Saperia; NETCONF Goes On
> Subject: Re: [NGO] external module properties
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Apr 2008 19:39:20 +0200

> resistant to human-introduced errors is a very high priority to me.

You are mixing things and I stop responding to that.
 
> from SMING and EOS.  I believe you wrote an RFC on the subject. ;-)

Go and read the document again and you will see a big argument against
protocol independent data modeling languages. (A revised version of
the ID will soon appear in IEEE Communications Magazine for those you
have access to it.) Now read my quote again and there will be
consistency.

> The YANG and 'Why YANG?' drafts cite the SMIng language as the
> starting point for YANG.

There is no contradiction with this in case you wanted to sound like
pointing out a contradiction. But even then, this has nothing to do
with the subject at hand in the first place.

> Forcing the use of a version ID for good XML usage is no different.

I think someone already pointed out that the namespace is needed for
making NETCONF do the right thing.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Apr 2008 19:48:41 +0200

> which version to use to perform validation.

I seems you are talking about version information you won't get from
the YANG module itself; at least as long as we do not do versioned
imports. I hear you saying you want a definition of what the various
thingies in a managed element actually support; which is was we called
agent capabilities in the SMIv2. In fact, if you look how SMIv2
compliance and agent capabilities work, you will see that they do not
even refer to a specific version of a MIB module.

Perhaps people have a different versioning model in mind than what
SMIv2 used to have. Then I think this needs to be discussed first.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 28 Apr 2008 11:31:54 -0600

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Andy Bierman'" <[email-masked]>; "'NETCONF Goes On'" <[email-masked]>
> Sent: Monday, April 28, 2008 11:27 AM
...
> which version to use to perform validation.
...

This is a really important point to consider, and also a good reason why
something like "agent-capabilities" from SMI is probably not the answer.

There's a slightly different way of looking at the problem that might be
helpful.  One can introduce an abstraction I'll call a "compatibility class".
Two things are members of a compatibility class if they both have all the
characteristics of the compatibility class.  This lets of treat each version
of a class as distinct, and the compatibility class abstraction describes
the extent to which instances of the different versions of a class may
be managed in the same way.

Due to the asymetry of manager and agent requirements for tolerating
instance data from the "wrong" version, we might extend the notion
just a bit further.  Deliberately picking bad words, I'll call them the
"loose" and the "fussy" version compatibility classes.  The "loose" is
merely the union of the characteristics of all the versions, and the "fussy"
is the intersection.  Over time, as more features are added or deprecated
or obsoleted, exactly what each of these abstractions would entail will
change.  The ways in which they will change will be determined by what,
if any, rules exist controlling what can be changed from one version to
another of "the same" module.

The point of all this to encourage a little thought about what it *really* means
for instance data to correspond to various versions of "the same" specification.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Apr 2008 21:18:16 +0200 (CEST)

Hi,

While I agree with Juergen about the general idea that YANG should not
try to enforce arbitrary rules on the user, in the case of 'revision'
I think it falls into the same category as 'namespace' and 'prefix'.
Neither is strictly speaking not required in all cases - a namespace
is not needed if the module is a type library such as yang-types; a
prefix is not needed if there are no local references in the module.

And I also agree that the revision might be needed for proper schema
discovery.

I think I'd rather see all three mandatory than all three optional.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Apr 2008 22:39:41 +0200

> agree with Andy it is needed.

I am not sure if I understand correctly - does it mean different
versions under the same data model URI?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Mon, 28 Apr 2008 16:44:32 -0400

"Randy Presuhn" writes:
>Over time, as more features are added or deprecated

Given that we'll have multiple revisions of multiple modules running
on multiple blades within the same chassis, there's really no one
right answer to "what revision(s) are you running?".

The good news is that we've arrived at the "there's no right answer"
answer quickly, so maybe we can put some lines around what sorts
of problems we thing we can solve and what we need to delay for
later work.  Can we address the simple cases with normal netconf
capability exchange, the more complex cases with module discovery,
and the worse cases with module versioning rules?

In other areas of discussion, the revision strings currently in
YANG are yyyy-mm-dd (2007-06-09), giving much more information
that decimal numbers.

I think I'd be happy to see these revision numbers in the
capability URIs that are advertised, and we could either allow
the inclusion of multiple revisions strings in the capability
or say that if no revision strings are present, the revision
information isn't simple (multiple or non-static), and the
application should resort to the module discovery mechanism.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Apr 2008 17:10:04 -0700

> I think I'd rather see all three mandatory than all three optional.

agreed.

The easy part (if there is one) is having a standard version ID.

The hard part is determining what changes are allowed without
updating the version, and what changes are never allowed, even
if the version is updated.

This is where MUST for standards and SHOULD for vendors is needed.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 29 Apr 2008 11:08:40 +0200

I think we have to define two ways of changing the module:
1) Where only the version changes, the module name and its URI stays the same, I would call 
this a compatible change (whatever that means :-)
Ericsson's definition for such a "compatible change" is that if a newer node is handled ONLY(!) 
by an older management system it will still work.
2) Where the module name and URI changes as well, any change is allowed. This really means 
writing a new module.

Balazs

>> I think I'd rather see all three mandatory than all three optional.
AGREED !!!

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Apr 2008 08:05:04 -0700

>>>>> On Mon, 28 Apr 2008 08:16:46 -0700, Andy Bierman <[email-masked]> 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).

>> cruft).  How about we put it at the bottom (or anywhere after the

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Apr 2008 08:28:27 -0700

> that even possible (namespace definitions alone should take care of

No, I just mean mandatory revision clauses in YANG.
There must be some data within the module itself that
can be used to distinguish 2 different versions of
the same module.

We already have a single naming scope for module names.
There is no concept at all in YANG of the Acme FOO-MIB
and some other FOO-MIB.  There is just one FOO-MIB,
and any import (or include) which identifies FOO-MIB
in the target is referring to the one and only possible
module (within that implementation) called FOO-MIB.

The YANG spec is silent on finding the module associated
with an import or include.  That doesn't mean a robust,
interoperable, standards-based CM system can be silent on the issue.

Andy

---

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 11:30:32 -0400

Hi,

So there are two questions to answer that might require different
solutions.
1) are these two versions the same or different?
2) which is newer?

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

> Behalf Of Wes Hardaker
> Sent: Tuesday, April 29, 2008 11:05 AM
> To: Andy Bierman
> Cc: NETCONF Goes On

---

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 11:35:26 -0400

> module (within that implementation) called FOO-MIB.

This works within an implementation. How does it work in an NMS that
deals with FOO-MIB instances in different implementations? If both
Ciso and Nortel publish a FOO-MIB, how does an NMS managing both
vendors' devices differentiate which FOO-MIB specification to use for
each managed node, especially if the BAR-MIB imports "FOO-MIB"?

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 11:40:19 -0400

>interoperable, standards-based CM system can be silent on the issue.

This was intentional, in the same manner that the ANSI C spec doesn't
tell you about /usr/include, /usr/local/include, or the -I flag.
The language spec should be defining the language and the model of
operation.  Your tool set will dictate where and how it searches
for files.

Heck, my tool set may not even use files.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Apr 2008 08:42:48 -0700

> 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.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Apr 2008 08:46:55 -0700

> each managed node, especially if the BAR-MIB imports "FOO-MIB"?

We already have this problem now with SMIv2 module names.
The standard uses 'stock fuzzy text' to warn vendors
to pick module names that will not clash.  This is how the IETF
punts the problem, because the real solution involves a registry,
and we apparently already have enough of those.  Vendors would
not want to register their module names with IANA anyway.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 11:43:42 -0400

>number.  Simply say it must be sortable using a standard comparison

Funny, but that's exactly what we did in YANG ;^)

    *** The revision Statement @revision@
    
    The "revision" statement specifies the editorial revision history of
    the module, including the initial revision.  A series of revisions
    statements detail the changes in the module's definition.  The
    argument is a date string in the format "YYYY-MM-DD", followed by a
    block of substatements that holds detailed revision information.  A
    module SHOULD have at least one initial "revision" statement.  For
    every editorial change, a new one SHOULD be added in front of the
    revisions sequence, so that all revisions are in reverse chronological
    order.

The revision statement looks like:

      revision 2007-06-09 {
          description "Initial revision.";
      }

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Apr 2008 08:52:47 -0700

> Heck, my tool set may not even use files.

Fine.
But if module FOO in any NETCONF system imports module X,
and module BAR imports module X, can we say in the YANG spec
that they MUST refer to the same exact module X?

Likewise, if FOO includes FOO-A and FOO-B, and both FOO-A
and FOO-B include FOO-TYPES, are they including the exact same
module (i.e., exact same sequence of YANG language tokens)?

This is a different issue than which particular X or FOO-TYPES is used.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 12:11:29 -0400

>not want to register their module names with IANA anyway.

The other option is the one java took: use reversed domain name
hierarchies to ensure that there are no conflicts.  No one but sun
can make a com.sun.java.swing module, given you instant self-organizing
uniqueness.  If you own the domain, you own the namespace under
that domain.  Pro: simple; con: verbose.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 12:12:44 -0400

>that they MUST refer to the same exact module X?

You can only say that if you can say that there is only
exactly one module X.  If everyone makes their own "vlan"
module, you're out of luck.

Thanks,
 Phil

---

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 12:55:25 -0400

This is also how enterpise MIB modules work; only cisco is allowed to
assign OID under the cisco tree.

The only registry IANA needs to define for enterprise MIBs is the one
that assigns subtrees based on enterpiseID, i.e. IANA delegates the
assignment authority for the subtree of private to the owner of the
enterpriseID.

dbh 

> From: Phil Shafer [mailto:[email-masked]] 
> Sent: Tuesday, April 29, 2008 12:11 PM
> To: Andy Bierman
> Cc: David Harrington; 'NETCONF Goes On'

---

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 12:56:23 -0400

I think that's a problem.

dbh 

> Behalf Of Phil Shafer
> Sent: Tuesday, April 29, 2008 12:13 PM
> To: Andy Bierman
> Cc: NETCONF Goes On

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Apr 2008 19:10:23 +0200 (CEST)

Phil Shafer <[email-masked]> wrote:
> can make a com.sun.java.swing module, given you instant
> self-organizing uniqueness.  If you own the domain, you own the
> namespace under that domain.  Pro: simple; con: verbose.

If we want something verbose, we already have the namespace uri, which
also is supposed to be globally unique.  It could be used to identify
the module.

I have limited experience of using SNMP MIBs in larger NMS systems;
but is the current module name scheme of SMI a problem?  If it is, we
should do something better.  If it isn't, we shouldn't try to solve
it.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Apr 2008 10:44:39 -0700

>> module, you're out of luck.

I am proposing that within a given running NETCONF agent,
that the [sub]module names are unique.  You cannot have
multiple "vlan" modules within the same agent.  That
implies that all import/include searches will use the
same algorithm, but the spec can be silent about that.

(Multiple versions of the vlan module within a single agent
is a different problem.)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Apr 2008 19:50:06 +0200

> assignment authority for the subtree of private to the owner of the

I though we were talking about module names...

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Apr 2008 19:56:21 +0200

> I think that's a problem.

Why do we not work on the YANG specification? It says:

   Standard module names will be assigned by IANA.  The names of all
   standard modules MUST be unique (but different revisions of the same
   module should have the same name).

   Private module names will be assigned by the organization owning the
   module without a central registry.  It is recommended to choose names
   for their modules that will have a low probability of colliding with
   standard or other enterprise modules, e.g. by using the enterprise or
   organization name as a prefix.

This is more or less what we do with the SMI. It is not perfect
(reverse DNS names a la Java surely are better but also much more
verbose), but it also seems SMI module name clashes have not been a
serious problem in practice. (Correct me if I am wrong.)

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Apr 2008 11:00:51 -0700

> should do something better.  If it isn't, we shouldn't try to solve

We should do what we can within the XML sandbox.
I agree with your comment about using the namespace URI instead
of a long string for the module name.  There are enough static
mappings to deal with already.  However, these URIs will
not be very easy to memorize, unlike module names.

I prefer to use derived fields from the YANG module (ala revision
date for version ID) instead of adding potentially redundant fields,
in case you were thinking of a 'short' module name an a 'long' module name. ;-)

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 14:05:12 -0400

>also is supposed to be globally unique.  It could be used to identify

With the issue that it's even uglier that the already-ugly-enough
java scheme, and it gives an even less simple module->filename
mapping.

We could say that the module name is just a user-friendly term
that means nothing to the language, and then import by URIs,
but this doesn't answer includes.  And I think we'd have to
give some helpful words about the URI->filename mapping, such
as "you could give a file that contains this mapping".

>should do something better.  If it isn't, we shouldn't try to solve

In truth, it's rare and mostly seems to occur between multiple early
versions of the same technology.  The most common conflicts I could
find (in a quick search) was "vlan-mib", "switch-mib", and, um, er,
one other that I've forgotten.  Rats.

I'm happy (more than happy) to declare this a non-problem, but we
declared it a non-problem a couple months ago and here it is again.

Can we get a non-problem pre-first-meeting concensus and move on?

My take is either it's not a problem, or it needs a once-and-for-all
fix.  I'm not a fan of the java naming scheme (or java at all), but
the difference between "module ietf-vlan" and "module org.ietf.vlan"
is zero.  Hack, we could do non-reverse names: "module vlan.ietf.org".

Either way, it's not a big deal.  Let's pick an answer and get it
off the table.

Thanks,
 Phil

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Apr 2008 11:26:53 -0700

>>>>> On Tue, 29 Apr 2008 08:28:27 -0700, Andy Bierman <[email-masked]> said:

AB> No, I just mean mandatory revision clauses in YANG.

My bad...  I misread one of your statements with the word "vendor"
instead of "version.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Apr 2008 11:42:10 -0700

>>>>> On Tue, 29 Apr 2008 08:52:47 -0700, Andy Bierman <[email-masked]> said:

AB> But if module FOO in any NETCONF system imports module X,
AB> and module BAR imports module X, can we say in the YANG spec
AB> that they MUST refer to the same exact module X?

The problem you're trying to dance around is that you don't want to use
import statements that are verbose.

If the SMI used import statements that imported OID instead, there
wouldn't be any naming collusion issues.  But no one wants to write

  IMPORT ifIndex from 1.3.6.1.2.1.2.2.1.1

Nor do we want to write

  <magic-import from="urn:ietf:params:xml:ns:netconf:base:1.0" it="ErrorTag" />

Tools don't actually have a problem actually handling the above.  They
make indexes for lookups or read every file in a search path.  Most
tools already do this for MIB module names since you can't expect the
file name to match the BEGIN statement.

You only have three choices:

1) use fully qualified unique names from the module ID (like
   "namespace") and suffer from the lower readability

2) standardize on some prefix ownership scheme when naming files.  Your
   "module netconf", eg, shouldn't be named that way.  It should be
   "module IETF-netconf" or with some other unique prefix that identifies
   the controlling organization.

   (qualifiers count in this choice too, like

     <magic-import organization="IETF" from "netonf" it="ErrorTag" />

   )

3) be happy when conflicts occur and shrug them off as "not that big of
   a problem".

I'd like to avoid (3).  (2) may or may not require IANA help but I think
is the most reader-and-writer-friendly.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Apr 2008 11:45:53 -0700

>>>>> On Tue, 29 Apr 2008 08:42:48 -0700, Andy Bierman <[email-masked]> said:

AB> YANG solves it by not allowing the vendor to have
AB> any sort of version string within the language.
AB> You get one release per day per module. Period.

That smells of a CLR.  An arbitrary timing requirement immediately
limits what you can do with it.

From a security point of view I don't like it either.  Security issues
can be created in data models and releasing a new copy with a fix *now*
is an important feature.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Apr 2008 11:50:05 -0700

>>>>> On Tue, 29 Apr 2008 11:43:42 -0400, Phil Shafer <[email-masked]> said:

>> number.  Simply say it must be sortable using a standard comparison

PS> Funny, but that's exactly what we did in YANG ;^)

Good start, but I'm going to take issues with only using a date.  And
YANG doesn't do what I said.  It specifies the revision number format as
a date.

PS> The revision statement looks like:

PS> revision 2007-06-09 {
PS>    description "Initial revision.";
PS> }

I wanted to be able to pick what was right for me, as an author, from
any of these (for only I know what is good from my authoring
perspective):

  revision 20070609 {
  
  revision 200706090001 {

  revision 42 {

As long as future > past, the tools should be happy.

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 14:54:17 -0400

>can be created in data models and releasing a new copy with a fix *now*

But from a real-world point of view, a company making multiple
security fixes in one day won't last long enough to worry about.
The marketplace will solve the problem on its own.

Thanks,
 Phil

---

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 15:02:16 -0400

Hi,

My concern also includes multiple instances of a vlan module running
within a single (master/subagent) environment. This might be found in
a router chassis that supports new and legacy blades, or an x86 PC
server that can support disk drives from different vendors. 

Each of these components might support different revisions of the same
module, depending on the vendor model and release. In SNMP, this
wasn't critical beacause we were mostly monitoring. Th eoperators
complained about this for the CLI interface in the IAB workshop. 

If we are going to configure these using model-and-release-dependent
modules, we probably need to know which version of the "knob
definitions" are supported by the different components. If there are
includes in the module, then we better know which sub-module is being
referenced, just as installs on Linux usually require a clear
indication of the dependencies on specific versions of other packages.

dbh

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Tuesday, April 29, 2008 1:45 PM
> To: David Harrington
> Cc: 'Phil Shafer'; 'NETCONF Goes On'

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 29 Apr 2008 21:04:40 +0200

> not be very easy to memorize, unlike module names.

Given the way how NETCONF works, the capability URIs are supposed to be
the identifiers that are communicated between the parties. Then each
party can have its own catalog that maps this URI to a local file name
(that even needn't be globally unique) or an URL in general. This way,
the file name of the module is a non-issue and search path can be
handled as well.

I would also prefer to encode version numbers (if there are any) to the
URI rather than invent yet another meta-parameter of YANG models.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 15:06:47 -0400

> 
> Why do we not work on the YANG specification? 

That would be fine. Should we be discussing this on the YANG list
then?

dbh

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 15:05:39 -0400

>YANG doesn't do what I said.  It specifies the revision number format as

Then I'm lost.  You wanted:
(a) required formatting
(b) sortability
Which requirement doesn't YANG satisfy?

>any of these (for only I know what is good from my authoring

It's a standard.  You give up "right for me" for a common structured
standard.

>As long as future > past, the tools should be happy.

This breaks (a) above.

There's a lot to be gained by using dates and not a lot of down
side.  Being able to look at the revision history and see when what
happened, how stable a module is, and how likely folks are to be
up-to-date with the latest version is important.  And it avoids
tons of discussion about whether we need two or three decimal numbers
and when the major or minor version should change.  It's simple,
obvious, sortable, well-defined, and will last for thousands of
years.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Apr 2008 12:16:29 -0700

> the file name of the module is a non-issue and search path can be

Excellent point.
I am envisioning a system which includes a mandatory standard
'schema-discovery' mechanism.  The <hello> exchange is a bad
place for all this versioned module to namespace mapping info
(even though that's exactly what I have implemented now ;-)

> URI rather than invent yet another meta-parameter of YANG models.

We wrapped around the axle once before on this topic.
IMO:

The namespace URI should be stable.  It is assigned in
the first version of the module.  It can never change.
If the module is obsolete, the namespace is still 'used up',
and can never be reused in another module.

In XSD, the <schema> 'version' attribute should be used in addition
to the targetNamespace, to determine the exact schema content.
In YANG, each new version of a module (std:MUST/vendor:SHOULD)
include a new revision-stmt, which has a date string which becomes
the new version identifier.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Apr 2008 12:20:56 -0700

> That would be fine. Should we be discussing this on the YANG list

I used the NGO list because I thought I was raising issues
which are not YANG-specific.  We have discussed how YANG would
address these issues, but have not discussed any concrete
changes to the YANG draft.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 15:22:32 -0400

>That would be fine. Should we be discussing this on the YANG list

That's the First Rule of YANG:  YANG expands to consume all mailing
lists ;^)

Thanks,
 Phil

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Apr 2008 12:36:15 -0700

>>>>> On Tue, 29 Apr 2008 14:54:17 -0400, Phil Shafer <[email-masked]> said:

PS> But from a real-world point of view, a company making multiple
PS> security fixes in one day won't last long enough to worry about.

Or the one time that a big company does and realizes it's mistake and
immediately tries to do the right thing will get equally as hurt.

PS> The marketplace will solve the problem on its own.

So you should take no objection to doing a more granular release number format.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Apr 2008 12:37:16 -0700

>>>>> On Tue, 29 Apr 2008 15:22:32 -0400, Phil Shafer <[email-masked]> said:

>> That would be fine. Should we be discussing this on the YANG list

PS> That's the First Rule of YANG:  YANG expands to consume all mailing
PS> lists ;^)

The SMI long beats YANG on this.  Note how often the SMI is talked about
hear, as opposed to YANG on the SMI lists ;-)
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Apr 2008 21:48:10 +0200 (CEST)

Hi,

> obvious, sortable, well-defined, and will last for thousands of

I fully agree with this.

How about adding an optional counter after the date?  So you can do

  2008-04-29
  2008-04-29:1
  2008-04-29:2

and so on.

It removes the arbitrary timing constraint that worries Wes, and it's
still simple enough for the common use case.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Apr 2008 22:00:31 +0200 (CEST)

Hi,

> server that can support disk drives from different vendors. 

I agree that this is a difficult problem, and I'd be happy to discuss
this more.  Is this something we want to work on?  But I think it is
orthogonal to the issue about how a module is identified.  BTW, this
problem touches other ongoing work, like schema discovery.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 29 Apr 2008 22:02:48 +0200

> (even though that's exactly what I have implemented now ;-)

Why is it so bad? The big advantage I see is that it works with the
existing NETCONF framework.

> the new version identifier.

RELAX NG has no such attribute and nobody seems to be complaining.
Version numbers are indeed encoded in namespace URIs. In my view, the
revision statement could be interpreted as an auxiliary version marker
intended for human readers - the only authoritative identifier of a YANG
module content would be the URI.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 29 Apr 2008 13:05:02 -0600

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, April 29, 2008 1:48 PM
...
...

Even simpler - just use RFC 3339 date-time with the option of abbreviating it to full-date.
That should be enough for even the busiest believers in rapid prototyping.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 29 Apr 2008 13:08:26 -0600

Hi -

> From: "Ladislav Lhotka" <[email-masked]>
> To: "NETCONF goes on" <[email-masked]>
> Sent: Tuesday, April 29, 2008 2:02 PM
...

Anything that is limited to the <hello> exchange won't work well with
hot-swappable components.  Plugging a line card into a running chassis should
not require tearing down and re-establishing any connections to management
systems.  Or is netconf not intended for these systems?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Apr 2008 13:09:14 -0700

> How about adding an optional counter after the date?  So you can do

I sort of prefer separate 'revision-date' and 'release-number' fields,
but you are trying to keep the compare limited to a single string,
which is better.

I also prefer to limit the characters in this string to 'URL-safe'
and 'filespec-safe' chars, e.g., 2008-04-29.1 and 2008-04-29.2

Andy

---

From: "David Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 16:12:28 -0400

Schema discovery cannot discover what isn't said ;-)
Someplace in the schema, we need a good version identifier.
I think we might need the capability of specifying version in the
include statement (if the version dependency is important, but it
should be able to be left out when it is not important)

A dependency tree could be complex, and might be able to be avoided by
tightening the rules about how a module can be updated. OR we can try
to utilize some existing standards about handling dependencies.

dbh

> From: Martin Bjorklund [mailto:[email-masked]] 
> Sent: Tuesday, April 29, 2008 4:01 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Apr 2008 22:49:25 +0200

> complained about this for the CLI interface in the IAB workshop. 

I think it is not desirable to assume a 1:1 mapping of each and every
"(sub)agent capability" to a YANG module. I can't imagine this to work
in a standards setting; you would have to isolate each and every
little feature into a separate YANG module.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Apr 2008 23:00:08 +0200

On Tue, Apr 29, 2008 at 01:05:02PM -0600, Randy Presuhn wrote:
 
> Even simpler - just use RFC 3339 date-time with the option of
> abbreviating it to full-date.  That should be enough for even the
> busiest believers in rapid prototyping.

Sounds like a reasonably way forward to me.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 18:33:05 -0400

>little feature into a separate YANG module.

At this point, that's all the granularity we have.  We have talked
about adding a capabiltity definition and testing mechanism to YANG,
but it never took off.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 18:43:24 -0400

>should be able to be left out when it is not important)

I keep coming back to this also, for the "import" statement.
Consider this scenario/timeline:

- module A defines a cool feature
- modules B and C import A to use that feature
- module A gets rev'd to add a new leaf to a grouping
- module B wants the new leaf
- module C doesn't want it

Without revision-specific imports, this scenario is unworkable.

With revisions, module B would get rev'd to import the new revision
of A.  Module C would continue to import the previous revision.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 18:45:42 -0400

>systems.  Or is netconf not intended for these systems?

Putting it in the hello making a short-cut against having to
do schema discovery on each connections.  If the schema information
changes, the device should send a notification to tell the client
that it might want to perform schema discovery again.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Apr 2008 00:51:02 +0200

> about adding a capabiltity definition and testing mechanism to YANG,

I suggest to get data models done first, then worry about the next
things on the road. Describing granular implementation feature sets is
for me a very different problem - and without common data models
written in a common data modeling language, it is not worth to spent
time to solve this problem.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 18:52:09 -0400

>How about adding an optional counter after the date?  So you can do

This is fine with me (with dash or dot rather than colon).  I don't
think we need full-date and the various issues it will bring with
it (esp. time zones).

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Apr 2008 00:54:32 +0200

> of A.  Module C would continue to import the previous revision.

Or a user of a grouping has to be explicit what he is using; with
this, even within module A, you can use different subsets of a
grouping defined in A.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 19:06:23 -0400

>this, even within module A, you can use different subsets of a

This would be a choice between being difficult to maintain and
verbose at a bunch of spots in the module, or being explicit in one
spot.  That's an easy one for me.  Also it keeps the idea of the
module at an atomic conhesive whole.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 19:02:37 -0400

"David Harrington" writes:
>module, depending on the vendor model and release.

I agree this is a thorny problem and one that will likely become
more commonplace.  I don't have a good answer, so here's a bad one ;^)

If you have instance-specific modules, you'd use "augments" to add
the new bits.  Something like:

     augments /interfaces/interface/unit {
         when "../type == 'sonet'";
         leaf new-stuff { ... }
     }

To support multiple revisions, you'd need something like
this in your hierarchy, like:

    augments whatever {
         when "../version > '2008-04-01'";
         ...
    }

Then netconf core component could handle the insertion (on output)
and checking (in input) of this version element.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Apr 2008 19:04:01 -0400

Juergen Schoenwaelder writes:
>things on the road.

Fine by me.  We should make a list of topics that the WG is explicitly
putting off for future work, so we don't continually rehash them.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Apr 2008 08:23:52 +0200 (CEST)

> of A.  Module C would continue to import the previous revision.

But with revisions, you have to explicitly rev all importers of a
module when the module is updated.

Suppose module A rev 1 gets published in an rfc, and module B which
imports A rev 1 in another.  Now, A is updated to rev 2.  If a vendor
wants to implement A rev 2 and B, that doesn't work, unless B is also
updated to rev 2 as soon as A is updated.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Apr 2008 08:28:28 +0200 (CEST)

> busiest believers in rapid prototyping.

That was my first thought as well, with the additional CLR to only use
UTC, in order for simple string comparison to work.  But I thought a
single integer would be simpler and do the job just fine.

If we do a single integer, we should use a dot instead of colon, as
Andy suggested.

/martin

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Apr 2008 06:42:23 -0700

>>>>> On Tue, 29 Apr 2008 15:05:39 -0400, Phil Shafer <[email-masked]> said:

PS> Then I'm lost.  You wanted:
PS> (a) required formatting
PS> (b) sortability
PS> Which requirement doesn't YANG satisfy?

I actually said that I didn't (ideally) want (a).  The requirement on
formatting I suggested was a simple sortable number (either integer or
floating point) who's value could be left to the module writer as long
as it was either an integer or float.

I'm fine with a date and time too, though.  This is not an argument that
I think is crucial, mind you, but I don't see the point in restricting
modules to only be released once per day.  That's imposing an arbitrary
rule that isn't needed.  And letting the version spec be either a
integer or float without additional imposed semantics means you can use
a date-based number or you don't have to.  Flexibility all around.

>> As long as future > past, the tools should be happy.

PS> This breaks (a) above.

Which I never said I wanted.  You extrapolated that from my desire for an
sortable format.  It's easy to see how you could have thought that and
I'm sorry if I didn't explain it well enough.

PS> There's a lot to be gained by using dates

What?

PS> Being able to look at the revision history and see when what
PS> happened, how stable a module is, and how likely folks are to be
PS> up-to-date with the latest version is important.

So you want to compare the frequency of releases based on the date to
decide whether to use it or not?

PS> And it avoids tons of discussion about whether we need two or three
PS> decimal numbers and when the major or minor version should change.
PS> It's simple, obvious, sortable, well-defined, and will last for
PS> thousands of years.

How about 2008-01-01-0000?  Or better (IMHO) 200801010000 which is
instantly machine parse-able without special code?  Or how about an XML
defined date/time string that leaves the time stamp as optional?
Wouldn't that provide the most reuse and flexibility?

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Apr 2008 06:43:37 -0700

>>>>> On Tue, 29 Apr 2008 13:05:02 -0600, "Randy Presuhn" <[email-masked]> said:

RP> Even simpler - just use RFC 3339 date-time with the option of
RP> abbreviating it to full-date.  That should be enough for even the
RP> busiest believers in rapid prototyping.

Cool, I just said that too :-)  (though you nicely referenced a spec for
it).
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Phil Shafer <[email-masked]>
Date: Wed, 30 Apr 2008 11:28:15 -0400

Wes Hardaker writes:
>I actually said that I didn't (ideally) want (a). 

Doh!!  My bad.  Sorry, I misread your comment.

>decide whether to use it or not?

Yup.  In deciding when or whether to implement a module, I'd consider
factors like stability, churn and age, which would be easily visible
in dated revisions.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 30 Apr 2008 08:57:00 -0600

Hi -

> Sent: Wednesday, April 30, 2008 12:23 AM
...
> module when the module is updated.

No.  Importers of a module which has been updated only need to be
revised if one wants to take advantage of the changes that were made.

> updated to rev 2 as soon as A is updated.

In my opinion, this is a feature, rather than a bug.
(But there's no "as soon as" requirement.  There's no need to update
B until someone wants a version that includes the behavioural changes
that would result from using the newer version of A.)

I think there's some wisdom in the language that accompanies the
references sections in many ISO/ITU documents:
    The following specifications contain provisions which, through references
    in this text, constitute provisions of this specification.  At the time of publication,
    the editions indicated were valid.  All specifications are subject to revision, and
    parties to agreements based on this Specification are encouraged to investigate
    the possibility of applying the most recent editions of the specifications listed
    below.

Randy