Subject: [netmod] data model conformance

From: Andy Bierman <[email-masked]>
Date: Sat, 18 Oct 2008 10:32:55 -0700

Hi,

IMO, the if-feature proposal, not to be confused
with the addition deviation-stmt proposal, is a
good inline solution if the number of features is small.

However, I do not think it is sufficient or even the most
appropriate solution approach for the module conformance problem.

IMO, the following proposal addresses the deficiencies of
the if-feature approach, and also makes import/include by revision
unnecessary.

module foo {

   namespace "...";
   prefix foo;

   import x { prefix x; }
   import y { prefix y; }

   include foo-submod;

   revision 2008-10-18 {
     description "latest version";
   }

   revision 2007-09-10 {
     description "initial version";
   }

   // all the module definitions

   conformance 2008-10-18 {
     uses-import x {
        version 2007-10-17;
     }
     uses-import y {
        version 2008-03-01;
     }
     uses-include foo-submod {
        version 2007-09-10;
     }
     object-variance /foo:container/foo:leaf1 {
        config false;
     }
     object-variance /foo:container/x:list1 {
        min-elements 0;
        max-elements 0;
     }
   }

   conformance 2007-09-10 {
     uses-import x {
        version 2007-01-05;
     }
     uses-import y {
        version 2007-07-16;
     }
     uses-include foo-submod {
        version 2007-09-10;
     }
   }
}

The exact ABNF is TBD, but the conformance statement is
what a WG would agree on before publishing a DM version.
The syntax may end up similar to the deviation-stmt,
but reporting agent implementation non-conformance
is a different problem that agreeing on minimum
conformance requirements for a standard data model.

E.g., a module could claim conformance to version 2008-10-18
of module foo, even if it did not implement 'x:list1',
or did not allow writes to 'foo:leaf1'.

All readers and tools would know which versions
of all modules involved for each published revision
of each module.  There is no ripple effect, since the
import-stmt never needs to be edited.  There is no
enumerated list of objects to write, but there is still a
need for tools to maintain N versions per module.

This would work with the if-feature construct, in that,
any features that are in effect in a given version
are part of the conformance.  An 'object-object' variance
clause for an object within a feature only has meaning
if that feature is supported by the agent.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 27 Oct 2008 15:40:31 +0100 (CET)

Hi,

>    // all the module definitions

Is the idea that the construct above is used instead of import by
revision?  I.e. if you would have used import by revision for a
certain module, you propose that this construct is used instead?

Is the argument to conformance above just a string?  Can I do:

  conformance full {
      uses-import x {
          version 2007-10-17;
      }
  }

  conformance read-only {
      uses-import x {
          version 2007-10-17;
      }
      object-variance /top {
          config false;
      }
  }

> conformance requirements for a standard data model.

Agreed.  So if an agent claims conformance to the 'read-only'
conformance level above, it would not use any deviation statements,
right?  deviation is still used for when you break some of the
standardized conformance levels.

> import-stmt never needs to be edited.

But don't you just move the problem?  From the import statement to the
conformance section.  If you need to use a new version of an imported
module, you have to modify the conformance sections.

I don't see how this proposal makes handling multiple revisions
easier, and I also think it a bit unintuitive to specify which version
is imported in the conformance level.  This makes it possible to
import different versions in different levels.

> if that feature is supported by the agent.

I like this.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Oct 2008 08:12:31 -0700

> Is the argument to conformance above just a string?  Can I do:

Not sure which would work best:
   1) named conformance sections that get modified each release
   2) 1 unnamed conformance section that gets modified each release
   3) 1 conformance section for each published release; the old
      ones get kept around (like the old revision statements)

> standardized conformance levels.

correct

> module, you have to modify the conformance sections.

yes, sort of.
If multiple concurrent conformance sections are allowed,
then import-by-revision is actually better, because it
does not allow different revisions of an external module
for different conformance levels.

IMO, the entire import/include by revision needs to be tossed
and a different, must less permissive, and much less complex
mechanism for identifying the contents of a specific release
needs to be used.

I only liked import-by-revision better than listing
the leafs that are required for a conformance level,
because I thought import-by-revision could be made to
work without N versions of every identifier used in
the system.  But it can't, and managing all the revision
ripple for modules published in RFCs is going to
be a non-trivial workload in itself.

> import different versions in different levels.

I think you are right.
Nothing short of listing the leafs (somehow, e.g., GROUPs)
and the variance allowed for particular leafs, is going
to work -- except if typedefs and groupings cannot
be semantically altered after first publication.

Listing the leafs for a conformance level is always going
to be more verbose than simply omitting the info.
But I prefer to be able to inspect the contents of
a YANG module with simple tools like a text reader
or a WEB browser.  If I have to rely on custom tools
to tell me what is in any particular YANG module version,
those tools may not always be available, or if they have bugs,
they will be relied on anyway.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 27 Oct 2008 11:54:21 -0400

>for different conformance levels.

I concur that you aren't fixing anything with this new syntax, just
moving the revision from the import/include to a section of the
module that's less directly tied to the import/include.  Will
conformance sections be allowed to list differing revisions?
Will this somehow be less complex?

>mechanism for identifying the contents of a specific release

Less permissive?  Import by revision is strict and exact.
This is a good thing.

>they will be relied on anyway.

This argument of buggy custom tools is a red herring.  You can read
YANG modules as text files in any tool, and YANG is unlikely to
cure all bugs in all software.

If you import a specific revision of a module, discovering that
module's contents is a pretty easy job.  On the other hand, it is
a difficult taks to perform as a post mortem, trying to dig into a
module that imports an unknown revision of a second module and
trying to understand what the original author intended and if (when)
it matters that I use a more modern revision.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 27 Oct 2008 21:18:06 +0100 (CET)

Hi,

Wouldn't it work if we do import by revision, and add your conformance
statement minus uses-import?

There can be multiple conformance statements, specifying different
conformance levels.  The conformance level is advertised in the hello
message.  If no conformance level is advertised, the agent claims full
conformance to all features it advertises.

Each conformance level specify the 'object-variance' for each leaf /
subtree it modifies:

   conformance partial {
       description
          "Devices that cannot modify XXX in their hardware may claim
           partial conformance.";
  
       object-variance "/top/foo/bar" {
           config false;
       } 

       object-variance "/top/foo/baz" {
           config false;
       } 
   }

   conformance read-only {
       // the entire module is read only on this conformance level
       object-variance "/top" {
           config false;
       }
   }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Oct 2008 13:51:08 -0700

>        // the entire module is read only on this conformance level

I like this a lot, but import-by-revision is irrelevant to
the problem of partial conformance levels.  This allows
vendors to claim 'full', 'partial', or 'read-only' conformance,
where full is implied to be everything in the module,
not described by any 'conformance-stmt'.

IMO, this solves part of the ipfix request: fine-grained mods
to full conformance.  The capability mechanism in the protocol
already exists for course-grained conformance, so I don't
see why feature/if-feature is a must-have right now.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 29 Oct 2008 13:54:57 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> >        } object-variance "/top/foo/baz" {
> >            config false;
> >        } }
> > conformance read-only {
> the problem of partial conformance levels.

Agreed.  I just meant that your conformance idea could also work with
import-by revision, it doesn't have to include used-import.

> to full conformance. 

Yes.

> The capability mechanism in the protocol

But then we're saying that if you want to partition your module, you
must split it into several modules, each with its own namespace etc.
The feature construct is supposed to make a more light-weight
construct available to the module designer.  One module is reported as
one capability.  Each module can have zero or more features (or
"sub-capabilities").

I like your 'conformance' statement for specifying conformance levels,
and I think it works nicely togther with 'feature' and 'deviation'.

It also works with "import by revision", if we decide to do that.

I would like to see a detailed proposal for this conformance
statement, and I'm prepared to work on this.

/martin