Hi,
Andy Bierman <[email protected]> wrote:
> 1.1
>
> It does not mention:
> - multiple import-stmt for the same module now allowed
> - description-stmt and reference-stmt now allowed in
> import-stmt and include-stmt
>
> (There are no examples of any of the above changes)
Ok, fixed, including one example of a reference:
import ietf-yang-types {
prefix "yang";
reference "RFC 6991: Common YANG Data Types";
}
> 5.1:
>
> o A module MUST include all its submodules.
>
>
> This is not 100% correct.
> A module MUST include one revision of all its submodules.
> This includes a submodule with all obsolete definitions I guess.
I don't understand what you mean. Do you have a concrete proposal?
> 7.1.6
>
> It does not say what happens if a nested submodule includes-by-revision
> a different revision that the parent module.
>
> Multiple revisions of the same submodule MUST NOT be included.
>
>
> It is not clear that this applies to all include-stmt for the same module
>
>
> module A {
> include A1 {
> revision-date 2016-01-01;
> }
> include A2;
> include A3;
> }
>
> submodule A1 { ... }
>
> submodule A2 {
> include A1; // which revision is included if no date? conflict w/
> module?
> }
>
> submodule A3 {
> include A1 {
> revision-date 2015-01-01; // this is an error, right?
> }
> }
I suggest:
OLD:
For backward compatibility with YANG version 1, a submodule is
allowed to use the "include" statement to reference other submodules
within its module, but this is not necessary in YANG version 1.1. A
submodule can reference any definition in the module it belongs to
and in all submodules included by the module.
NEW:
For backward compatibility with YANG version 1, a submodule is
allowed to use the "include" statement to reference other submodules
within its module, but this is not necessary in YANG version 1.1. A
submodule can reference any definition in the module it belongs to
and in all submodules included by the module. A submodule MUST NOT
include different revisions of other submodules than the revisions
that its module includes.
> 9.12
>
> It doesn't say what happens when a union containing a leafref
> or instance-identifier becomes invalid or changes member types.
> Is this just a server implementation detail? Is should at least be clear
> a valid union leaf/leaf-list applies to a valid datastore
> (e.g. running, not candidate).
How this is handled internally is an implementation detail. But if
you have a union between a leafref to a string leaf and an int32, and
the referenced string doesn't exist, the config is invalid. However,
if you have a union between a leafref to a string and a string, and
the referenced string doesn't exist, the config is valid (since the
value matches the next type in the union).
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
