Subject: Re: [netmod] yang-09, sec.10, revision rules

From: Washam Fan <[email-masked]>
Date: Tue, 8 Dec 2009 22:14:59 +0800

Hi Martin,

> Andy Bierman <[email-masked]> wrote:
> > Hi,
> >
> > [this WGLC comment got lost in the wrong thread]
> >
> >
> > It does not make any sense to talk about different versions
> > of a YANG [sub]module without a new revision date.  There is no way
> > to even distinguish which is the old version and which is
> > the new version in a standard way.
> >
> > Sec 10:
> >
> >   For any published change, a new "revision" statement (Section 7.1.9)
> >   SHOULD be included in front of the existing revision statements.
> >
> > Edit 1:  s/SHOULD/MUST
>
> I agree.
>
> > Edit 2:  state (somewhere in sec. 10) that a module without
> >          revisions MUST NOT change (ever)
>
> I don't think this is necessary, but I'm ok with adding it.

Could you elaborate on why this is unecessary? Personally, I think,
it would mess up if no indication for (sub)module change.

washam

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 08 Dec 2009 21:08:30 +0100 (CET)

> it would mess up if no indication for (sub)module change.

It is not sufficient for guaranteed module import / submodule
inclusion; for this you need import/inlcude by revision, and we have
already agreed that we will not make that mandatory to use.

And I expect all standard modules to have a revision history; this is
already a MUST in the guidelines doc.

Even if this is a MUST, it will be hard to detect if a vendor
chooses to not use revisions and modifies a module.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 08 Dec 2009 12:53:48 -0800

> chooses to not use revisions and modifies a module.

This is incorrect.
It is quite possible to diff 2 YANG modules that
claim to be the same, and tell if that is true or not.

The issue is conformance to a standard that actually works.
There is no way to tell 2 module versions apart except
for the standard revision mechanism.  I am strongly opposed
to any unspecified mechanisms being considered to
be within the standard.

If a vendor wants to ignore revisions and the rules in sec. 10,
then they have to be non-compliant to do that.

> /martin

Andy

---

From: Washam Fan <[email-masked]>
Date: Wed, 9 Dec 2009 20:40:31 +0800

Hi,

> claim to be the same, and tell if that is true or not.

Is it realistic the client retrieves every module without revision
from the server to check if it is the same as the local counterpart?

> to any unspecified mechanisms being considered to

Either revision statement or other ways should be used to
tell the module change, IMO.

washam

---

From: Andy Bierman <[email-masked]>
Date: Wed, 09 Dec 2009 07:35:39 -0800

> from the server to check if it is the same as the local counterpart?

No -- that is exactly why modules without any revision date
MUST NOT change.  Even if the optional <get-schema> is supported,
the client has no way to detect a mismatch in the [name, revision, namespace]
tuple that uniquely identifies an advertised module.

> tell the module change, IMO.

other ways?
that isn't standard.
There is only 1 standard way needed, and it is already defined.

Andy