Subject: [netmod] VRFY :45: better conformance mechanism

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 May 2015 11:59:31 +0200

Hi,

after long discussions in physical meetings, virtual meetings, and on
the mailing list, I believe we have reached rough consensus to adopt
Y45-04 in order to resolve import ambiguities (aka typedef drift and
grouping drift) and we will leave it to YANG extensions (to be worked
on in the future) to provide means to define explicit conformance
requirements (instead of trying to derive conformance requirements
from import relationships alone). A recent poll of core contributors
on this issue can be found here:

http://www.ietf.org/mail-archive/web/netmod/current/msg12560.html

Please speak up by Monday 2015-05-25 if you disagree with this
proposal and your position is not yet included in the email message
pointed to above.

For more details, see the issues list available here:

     http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 May 2015 05:55:26 -0700

Hi,

RFC 6020, sec. 7.1.5 has this sentence:

   Multiple revisions of the same module MUST NOT be imported.

I expect the new RFC will contain a complete explanation why
this MUST NOT is wrong and needs to be changed.
I would expect that multiple implementation examples of this
approach can be cited, as proof that the new solution already works
(before it is standardized).

Andy

On Tue, May 19, 2015 at 2:59 AM, Juergen Schoenwaelder
<[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 May 2015 15:16:08 +0200

> On 19 May 2015, at 14:55, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 

It’s not wrong but without this restriction a data modeller can use some typedefs/groupings from a new revision and isn’t forced to upgrade everything to the new revision at the same time. It was you who advocated this option in Dallas:

   AB: I agree with Martin that the ripple effect is a problem. When
       you want to use a new version of a module, you have to update
       everything else that you use from the same module.

> (before it is standardized).

It will be implemented in pyang, including the mapping to DSDL schemas.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 May 2015 08:00:07 -0700

>        everything else that you use from the same module.

The updating of import revision dates is not "fixed" by adding multiple
import-by-revision statements to a module.

The MUST NOT is correct but it is being removed anyway?
I would expect the sentence to be replaced by a thorough
explanation of why it was incorrectly placed in RFC 6020.

> It will be implemented in pyang, including the mapping to DSDL schemas.

So no existing designs that would validate this approach
before it is standardized? Didn't think so.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 May 2015 17:29:58 +0200

> On 19 May 2015, at 17:00, Andy Bierman <[email-masked]> wrote:
> 

It is - you can import a new revision with a different prefix and update only selected groupings or typedefs.

> explanation of why it was incorrectly placed in RFC 6020.

It’s not about correct-incorrect but rather about better-worse.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 May 2015 17:55:35 +0200

> (before it is standardized).

The attached yang module compiles using pyang 1.3 and if you replace
yang1:uuid with yang0:uuid, you get an error (as one would expect).

Depending on how your code is organized, the Y45-04 behaviour may fall
out naturally and it takes extra effort to implement the MUST quoted
above. It may be possible to find a second implementation that
actually does not implement this MUST. (Our libsmi code has a problem
with import-by-revision so it is not a candidate unless we implement
this.)

The reason to change the MUST quoted above can certainly be explained.

/js

PS: Yes, pyang is broken wrt. YANG 1.0 since it does not implement
    the MUST quoted above.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 May 2015 09:22:29 -0700

> yang1:uuid with yang0:uuid, you get an error (as one would expect).

A tool that parses the syntax is not really the same
as a server implementation.  I do not question the ability
to distinguish 2 different strings as 2 different prefixes.

> The reason to change the MUST quoted above can certainly be explained.

So what is the explanation?
Removing a MUST NOT (especially from a 1.1 maintenance release)
is a big deal.  I would expect it to be easy to demonstrate that
the original MUST NOT is a bug.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 19 May 2015 21:20:52 +0000

It's unclear to me why Y45-04 is needed at all.  Doesn't a newer revision
of a module contain all the same typedefs from before, and thus a module
could import just the more recent revision to get everything it needs?
Why would a module ever have to import an older revision?

RFC 6020 says "New typedefs, groupings, rpcs, notifications, extensions,
features, and identities may be added."   I take this to imply that they
cannot be removed or even renamed.  Is this not the case?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 May 2015 08:24:11 +0200

> to distinguish 2 different strings as 2 different prefixes.

How does the resolution of symbols (typedef and grouping names) at
module compile time impact the server implementation?

> the original MUST NOT is a bug.

The original MUST NOT makes it expensive to upgrade since it is an all
or nothing upgrade mechanism and the only way to ease the pain is that
the module author anticipates incremental updates and maintains N
different versions of definitions to ease the pain. The NETMOD
principle has always been that module readers are first priority,
module writers are second priority, and tool implementers are third
priority. Yes, Y45-04 is a change for tool implementors (except
perhaps tools that failed to implement the MUST NOT) but it is done
for a reason.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 May 2015 08:26:51 +0200

> cannot be removed or even renamed.  Is this not the case?

The definitions can be changed and Y45 is about making sure that we
always know precisely which definition is used - this was called
typedef drift and grouping drift. Please check the extensive
discussions we had about this plus the I-Ds people wrote about this.
I do not think we should restart this discussion once more.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 May 2015 10:40:05 -0700

> module compile time impact the server implementation?

Implementors who followed the MUST NOT rule may have optimizations
wrt/ symbol resolution.  These will be invalid once the MUST NOT is removed.
It is fairly trivial to parse YANG compared to implementing NETCONF/YANG
it in a server.

> perhaps tools that failed to implement the MUST NOT) but it is done

The original MUST NOT depends on the update rules in sec. 10.
IMO following lots of dependencies makes YANG modules harder
to read, so I don't agree Y45-04 is good for readers.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 May 2015 10:51:28 -0700

> I do not think we should restart this discussion once more.

You seem to be suggesting that Kent is an uninformed observer and Y45-04
is actually really easy to understand.  Neither is true.
The solution is not intuitive at all.  The implications of cherry-picking
YANG statements from various revisions of a YANG module are
not well understood.  The concept of writing a YANG module
so it works with all possible combinations of all possible back-revisions
of imported modules is not well understood.

The question "why can't the module being updated use the latest revision
of an import" is quite legitimate.  So is the question "Why can't I determine
what a server implementation is required to support for a given YANG module?"

The issue title "Better YANG conformance" is misleading because YANG
conformance specificity is actually much worse with this solution.
It's great for vendors who want to interpret for themselves
what conformance means.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 21 May 2015 00:39:33 +0000

>is actually really easy to understand.  Neither is true.

I appreciate Andy's vote of confidence, but the reality is that I fell
into a black hole right at the end of the Dallas meeting and just now
caught up on the Y45 discussion.  That said, my comment was based solely
on what I read in the YANG 1.1 issue list, which wasn't easy to
understand, so at least that part is true  ;)

<chair hat on>

After catching up on the Y45 discussion to date, I was concerned if Andy's
objection to the removal of the MUST NOT clause might be substantiated by
the Charter, which currently says:

  "The changes to RFC 6020 are restricted in the following ways:
     - All compliant YANG 1.0 modules must be accepted as compliant
       YANG 1.1 modules.
     - All known ambiguities of YANG 1.0 and all reported defects
       and errata will be addressed.
     - YANG 1.1 is not adding fundamentally new data modeling
       concepts to the language.
     - The changes of the specification will be kept to the minimum
       necessary to achieve the previously stated goals."

The 1st point was the one I was worried about the most.  Had it said
instead "6020bis must be backwards compatible", then Y45-04 would not be
allowed.  However, as worded, Y45-04 is OK.  The 3rd and 4th points are up
to interpretation, but I don't think Y45-04 steps over the line.

<chair hat off>

I don't have a strong preference or objection to any of the proposed
solutions (Juergen, you can mark this statement in your table).  That
said, I wish we could better decouple "imports for typedefs/groupings"
from "imports for augments/leaf-refs".  For instance:

  import-declaration mod-a {
    prefix a;
    revision 2001-01-01;
  }
  import-declaration mod-a {
    prefix a2;
    revision 2002-01-01;
  }
  import-runtime mod-a {
    prefix a2;
    min-revision 2002-01-01;
  }

The idea is to give explicit control to the module designer to cherry-pick
declarations from any module revision *and* specify the min-revision
needed (if any) in order to resolve protocol accessible nodes.  Of course,
this would break point #1 in the charter above, but it seems better than
leaving it solely to the discretion of the server...

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 May 2015 08:27:35 +0200

On Wed, May 20, 2015 at 10:51:28AM -0700, Andy Bierman wrote:
 
> not well understood.

If there are issues that have not been brought up before that we do
not understand, please put them on the table. But things need to be
concrete, not abstract.

> The concept of writing a YANG module so it works with all possible
> combinations of all possible back-revisions of imported modules is
> not well understood.

This is an example of an abstract claim that is difficult to work
with.

> It's great for vendors who want to interpret for themselves

This is what I wrote:

  I believe we have reached rough consensus to adopt Y45-04 in order
  to resolve import ambiguities (aka typedef drift and grouping drift)
  and we will leave it to YANG extensions (to be worked on in the
  future) to provide means to define explicit conformance requirements
  (instead of trying to derive conformance requirements from import
  relationships alone).

I think we concluded from ~1 year of discussions that deriving
conformance requirements from import statements does not work.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 May 2015 02:27:50 -0700

> This is an example of an abstract claim that is difficult to work

According to Y45-04, if I use import-by-revision it only applies
to some statements.  The vendor can use any revision for
the rest of the statements.  This may be abstract to you, but
it sounds like a tech-support nightmare to me.

> conformance requirements from import statements does not work.

Then we agree that this issue does nothing for conformance
(except make it worse).

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2015 14:40:47 +0200

> to interpretation, but I don't think Y45-04 steps over the line.

Of course it doesn't, but it is not only this issue where Andy insists
(above the charter) on stricter backward compatitibility - except for new
features that he has already implemented.

I think we would get nowhere with YANG 1.1 if everybody fiercely opposed
changes that need some work on his part.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 May 2015 07:21:24 -0700

> changes that need some work on his part.

I haven't implemented any of YANG 1.1, but that is irrelevant.
I don't ilke standardizing solutions that have never been
tried and have not been proven to be useful.

Changing a MUST NOT to a MAY in any standard is a big deal.
It needs to be done with care and clarity.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2015 16:37:03 +0200

> On 21 May 2015, at 16:21, Andy Bierman <[email-masked]> wrote:
> 

You once mentioned Yuma already supported XPath extension functions. Is it not true?

> It needs to be done with care and clarity.

RFC 6020 also states that must and when expessions are XPath 1.0, and we are moving away from it. This is IMO a much bigger change than Y45-04.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2015 16:42:44 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> RFC 6020 also states that must and when expessions are XPath 1.0, and
> we are moving away from it.

No we are not moving away from XPath 1.0.  XPath 1.0 allows you to specify
a function library - in fact, it *requires* you to do this - and we
use the core function + some more.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2015 16:47:38 +0200

> On 21 May 2015, at 16:42, Martin Bjorklund <[email-masked]> wrote:
> 

Well, but RFC 6020 states:

   o  The function library is the core function library defined in
      [XPATH], and a function "current()" that returns a node set with
      the initial context node.

Introducing new functions certainly affects implementors.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2015 16:50:04 +0200 (CEST)

> Introducing new functions certainly affects implementors.

Absolutely.  But we're not moving away from XPath 1.0.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 May 2015 16:51:27 +0200

> On 21 May 2015, at 16:50, Martin Bjorklund <[email-masked]> wrote:
> 

Yes, sorry, this was my wrong formulation.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 May 2015 10:14:53 -0700

> You once mentioned Yuma already supported XPath extension functions. Is it not true?

Within the C code there is an extensible XPath function library.
It would be unreasonable to design a XPath implementation
with a hard-wired function library. The standard is designed
to support the opposite.

> RFC 6020 also states that must and when expessions are XPath 1.0, and we are moving away from it. This is IMO a much bigger change than Y45-04.

Show me the "MUST NOT" that is getting reversed and I will agree with you.
I am not objecting to Y45-04.  I am objecting to removing a "MUST NOT"
from the standard.  Discussion of relative implementation complexity
of other YANG 1.1 changes is irrelevant.

Andy

---

From: Per Hedeland <[email-masked]>
Date: Thu, 21 May 2015 19:38:45 +0200

> of other YANG 1.1 changes is irrelevant.

I don't have one for that, but these are:

   A member type can be of any built-in or derived type, except it MUST
   NOT be one of the built-in types "empty" or "leafref".

I believe they're described as CLR in the issues doc...

--Per Hedeland

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 May 2015 10:46:56 -0700

> I believe they're described as CLR in the issues doc...

I don't know about leafref, but type "empty" and a zero-length string
are identical on the wire, and that is allowed.  This is a trivial
change to YANG syntax. I don't think Y45 has such a trivial impact
on YANG syntax or usage.

Andy

---

From: Per Hedeland <[email-masked]>
Date: Thu, 21 May 2015 20:06:51 +0200

> change to YANG syntax. I don't think Y45 has such a trivial impact

Probably not (though the needed server implementation change is not
likely to be as trivial as the syntax change), but you said that you
weren't objecting to Y45, but to removing a "MUST NOT"...

--Per

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 May 2015 11:25:09 -0700

> weren't objecting to Y45, but to removing a "MUST NOT"...

I object to removing this specific MUST NOT, not any in general.
I don't agree this MUST NOT was an omission or trivial CLR
like the example you cited.  I think the WG made the correct decision
the first time.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2015 22:36:45 +0200 (CEST)

Andy,

I don't think the implementation burden on the server is that heavy.
A YANG 1.0 compliant server today supports:

   leaf a in module A of type foo from foo@2001-01-01
   leaf b in module B of type foo from foo@2002-02-02

I.e., it supports different leafs in the combined data model referring
to different versions of the same type.

A YANG 1.1 server would also support

   leaf a in module A of type foo from foo@2001-01-01
   leaf b in module A of type foo from foo@2002-02-02

Of course, how much a specific implementation is affected will vary,
but I don't think the concepts are *that* different.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 May 2015 14:17:51 -0700

> but I don't think the concepts are *that* different.

I am not that concerned about the implementation details.
Our server fully supports multiple revisions at once.
I am more concerned with the increased complexity
due to multiple imports of the same module.

I think Y45-03 is sufficient and Y45-04 covers
1 or 2 corner-cases that don't justify the increased complexity.
In the hands of experts it won't be a problem, but most
YANG modules are not read or written by experts.

We don't have any experience using multiple revisions
at once. Even the example touted as the reason we need Y45-04
was pointless (because ip-address the same in both revisions).
I am not convinced it is really needed. I am much more comfortable
adding a new feature like "actions", because there is significant
deployment of this solution approach.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 May 2015 16:15:17 -0700

Martin,

I will remove my objection to Y45-04 if you write a section
in the draft about why multiple imports of the same module
is needed, plus examples that show appropriate use
of this new feature.

I also think examples are needed that highlight how data nodes and
augments ignore the revision date (multiple module augments
example), while still using groupings and typedefs that do not
ignore the revision dates.

IETF modules should not need to cherry-pick from multiple
revisions.  That means the WG is deciding to stay "down-rev"
on something, and that should not be approved without good reason.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2015 10:20:37 +0200

>    leaf b in module B of type foo from foo@2002-02-02

In fact, the same can be done in two submodules of the same module, or
main module and submodule, which leads exactly to the situation below -
and that's allowed even in YANG 1.0.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2015 10:29:52 +0200

> is needed, plus examples that show appropriate use

The use case is clear: With the IETF process in place, one cannot expect
fine granularity of module revisions. That is, a new revision may
typically include several changes, and authors of modules that import
such a module may want to use just a subset of the changes and stick to
the old revision for the rest.

There is some evidence it was you who came up with this use case when
you advocated that every change in a grouping/typedef be accompanied
with a name change of the grouping/typedef, and both the old and new
version be kept.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 May 2015 10:37:29 +0200 (CEST)

> and that's allowed even in YANG 1.0.

Yes, you're right!  Which makes the current MUST NOT more of a CLR.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 May 2015 07:11:27 -0700

> Yes, you're right!  Which makes the current MUST NOT more of a CLR.

Completely wrong because each submodule is its own context and you
cannot combine
multiple revisions of any module in any 1 submodule.  All XPath and other
statements in the submodule will only be using 1 revision of any of the
submodules or modules it can access.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 May 2015 16:21:43 +0200

> On 22 May 2015, at 16:11, Andy Bierman <[email-masked]> wrote:
> 

This looks like your wishful thinking - the CLR in section 7.1.5 is totally unqualified, and my interpretation is that it’s meant for the text of a single module or submodule because an import in one submodule doesn’t apply to other submodules nor the main module. Moreover, I can easily combine *groupings and typedefs* from multiple revisions. For everything else, including XPath, the revisions are irrelevant.

Lada