Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems
Intended status: Informational January 25, 2015
Expires: July 29, 2015
The YANG Conformance Problem
draft-bjorklund-yang-conformance-problem-00
Abstract
This document describes the YANG conformance problem. It is intended
as a temporary document to help the NETMOD WG in the design of YANG
1.1.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 29, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bjorklund Expires July 29, 2015 [Page 1]
Internet-Draft YANG Conformance Problem January 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Axioms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Problem P1 - background . . . . . . . . . . . . . . . . . 4
3.2. Problem P1a . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Solution P1a-01 . . . . . . . . . . . . . . . . . . . 5
3.2.2. Solution P1a-02 . . . . . . . . . . . . . . . . . . . 5
3.3. Problem P1b . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Solution P1b-01 . . . . . . . . . . . . . . . . . . . 6
3.3.2. Solution P1b-02 . . . . . . . . . . . . . . . . . . . 7
3.4. Problem P2 - import-by revision everywhere . . . . . . . 7
3.4.1. Solution P2-01 . . . . . . . . . . . . . . . . . . . 8
3.4.2. Solution P2-02 . . . . . . . . . . . . . . . . . . . 8
3.4.3. Solution P2-03 . . . . . . . . . . . . . . . . . . . 8
3.5. Problem P3 . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Problem P4 . . . . . . . . . . . . . . . . . . . . . . . 8
3.6.1. Solution P4-01 . . . . . . . . . . . . . . . . . . . 9
3.7. Problem P5 . . . . . . . . . . . . . . . . . . . . . . . 9
3.7.1. Solution P5-01 . . . . . . . . . . . . . . . . . . . 10
3.7.2. Solution P5-02 . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document describes the YANG conformance problem. It is intended
as a temporary document to help the NETMOD WG in the design of YANG
1.1. It defines some terminology, lists some use cases to be used
when evaluating solutions, and finally lists some (partial)
solutions.
Wikipedia defines "conformance" as "how well something, such as a
product or system, meets a specified standard".
There are two parts to the the conformance problem:
o The mechanisms available for the data model designer to define
compliance levels, i.e., what parts of a data model are mandatory
vs. optional to implement. In YANG, there are two such
mechanisms, modules and features. For comparison, in SMIv2 this
is done with the MODULE-COMPLIANCE macro.
o The mechanism by which an implementation specifies how well it
conforms to the data model specification. In YANG, a server
claims conformance to a module it implements by advertising the
module and the features it implements. A server can also
advertise how it deviates from the module specification by using
Bjorklund Expires July 29, 2015 [Page 2]
Internet-Draft YANG Conformance Problem January 2015
the deviate statement. For comparison, in SMIv2 this is done with
the AGENT-CAPABILITIES macro.
A related question is *how* a server advertises which modules and
features it implements. This is a separate problem, and is not
further discussed here.
2. Axioms
If a server advertises module A with some features, it means that it
implements all data nodes, rpcs, and notifications defined in module
A with these features. It also means that it understands all
identities defined in module A.
Axiom A1: A server must implement all data nodes, rpcs, and
notifications (modulo supported features) in the module it
advertises.
Note that the statement above doesn't say anything about typedefs and
groupings - more on that later.
If module A augments module B, A cannot be implemented without also
implementing the augment's target node. From A1 follows:
Corollary C1: If a server advertises module A that augments a module
B, it must also implement and advertise module B.
And we have:
Axiom A2: A server implements one and only one specific revision of
a module.
Note that from A2 only it does not follow that a server cannot
conform to and advertise multiple revisions of a module. But this is
not how YANG has been understood, thus we have:
Axiom A3: A server must not advertise more than
one revision of a module.
It is important that the client knows what to expect from a server:
Axiom A4: A client must be able to tell which data nodes, rpcs,
and notifications a server implements, including the types
of all leafs and leaf-lists.
Bjorklund Expires July 29, 2015 [Page 3]
Internet-Draft YANG Conformance Problem January 2015
3. Problems
3.1. Problem P1 - background
Consider the following situation:
module mod-a {
...
revision 2001-01-01; // inital version
typedef foo {
type enumeration {
enum q;
}
}
grouping bar {
leaf x { type string; }
}
}
module mod-a {
...
revision 2002-01-01; // new version
typedef foo {
type enumeration {
enum q;
enum w; // enum added
}
}
grouping bar {
leaf x { type string; }
leaf y { type string; } // grouping extended
}
}
module mod-b {
...
import mod-a {
prefix a;
revision 2001-01-01; // uses initial vsn of mod-a
}
leaf b {
type a:foo;
}
container b2 {
uses a:bar;
}
}
Bjorklund Expires July 29, 2015 [Page 4]
Internet-Draft YANG Conformance Problem January 2015
module mod-c {
...
import mod-a {
prefix a;
revision 2002-01-01; // uses new vsn of mod-a
}
leaf c {
type a:foo;
}
container c2 {
uses a:bar;
}
}
module mod-d {
...
import mod-a // uses unknown vsn of mod-a
prefix a;
}
leaf d {
type a:foo;
}
container d2 {
uses a:bar;
}
}
3.2. Problem P1a
Suppose a server implements and advertises mod-b, mod-c and mod-d.
What are the types of leafs b,c?
Which of /b2/y are /c2/y are implemented?
3.2.1. Solution P1a-01
Fix the type and grouping when using import-by revision. In this
case, it is clear what the types of leaf b and c are, and /b2/y is
not supported, but /c2/y is.
3.2.2. Solution P1a-02
Do not use import-by revision (deprecate?), and make it illegal to
extend the value space of a typedef, or add nodes to a grouping. In
this case, we would have:
Bjorklund Expires July 29, 2015 [Page 5]
Internet-Draft YANG Conformance Problem January 2015
module mod-a {
...
revision 2002-01-01;
typedef foo {
type enumeration {
enum q;
}
// possibly status deprecated
}
typedef foo2 {
type enumeration {
enum q;
}
}
grouping bar {
leaf x { type string; }
// possibly status deprecated
}
grouping bar2 {
leaf x { type string; }
leaf y { type string; }
}
}
An advantage of this is that it allows all nodes that reference a
typedef or grouping to receive bug fixes. This works because the
type or grouping is never fixed.
3.3. Problem P1b
Suppose a server implements and advertises mod-b, mod-c and mod-d.
What is the type if leaf d?
Is /d2/y implemented?
3.3.1. Solution P1b-01
Require the server to advertise mod-a, but mark the advertisement as
being "no nodes implemented".
This means that all modules that uses a typedef or grouping without
importing by revision will get the same version of the typedef.
Bjorklund Expires July 29, 2015 [Page 6]
Internet-Draft YANG Conformance Problem January 2015
3.3.2. Solution P1b-02
Require import-by revision everywhere. See P6 though.
3.4. Problem P2 - import-by revision everywhere
Consider the following situation:
module mod-e {
...
revision 2001-01-01; // initial version
container x;
}
module mod-e {
...
revision 2002-01-01; // new version
container x;
container y; // added data node
}
module mod-f {
...
revision 2001-04-01;
import mod-a {
prefix a;
revision-date 2001-01-01; // uses initial vsn of mod-e
}
augment /a:x { ... }
}
module mod-g {
...
revision 2002-04-01; // uses new vsn of mod-e
import mod-e {
prefix e;
revision-date 2002-01-01;
}
augment /e:y { ... }
}
Suppose that a server wants to implement both mod-f and mod-g. From
C1, it follows that it also must implement and advertise mod-
e@2001-01-01 and mod-e@2002-01-01. But this contradicts axiom A3.
Bjorklund Expires July 29, 2015 [Page 7]
Internet-Draft YANG Conformance Problem January 2015
3.4.1. Solution P2-01
Do not allow import-by revision.
3.4.2. Solution P2-02
Relax A3. Let the server advertise both revisions of mod-e.
3.4.3. Solution P2-03
Relax the meaning of import-by revision, to mean "import by minimum
revision". Alternatively add a new statement with this meaning, and
deprecate (?) import-by revision.
3.5. Problem P3
A server may choose to not implement nodes with status "deprecated"
or "obsolete". However, there is no mechanism to advertise which
such nodes are actually implemented on a server.
3.6. Problem P4
Consider the following siutation:
module mod-h {
...
revision 2001-01-01;
...
container x { ... }
}
module mod-i {
...
revision 2001-04-01;
import mod-h {
prefix h;
}
augment /h:x {
container y { ... }
}
A server advertises mod-h@2001-01-01 and mod-i@2001-04-01.
Now, mod-h is revised:
Bjorklund Expires July 29, 2015 [Page 8]
Internet-Draft YANG Conformance Problem January 2015
module mod-h {
...
revision 2004-01-01;
...
container x {
status deprecated;
}
container much-better-x { ... }
}
The server picks up the new revision of mod-h, and advertises mod-
h@2004-01-01 and mod-i@2001-04-01.
Next, mod-h is revised again:
module mod-h {
...
revision 2010-01-01;
...
container x {
status obsolete;
}
container much-better-x { ... }
}
The server picks up the new revision of mod-h, but it does not want
to / cannot implement the obsolete container "x". But this means it
cannot implement mod-i faithfully.
3.6.1. Solution P4-01
This is the way it works. mod-i should be revised, or the server
will have to advertise a devation to mod-i, where the augmented nodes
are not implemented.
3.7. Problem P5
Consider the following situation:
Bjorklund Expires July 29, 2015 [Page 9]
Internet-Draft YANG Conformance Problem January 2015
module mod-system {
...
container system {
container users { ... }
container logging { ... }
}
}
module mod-dns {
...
import mod-system {
prefix sys;
}
augment /sys:system {
container dns { ... }
}
}
If a server wants to implement mod-dns, it follows from C1 that it
must also implement all of mod-system (minus if-featured nodes), even
though the only node that is really necessary is the NP-container
"system".
3.7.1. Solution P5-01
Relax C1, so that a module does not have to be implemented (and thus
not claimed conformance to) because of an augmentation.
The problem with this solution is that it might work for NP-
containers, but what if the target node lies with a list?
3.7.2. Solution P5-02
Do nothing. This is an educational issue. Make sure generic
containers like this "system" do not require the implementation of
many other nodes.
Author's Address
Martin Bjorklund
Tail-f Systems
Email: mbj@tail-f.com
Bjorklund Expires July 29, 2015 [Page 10]