Subject: [Netconf] Y45-04 and ietf-yang-library

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Jun 2015 23:14:49 +0200 (CEST)

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?

      I don't have a good proposal, but what we need is a way to
      indicate "I implement the protocol accessible nodes in this
      module" vs. "I just list this module b/c some other module that
      I implement uses typdefs/groupings/... from it".

      This issue is related to the github issue #3.  I think we need
      this information; Y45-04 relies on it.

  2.  The "/modules/module" list is keyed by "name" and "revision".
      Should we really have "revision" as key?  A server can only
      implement one revision of a module, and should only list one
      revision of a module w/ conformance = false.  I suggest we make
      this leaf mandatory, and not part of the key.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jun 2015 14:31:00 -0700

>       this information; Y45-04 relies on it.

We went through this before and you didn't have a better suggestion last
time either.

conformance=false means the server is not claiming conformance for this
module.  A NETCONF <hello> should not have any modules tagged
as conformance=false.

CoMI relies on this module as well.
It has been ready for WGLC since January.

>       this leaf mandatory, and not part of the key.

I am not in favor of this change.
Two modules "foo" and "bar" released on the same date
could not be represented.

I think the indexing is fine in the current draft.
The <get-schema> operation in NETCONF and RESTCONF need
the module name and the revision-date.

This module should not care how many revisions of each module
are listed.  This is the full YANG library, not a <hello> message.

> /martin
Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Jun 2015 10:14:17 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> module.

Yes I know.  I just wish we had a better name for this.  But you're
right, if we can't come up with a better term, we'll stick to what we
have.

> A NETCONF <hello> should not have any modules tagged
> as conformance=false.
> 

The name of the module would be the (single) key, so this should be
possible.

> the module name and the revision-date.

Yes, revision must be mandatory.

> are listed.  This is the full YANG library, not a <hello> message.

The whole point of this module is to replace the <hello> message!  It
first came up in RESTCONF, and we want to use it also in NETCONF in
order to have one single way to do YANG module advertisement
regardless of protocol.

There is already the schema list in ietf-netconf-monitoring that gives
you the full set of modules and submodules used in a server.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Jun 2015 05:50:02 -0700

> The name of the module would be the (single) key, so this should be

This does not work.

> Yes, revision must be mandatory.

Unless revision is the key then only 1 revision of the module is possible.

> you the full set of modules and submodules used in a server.

We already discussed relation to the schema list and decided to ignore it.
The whole point of this library is to provide the full list of YANG modules
and submodules on the device.

I strongly object to changing this module.
IMO it is quite clear how to fill in the list of modules.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Jun 2015 06:05:59 -0700

> .....
This is not true.

       --ro schemas
      |  +--ro schema* [identifier version format]
      |     +--ro identifier    string
      |     +--ro version       string
      |     +--ro format        identityref
      |     +--ro namespace     inet:uri
      |     +--ro location*     union

There is no way to tell a submodule from a module in RFC 6022.
There is no way to tell which submodules go with which modules.
There is no way to identify deviation files.
So this 'schema' list does not work for RESTCONF or CoMI.
That is 1 reason it was rejected and the ietf-yang-library module
is being used instead.

It is very useful for a client to be able to scan 1 table and find out
all the YANG files used by the server, and then use <get-schema>
to retrieve any files missing from the client.

IMO the <hello> message issue is misguided because the size of the
hello message is not really a bottleneck anywhere.  Even 1000 YANG modules
would be less than 100K in a <hello> message.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Jun 2015 21:33:07 +0200 (CEST)

> Unless revision is the key then only 1 revision of the module is possible.

Correct.  We agreed that a server cannot implement more than one
version of a module (i.e., conformance = true).  And the reason for
listing other modules (conformance = false) is for the client to learn
which revision of such a module is used by the server in modules that
import them without revision.  Again, there must only be one such
revision.

An example might help.

Suppose we have a typedef only module "t", and three modules "a",
"b", and "c" importing it:

  module a {
    ...
    import t {
      prefix t;  // note: no revision-date
    }
    ...
  }

  module b {
    ...
    import t {
      prefix t;
      revision-date 2015-01-01;
    }
    ...
  }

  module c {
    ...
    import t {
      prefix t;
      revision-date 2015-02-02;
    }
    ...
  }

  module t {
    ...
    revision 2015-02-02;
    revision 2015-01-01;
    ...
  }

Now the server lists in ietf-yang-library:

  modules:
    module:
      name: t
      revision: 2015-01-01;
      conformance: false
    module:
      name: t
      revision: 2015-02-02;
      conformance: false
   ...

A client downloads all modules from the server.  Now, how can the
client tell which revsion of "t" was used to implement "a"?

I can se two solutions:

  1.  Just list one revision of "t" - the one used to implement module
      "a" (and any other module that imports "t" w/o revision).

      There really is no reason to list the other revsion of "t".

  2.  List both revisions of "t", but mark the one that is used to
      implement module "a" in some way.

> IMO it is quite clear how to fill in the list of modules.

Yes it is clear.  I argue that it the information is provides is not
sufficient to solve the advertisement problem.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Jun 2015 21:37:27 +0200 (CEST)

> There is no way to identify deviation files.

A client can just download all of them and find which submodules etc
are in there.

> would be less than 100K in a <hello> message.

Are you saying you want to undo Y16?

One nice thing with ietf-yang-library is that is has potential to be
used as the advertisement solution for any YANG-based protocol.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Jun 2015 13:23:24 -0700

> A client can just download all of them and find which submodules etc

The feedback I have received is that the NETCONF schema table is not
very good and does not list all the YANG files, such as
the submodules and deviations.  The goal is to be able to retrieve
the correct module set without needing to
parse the modules first to find all the imports and includes.

I don't see why it helps to remove the version index.
Explain what problem this solves?

Since YANG 1.1 allows module X to import an unlimited number of
revisions of Y, I don't see how the server can just list 1 revision of
each module in its library.

> Are you saying you want to undo Y16?

I don't care much if the YANG 1.0 way is used for YANG 1.1 as well.
IMO it is very confusing that there are 2 ways of advertising
modules, based on the language version.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Jun 2015 14:46:14 -0700

>       and/or type of this leaf?

Here is a proposal.
There are no restrictions about how many revisions can appear
in order to support existing YANG 1.0 servers, which have
no such restrictions.

    leaf conformance
      mandatory true;
      type enumeration {
         enum implement {
            description
              "The server implements the specified revision of this module";
         }
         enum import {
            description
               "The server imports the specified revision of this module";
         }
        enum none {
            description
               "The server does not use the specified revision of this
module.
                 The server only supports retrieval of this YANG module.";
         }
     }
   }

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Jun 2015 10:32:00 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> the submodules and deviations.

That seems to be an issue with the implementation rather than the
model.

> The goal is to be able to retrieve

Yes; download all modules in the schema list.

> Explain what problem this solves?

It solves the advertisement problem:

  1.  The client needs to know which modules the server implements,
      and their revisions.

      Since a server can only implement one revision of a module, this
      is easy.  List the module and mark it with conformance
      true.

  2.  Some definitions-only modules might be imported by revision by
      the modules that are implemented.  These do not need to be
      advertised.

  3.  Some definitions-only modules might be imported without revision
      by the modules that are implemented.  The server MUST pick one
      revision and use that, and it needs to advertise this revision,
      and mark it with conformance false.

      Again, it is just one revision.

If this list contains more than one revision of a conformance false
module, the client cannot tell which revision was used.  And if the
list contains more than one revision of a conformance true module, the
server lies (since it cannot implement more than one revision).

> each module in its library.

See above. 

> modules, based on the language version.

The YANG 1.0 way only works for NETCONF.  So there will be another
mechanism for RESTCONF and possibly other protocols.  Isn't it better
to use that mechanism for all protocols?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Jun 2015 10:59:07 +0200 (CEST)

> >       and/or type of this leaf?

Thanks, I think this is good progress.

> in order to support existing YANG 1.0 servers, which have

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

>               "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.

>                "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".

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

  There MUST NOT be more than one listing with conformance "import"
  for a given module name.

How is a deviation module listed?  Does the conformance leaf matter
for such a module?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Jun 2015 07:12:15 -0700

> module should have yang-version 1.1 - which all modules will have

This is an an important goal to me.

I do not see any value in restricting the contents of the YANG library,

IMO the library MUST contain all the YANG files and it MUST
bwe absolutely clear which files are modules, submodules, or deviations.
The schema list does not do that.

> have started to do this in 6020bis, so we should provide a ref to that

Any implementation of a protocol-accessible object.
Fairly obvious I think.

> module because some other module imports this revision".

I want to support a "module server" that does nothing more than
provide all the YANG modules for retrieval.

>   There MUST NOT be more than one listing with conformance "import"

No -- YANG 1.1 allows module X to
import module Y a million times if it wants.
Every one of those revisions of module Y will be listed.

> How is a deviation module listed?  Does the conformance leaf matter
I would say 'none'

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Jun 2015 10:18:51 -0700

>   There MUST NOT be more than one listing with conformance "implemented"

This is not true for YANG 1.0, only YANG 1.1

>   There MUST NOT be more than one listing with conformance "import"
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
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.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 27 Jun 2015 10:19:27 +0200 (CEST)

> This is not true for YANG 1.0, only YANG 1.1

How can you implement two revisions of a module in YANG 1.0?  IMO it
is not possible.

>     module=C, revision=1, conformance=implement

Ok.

>     module=X, revision=3, conformance=import

I would say that all these should be conformace=none.  Or maybe a new
enum if you prefer.  

I have tried to explain the rationale for this, but apparently I have
failed.  The problem is that if module D imports X without revision,
the client needs to be able to determine which revision of X the
server uses.

> I think 'deviation' should be its own enum, not use 'none'

But as you wrote above, deviations can be mixed with other statements,
so a module cannot be classified as "deviation" only.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 27 Jun 2015 08:50:02 -0700

> > > of this module for all other modules that import this module without

It is true in YANG 1.1 that the revision used if no import-date
is given in the import-stmt, if the server implements some specific
revision.  If not, then good luck figuring out which one to use.

Is this a new requirement you are adding that all import-without-revision
of X refer to just 1 revision of X?

> I would say that all these should be conformace=none.  Or maybe a new

The module X example above could all be import-by-revision.
All this example, modules, A, B, and C just use typedefs and groupings
from module A.  Even in RFC 6020 (sec. 7.1.5) it is quite clear that
each of these modules (A, B ,C) can import their own revision of module A.

   When the optional "revision-date" substatement is present, any
   typedef, grouping, extension, feature, and identity referenced by
   definitions in the local module are taken from the specified revision
   of the imported module.  It is an error if the specified revision of
   the imported module does not exist.  If no "revision-date"
   substatement is present, it is undefined from which revision of the
   module they are taken.

Note that this text says import-without-revision does not require the
server to
use any specific revision.  Are you proposing a new YANG 1.1 issue,
and trying to change this paragraph?

In the example, let's say A and B import X by revision but C does not.
This list does not help a client figure out which entry for X was used.
As you pointed out to the WG, the only way to do that would be
to replicate all the nested import-stmts for a module and add
any missing revision dates.

> the client needs to be able to determine which revision of X the

No --- the current RFC says that is not possible.
There is no way to do that. What if module X is not implemented
at all, just the typedefs and groupings used?

   module A {
      ...
     import X { revision 2014-01-01; prefix x; }
     revision 2014-06-01;
   }

   module B {
      ...
     import X { prefix x; }
     revision 2015-02-01;
   }

  module C {
      ...
     import X { revision 2015-01-01; prefix x; }
     revision 2015-06-01;
   }

     module=A, revision=2014-06-01, conformance=implement
     module=B, revision=2015-02-01, conformance=implement
     module=C, revision=2015-06-01, conformance=implement
     module=X, revision=2014-01-01, conformance=import
     module=X, revision=2015-06-01, conformance=import

In this case, the client has no idea which revision of X is imported by B.
The library narrows the choice from all revisions to 2 in this example.

What if modules A, B, C, and X import other modules,
which in turn import other modules?  YANG clearly allows
each one to import a specific revision or leave the revision
completely unspecified.

I think you are suggesting a new rule and maybe a new leaf,
sibling of the 'conformance' leaf:

   leaf default-revision {
      type boolean;
      default false;
      description
         "Indicates that this revision is used by the server if this module
          is imported without a specific revision date.";
    }

I can't think of any reason this could not be implemented
in a YANG 1.1 server.  It is quite clear YANG 1.0 imports
cannot be restricted in this way.

> so a module cannot be classified as "deviation" only.

It is true that deviations can be combined with regular objects,
except it is not allowed in IETF modules. In practice this does not work
because the regular modules are shared by all the vendor platforms.
The deviations are platform-specific so they are done in their own module.
I would suggest conformance 'none' for deviations.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 28 Jun 2015 10:11:15 +0200 (CEST)

> of X refer to just 1 revision of X?

I thought this was discussed and decided.  The idea being that in a
specific server, all import-without-revision of X refers to exactly
one revision of X.

> use any specific revision.

The text means that from a modelling perspective, the revision is not
fixed.  A server will of course use some revision.

> Are you proposing a new YANG 1.1 issue,

No.

> No --- the current RFC says that is not possible.

I don't think it does.  But more importantly, do you agree that the
server will use one revision of X?   If so, wouldn't it be good to
inform the client about which revision is used?

> The library narrows the choice from all revisions to 2 in this example.

Exactly.  This is the problem I thought we're trying to solve.

How about we introduce conformace=import-by-revision in addition to
conformace=import.  Then the above example would be

      module=X, revision=2014-01-01, conformance=import-by-revision
      module=X, revision=2015-06-01, conformance=import

>           is imported without a specific revision date.";

Yes this would also work, I think.

Or conformance import-by-revision/import or
import/import-default-revision.

> I would suggest conformance 'none' for deviations.

Sounds good.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 08:09:54 +0200

>       implement module "a" in some way.

Note that you can have two modules importing t without a revision and
the two modules may use different versions of t. If so, then it seems
the indexing we have is right since you may need to list multiple
revisions of t. If the requirement is to announce which version of t
has been used by module a, then it seems you need to kind of list the
imports with the revisions actually used in the data model, no?
 
> sufficient to solve the advertisement problem.

/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: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Jun 2015 10:44:49 +0200 (CEST)

Hi,

Here's a short summary, and then some questions for the WG.

The ietf-yang-library module is designed to serve two purposes:

  1.  A protocol-independent advertisement mechanism for YANG 1.1
      modules.

  2.  A list of the YANG modules stored in a server.

Q1.  Do you agree with these goals?

Q2.  Should this module be designed to work with both YANG 1.0 and
     YANG 1.1 servers - i.e., should it have yang-version 1.1 or not?

     If it should not be defined using YANG 1.1, why is this module
     special?

Q3.  Should the /modules/module list be designed to store both YANG
     1.0 and YANG 1.1 modules?

Q4.  Consider these modules, which both import foo without revision:

       module a { ... import foo; ... }
       module b { ... import foo; ... }

     Do we require a server that implements both a and b to use the
     same revision of foo?

     If the answer is yes, we need to indicate the default revision
     that the server uses in the model:

       container modules {
         ...
         list module {
           ...
           leaf default-revision {
             type boolean;
             default false;
             description
               "Indicates that this revision is used by the server if
                this module is imported without a specific revision
                date.";
           }
         }
       }

     If the answer is no, note that this puts an implementation burden
     on the client.  A client cannot simply download all listed
     modules, and load/compile/process them as one set.

     If the anwser is no, I propose that we extend the module as such:

       container modules {
         ...
         list module {
           ...
           list imported-without-revision {
             key "name revision";
             ...
           }
         }
       }

     A server could then list:

      <module>
        <name>a</name>
        <revision>2015-01-01</revision>
        <imported-without-revision>
          <name>foo</name>
          <revision>2002-02-02</revision>
        </imported-without-revision>
      </module>
      <module>
        <name>b</name>
        <revision>2015-01-01</revision>
        <imported-without-revision>
          <name>foo</name>
          <revision>2001-01-01</revision>
        </imported-without-revision>
      </module>

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Jun 2015 02:05:47 -0700

>      If it should not be defined using YANG 1.1, why is this module

What does 'special' mean here?
Can you identify a YANG 1.1 statement that this module needs?

>      1.0 and YANG 1.1 modules?
Do you have some reason why YANG 1.0 files should be excluded?

>            list imported-without-revision {
I do not think this change is needed

>         </imported-without-revision>
YANG 1.0 and current 1.1 says that if no revision-date is used,
then the client does not know the version and the
server is not required to pick any specific version.

Your proposal seems to be that the library will fill in all the
revision-dates
and reproduce the import-tree.  It makes more sense to make
import-by-revision mandatory.  But IMO this is not a real
problem so there is no point in this solution.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Jun 2015 11:16:48 +0200 (CEST)

> What does 'special' mean here?

Special in the sense that going forward, I assume all modules
published by the IETF will be YANG 1.1.

No.

> Do you have some reason why YANG 1.0 files should be excluded?

No, but if this module is supposed to be used for advertising 1.1
modules, why store 1.0 modules here?  Also, the description statements
will have to reflect the fact that some things don't apply to 1.0
modules (like conformance).

> and reproduce the import-tree.

Yes.

/martin

> It makes more sense to make

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 30 Jun 2015 11:56:02 +0200

>   2.  A list of the YANG modules stored in a server.

Is this used by "get-schema" or for something else?

> Q1.  Do you agree with these goals?

I think it should be only #1, if it is going to be the only way for
advertising YANG modules. A server may just implement the modules
without storing them. (But maybe I misunderstood the purpose of #2.)

>      If it should not be defined using YANG 1.1, why is this module

Hmm, it depends on what a 1.0 client is expected to do when encountering
1.1 modules. This is probably not specified in 6020bis. (?)

Yes.

>      If the anwser is no, I propose that we extend the module as such:

I'd vote for this option. A server implementor might need to use an old
revision of a grouping/typedef in one subsystem and a new revision in
another.

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Jun 2015 14:45:03 +0200

Writing as technical contributor...

> Q1.  Do you agree with these goals?

I primarily care about goal 1.
 
>      If it should not be defined using YANG 1.1, why is this module

I assume this module will sooner or later be YANG 1.1 anyway.
 
>      1.0 and YANG 1.1 modules?

Yes. Even if YANG 1.1 hits the street tomorrow, we will not have
revised all published YANG data models that were written using YANG
1.0. So a server needs to be able to announce both YANG 1.0 and YANG
1.1 modules.

>         </imported-without-revision>

I believe truth is advertisement is a good thing. In the SNMP world,
not all pieces of the instrumentation were moving at the same pace and
I would be somewhat surprised if this would be the case for all
implementations in the NETCONF world. Hence, I rather accept that an
import of foo without revision may resolve to different versions of
foo for different imports.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Jun 2015 14:46:13 +0200 (CEST)

> Is this used by "get-schema" or for something else?

Andy might be able to explain this requirement.

My personal view is that ietf-yang-library should do #1 only.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Jun 2015 07:16:29 -0700

> My personal view is that ietf-yang-library should do #1 only.
#2 is to support easy retrieval of all types of YANG files.
The types of YANG files can be identified (unlike the schema list)
so a subset of files can be retrieved if needed.  The 'schema'
list does not support submodules or deviation files.
No YANG file types can be identified with the 'schema' list.

It is useful to be able to retrieve the YANG files without having to parse
them
first.  This allows modular implementation.

The "schema" list is optional to implement so a client cannot
rely on it .  Only the YANG library is
mandatory to implement for RESTCONF and CoMI.

Since storage of the YANG files is expensive for constrained
devices, it is very useful to support a <get-schema> server
which contains all the YANG files for lots of device types.
(the conformance=none enumeration supports this mode)

There is no harm whatsoever in allowing multiple revisions from
appearing in the library.  I don't really understand why this
is a problem.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Jun 2015 11:10:35 -0700

> 1.0. So a server needs to be able to announce both YANG 1.0 and YANG

Yes -- We also agreed that we would not be republishing modules
just to change the yang-version to 1.1.

There are lots of YANG modules in progress at this time.
Perhaps 3 out of 100 are relying on YANG 1.1 statements.
It seems rather disruptive to declare all module must be YANG 1.1
since it has not even made it through WGLC yat, let alone
be published as an RFC, let alone be implemented
in real tool-chains.

I suspect if people find out the only think YANG 1.1 in their module
(preventing their existing tools from working) is a yang-version-stmt,
they might not be too happy.

Andy