Subject: Re: [netmod] yang-03, import/include by-revision

From: WashamFan <[email-masked]>
Date: Sun, 01 Feb 2009 18:53:56 +0800

Hi, 
>  >>  >> Issue 5) The revision is optional in the file format, so I am 
> not
>  >>  >>           sure what value it has at all.  Does that mean there
>  >>  >>           is no revision, or does it mean the user just felt
>  >>  >>           like leaving it out?
>  >>  > 
>  >>  > Both, but maybe we should be more restrictive, i.e. say that if 
> the
>  >>  > module has a revision stmt, then the filename SHOULD include the
>  >>  > latest revision date?
>  >>  > 
>  >>  
>  >>  case 1)
>  >>  
>  >>     import A { prefix a; revision X; }
>  >>  
>  >>     - if A has no revision X, then the import MUST fail
>  >>       (no module used for A)
>  >>     - A is considered 'revision X' if and only if its highest valued
>  >>       revision-date is X.
>  > 
>  > I got a little confused. X is nonsense if it does not equal highest 
> valued revision-date, i.e, we should always import the most recent 
> module. So Why should we need 'revision X' in the statement?
>  > 
>  
>  no.
>  
>  as modules get updated over time, it is important to
>  preserve pre-existing modules.  Consider a module A that
>  imports a grouping from module B.  The contents of A
>  do not change over time even if the grouping in B
>  does change over time.  Import-by-revision allows
>  module A to 'freeze' its version of the grouping,
>  even if other modules import newer versions of B,
>  and the grouping has different contents in those
>  other modules.

OK. So the most recent module does not obsolete its previous versions. I.e, all versions listed in most recent module's revision statement should be valid if Netconf agent can find all of them. When I write a new module B which would augment a grouping from module A, I do not have to augment the one in the newest module A.

washam

>  
>  > washam
>  
>  Andy
>  
>  > 
>  >>     - A has no revision if it has no revision-stmts.
>  >>       Any import of A requresting a specific version MUST fail
>  >>  
>  >>  case 2)
>  >>  
>  >>     import A ( prefix a; }
>  >>  
>  >>     - if A has revision-stmts (in each instance)
>  >>       then the instance with the highest valued revision-date
>  >>       SHOULD be used
>  >>  
>  >>     - if A does not have revision-stmts (in each instance)
>  >>       then it is implementation-specific which instance
>  >>       of module A is used
>  > 
>  > 
>  > 
>  > 
>  
>  
>  
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Sun, 01 Feb 2009 09:16:45 -0800

> OK. So the most recent module does not obsolete its previous versions. I.e, all versions listed in most recent module's revision statement should be valid if Netconf agent can find all of them. Whe…

You inadvertently brought up a different topic,
which is the status-stmt (current, deprecated, obsolete).
YANG guidelines have yet to be determined for this clause,
as it relates to YANG versions and conformance.

Also, groupings cannot be augmented.

Two huge differences in the complexity
of module management (between SMIv2 and YANG),
stem from the reusable 'grouping', and the 'typedef',
(which can refine other typedefs, not just built-in types).
Groupings can contain 'uses' for other groupings, as well.

In SMIv2, there can only be 2 modules involved in the
'definition skew'.  In YANG, 2 becomes N.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 02 Feb 2009 09:37:03 +0100 (CET)

Martin Bjorklund <[email-masked]> wrote:
> > Issue 3)  The '.' char is allowed in module-or-submodule-name,
> >            so it should not be used as a separator in this file format.
> >            Some operating systems may not like multiple '.' chars
> >            in the filename either. Maybe underscore '_' would be better.
> 
> And some OSs use 8+3 filenames.  I suggest changing the first '.' to '_'.

This won't work either, of course, since underscore is also allowed in
a module name.  But is this really a problem?  The filename SHOULD
(not MUST) be on this form, but if you use a OS which supports 8+3
characters (or whatever other restriction) then your filenames will
not be in this form.

The one time a tool might be confused is if your module is called
something like 'FOO.2008-04-01' which does not have any revision
statements, and you also have a module called 'FOO' with latest
revision '2008-04-01'.  Both these modules would be stored as
"FOO.2008-04-01.yang".

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 2 Feb 2009 08:36:45 -0500

>>            so it should not be used as a separator in this file format.

"_" is also allowed.  I don't see the point.

>And some OSs use 8+3 filenames.  I suggest changing the first '.' to '_'.

Are we trying to be DOS compatible?  Do we need to support OSs that
lack subdirectory support, or boot from floopy disks?  Specific OSs
with issues like this need individual solutions that are outside
of our scope.  I vote to stick with one separator, the period,
rather than mixing two.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 02 Feb 2009 06:14:34 -0800

> of our scope.  I vote to stick with one separator, the period,

I want to know why this section exists in normative text at all.
It should be moved to a non-normative appendix, and made clear
that it is not part of the standard.

Either that, or tackle the problem of universally acceptable
file naming conventions as a standard.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 2 Feb 2009 10:04:27 -0500

>that it is not part of the standard.

IIRC someone at the interim wanted to have concrete recommendations
for file naming so 15 different tool sets didn't use 15 different
conventions.  This was done in the spirit of interoperability.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 02 Feb 2009 07:41:51 -0800

> conventions.  This was done in the spirit of interoperability.

Fine.  It still needs to be in the proper standards-track
RFC section.  Since these are guidelines,  they MUST go in
a separate BCP document or in a non-normative appendix
of this document.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 2 Feb 2009 10:58:04 -0500

>revision '2008-04-01'.  Both these modules would be stored as

Should we say something about what to do in this case (modules
with no revision statement)?  "Use '0' as the revision string"?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 27 Feb 2009 09:15:56 +0100 (CET)

Hi,

Revisiting an old thread.

Martin Bjorklund <[email-masked]> wrote:
> Andy Bierman <[email-masked]> wrote:
> > Issue 7) Why is the full revision-stmt needed in the import-stmt
> >           and include-stmt?  If the description-stmt is really so
> >           important here (IMO no) then it should be a sub-statement
> >           of 'import' or 'include' directly, not a sub-stmt of 'revision'.
> >           I prefer this ABNF instead (without a description-stmt):
> > 
> >       import-stmt            = import-keyword sep identifier-arg-str optsep
> >                           "{" stmtsep
> >                               prefix-stmt stmtsep
> >                               [revision-keyword sep date-arg-str stmtsep]
> >                           "}"
> 
> I agree.  This was a bug.

The 'revision' statement is defined to allow a description
substatement.  Since we don't want to introduce a context sensitive
grammar (by saying that depending on where it is used 'revision'
sometimes has a 'description' substatement, and sometimes not), Andy
suggested (in an off-line discussion) that we use the following
instead:

    import X {
        prefix x;
        revision-date 2009-01-01;
    }

I think this makes sense, and will use it to solve this issue unless
people disagree.

/martin