On Fri, Jun 26, 2015 at 1:59 AM, Martin Bjorklund <m...@tail-f.com> wrote:
> Andy Bierman <a...@yumaworks.com> wrote:
> > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund <m...@tail-f.com>
> wrote:
> >
> > > Hi,
> > >
> > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order
> > > to address Y45-04. Note that YANG 1.1 uses the module
> > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the
> > > crossposting).
> > >
> > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?]
> > >
> > > We have a whole bunch of documents that have a normative reference to
> > > draft-ietf-netmod-rfc6020bis, which has a normative reference to
> > > draft-ietf-netconf-yang-library. This means we need to finish this
> > > document pretty soon.
> > >
> > > I ran into some issues with ietf-yang-library:
> > >
> > > 1. The leaf "conformance" is of type "boolean". It is not obvious
> > > what "conformance = false" means. Should we change the name
> > > and/or type of this leaf?
> > >
> > >
> >
> > Here is a proposal.
>
> Thanks, I think this is good progress.
>
> > There are no restrictions about how many revisions can appear
> > in order to support existing YANG 1.0 servers, which have
> > no such restrictions.
>
> I don't think this is an important goal. I also think that this
> module should have yang-version 1.1 - which all modules will have
> going forward.
>
> But if we combine what both of us have said there are two goals with
> this module:
>
> 1. Solve the advertisement problem (protocol independent).
>
> 2. Provide a complete listing of all YANG modules used in the
> server.
>
> I believe that your proposed solution below can solve both these
> requirements (with some minor tweaks):
>
> > leaf conformance
> > mandatory true;
> > type enumeration {
> > enum implement {
> > description
> > "The server implements the specified revision of this
> module";
>
> Ok. We need to clearly define what "implement" a module means. I
> have started to do this in 6020bis, so we should provide a ref to that
> section.
>
> > }
> > enum import {
> > description
> > "The server imports the specified revision of this
> module";
>
> This should be more precise - "the server uses the specified revision
> of this module for all other modules that import this module without
> revision".
>
> > }
> > enum none {
> > description
> > "The server does not use the specified revision of this
> > module.
> > The server only supports retrieval of this YANG
> module.";
>
> I don't think this is correct. The server would list a typedef only
> module that is imported by revision here, right? I think it should
> be something like "the server uses the specified revision of this
> module because some other module imports this revision".
>
> We should also say:
>
> There MUST NOT be more than one listing with conformance "implemented"
> for a given module name.
>
This is not true for YANG 1.0, only YANG 1.1
>
> There MUST NOT be more than one listing with conformance "import"
> for a given module name.
>
>
There are no restrictions on YANG for what is contained in the same module.
Module X can have typedefs, groupings, and objects.
The server implements the objects in X.5.
According to YANG 1.1, Y45-04:
Module A can import X.1 for its typedefs.
Module B can import X.2 for a different version of the typedefs.
Module C can import X.3 for the groupings in that version.
The library will have these entries:
module=A, revision=1, conformance=implement
module=B, revision=1, conformance=implement
module=C, revision=1, conformance=implement
module=X, revision=1, conformance=import
module=X, revision=2, conformance=import
module=X, revision=3, conformance=import
module=X, revision=5, conformance=implement
> How is a deviation module listed? Does the conformance leaf matter
> for such a module?
>
>
I think 'deviation' should be its own enum, not use 'none'
The nice thing about enum 'import' is that the server does not need to
provide deviation statements for any objects in the base module,
just to import from the module.
>
> /martin
>
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
