Andy Bierman
2017-11-13 21:41:24 UTC
Hi,
Here are some comments on SID draft:
- The SID design does not support augment correctly.
It is not mentioned at all in the draft.
The "label" leaf design does not allow for YANG identifier
names from other modules. There is also no need to
overload the label field with extra semantics about
the data type. This actually breaks the SID mapping
since "label" is part of the key. (It needs a simple
and canonical representation.)
Example of SID broken for augment:
module A {
...
container top {
leaf leaf1 { type string; }
}
}
module B {
import A { prefix A; }
...
augment /A:top {
leaf leaf1 { type int32; }
}
container top;
}
- the module revision date is always 2015-12-16.
The revision date is supposed to match the I-D revision date
so YANG compilers can tell the different versions apart
- typedef yang-identifier
do not clone this type. Use the real yang-identifier in
ietf-yang-types (RFC 6991(
- The 'mandatory true' statements are redundant for key leafs
and should be removed (for key leafs only)
- leaf 'type' needs to be an enumeration, not a string with patterns
to do the same thing as an enumeration. This field needs to be
a simple identifier, not a union of complex patterns.
This type is not defined correctly. It needs to identify the
YANG identifier namespace type, as defined in RFC 7950, sec. 6.2.1
Modules and submodules are in the same namespace.
They are not separate things as defined in the SID draft.
The following "yang-ns-id" typedef definition shows the
full namespace, and "sid-ns-id" shows the subset relevant to CoMI.
The leafs "type" and "label" fix the problems with the
current design and allow the "label" field to support augment-stmt.
The only allowed form is also the canonical form, allowing the
{ type, label } tuples to be easily and correctly compared.
typedef yang-ns-id {
type enumeration {
enum module {
description
"All module and submodule names share the same
global module identifier namespace.";
}
enum extension {
description
"All extension names defined in a module and its
submodules share the same extension identifier
namespace.";
}
enum feature {
description
"All feature names defined in a module and its
submodules share the same feature identifier
namespace.";
}
enum identity {
description
"All identity names defined in a module and its
submodules share the same identity identifier
namespace.";
}
enum type {
description
"The namespace for all derived type names, as
defined in YANG.";
}
enum grouping {
description
"The namespace for all grouping names, as defined
in YANG.";
}
enum data {
description
"The namespace for all data nodes, as defined in YANG.";
}
enum case {
description
"All cases within a choice share the same case
identifier namespace. This namespace is scoped
to the parent choice node.";
}
}
description
"A YANG namespace identifier specifies the identifier
namespace within a YANG module and its submodules.
An identifier is only required to be unique within
a specific namespace.";
reference
"RFC 7950, The YANG 1.1 Data Modeling Language;
Section 6.2.1: Identifiers and Their Namespaces.";
}
typedef sid-ns-id {
type yang-ns-id {
enum module {
description
"All module and submodule names share the same
global module identifier namespace.";
}
enum feature {
description
"All feature names defined in a module and its
submodules share the same feature identifier
namespace.";
}
enum identity {
description
"All identity names defined in a module and its
submodules share the same identity identifier
namespace.";
}
enum data {
description
"The namespace for all data nodes, as defined in YANG.";
}
}
description
"A SID namespace identifier specifies the identifier
namespace within a YANG module and its submodules,
as used within the a SID registry mapping.";
}
typedef sid-path {
type string;
description
"Identifies a schema-node path string for use in the
SID registry. This string format follows the rules
for an instance-identifier, as defined in RFC 7959,
except that no predicates are allowed.
This format is intended to support the YANG 1.1 ABNF
for a schema node identifier, except module names
are used instead of prefixes, as specified in RFC 7951.";
reference
"RFC 7950, The YANG 1.1 Data Modeling Language;
Section 6.5: Schema Node Identifier;
RFC 7951, JSON Encoding of YANG Data;
Section 6.11: The instance-identifier type";
}
leaf type {
type sid-ns-id;
description
"The SID namespace Identifier type for this entry";
}
leaf label {
type union {
type sid-path;
type yang:yang-identifier;
}
description
"The label identifying this mapping entry.
If the corresponding 'type' field is 'module',
'feature', or 'identity', then this field MUST
contain a valid yang-identifier string.
If the corresponding 'type' field is 'data',
then this field MUST contain a valid sid-path string.";
}
Example for module A and B:
module A:
module, "A", 1700
data, "/A:top", 1701
data, "/A:top/leaf1", 1702
module B:
module, "B", 2700
data, "/A:top/B:leaf1", 2701
data, "/B:top", 2702
Andy
Here are some comments on SID draft:
- The SID design does not support augment correctly.
It is not mentioned at all in the draft.
The "label" leaf design does not allow for YANG identifier
names from other modules. There is also no need to
overload the label field with extra semantics about
the data type. This actually breaks the SID mapping
since "label" is part of the key. (It needs a simple
and canonical representation.)
Example of SID broken for augment:
module A {
...
container top {
leaf leaf1 { type string; }
}
}
module B {
import A { prefix A; }
...
augment /A:top {
leaf leaf1 { type int32; }
}
container top;
}
- the module revision date is always 2015-12-16.
The revision date is supposed to match the I-D revision date
so YANG compilers can tell the different versions apart
- typedef yang-identifier
do not clone this type. Use the real yang-identifier in
ietf-yang-types (RFC 6991(
- The 'mandatory true' statements are redundant for key leafs
and should be removed (for key leafs only)
- leaf 'type' needs to be an enumeration, not a string with patterns
to do the same thing as an enumeration. This field needs to be
a simple identifier, not a union of complex patterns.
This type is not defined correctly. It needs to identify the
YANG identifier namespace type, as defined in RFC 7950, sec. 6.2.1
Modules and submodules are in the same namespace.
They are not separate things as defined in the SID draft.
The following "yang-ns-id" typedef definition shows the
full namespace, and "sid-ns-id" shows the subset relevant to CoMI.
The leafs "type" and "label" fix the problems with the
current design and allow the "label" field to support augment-stmt.
The only allowed form is also the canonical form, allowing the
{ type, label } tuples to be easily and correctly compared.
typedef yang-ns-id {
type enumeration {
enum module {
description
"All module and submodule names share the same
global module identifier namespace.";
}
enum extension {
description
"All extension names defined in a module and its
submodules share the same extension identifier
namespace.";
}
enum feature {
description
"All feature names defined in a module and its
submodules share the same feature identifier
namespace.";
}
enum identity {
description
"All identity names defined in a module and its
submodules share the same identity identifier
namespace.";
}
enum type {
description
"The namespace for all derived type names, as
defined in YANG.";
}
enum grouping {
description
"The namespace for all grouping names, as defined
in YANG.";
}
enum data {
description
"The namespace for all data nodes, as defined in YANG.";
}
enum case {
description
"All cases within a choice share the same case
identifier namespace. This namespace is scoped
to the parent choice node.";
}
}
description
"A YANG namespace identifier specifies the identifier
namespace within a YANG module and its submodules.
An identifier is only required to be unique within
a specific namespace.";
reference
"RFC 7950, The YANG 1.1 Data Modeling Language;
Section 6.2.1: Identifiers and Their Namespaces.";
}
typedef sid-ns-id {
type yang-ns-id {
enum module {
description
"All module and submodule names share the same
global module identifier namespace.";
}
enum feature {
description
"All feature names defined in a module and its
submodules share the same feature identifier
namespace.";
}
enum identity {
description
"All identity names defined in a module and its
submodules share the same identity identifier
namespace.";
}
enum data {
description
"The namespace for all data nodes, as defined in YANG.";
}
}
description
"A SID namespace identifier specifies the identifier
namespace within a YANG module and its submodules,
as used within the a SID registry mapping.";
}
typedef sid-path {
type string;
description
"Identifies a schema-node path string for use in the
SID registry. This string format follows the rules
for an instance-identifier, as defined in RFC 7959,
except that no predicates are allowed.
This format is intended to support the YANG 1.1 ABNF
for a schema node identifier, except module names
are used instead of prefixes, as specified in RFC 7951.";
reference
"RFC 7950, The YANG 1.1 Data Modeling Language;
Section 6.5: Schema Node Identifier;
RFC 7951, JSON Encoding of YANG Data;
Section 6.11: The instance-identifier type";
}
leaf type {
type sid-ns-id;
description
"The SID namespace Identifier type for this entry";
}
leaf label {
type union {
type sid-path;
type yang:yang-identifier;
}
description
"The label identifying this mapping entry.
If the corresponding 'type' field is 'module',
'feature', or 'identity', then this field MUST
contain a valid yang-identifier string.
If the corresponding 'type' field is 'data',
then this field MUST contain a valid sid-path string.";
}
Example for module A and B:
module A:
module, "A", 1700
data, "/A:top", 1701
data, "/A:top/leaf1", 1702
module B:
module, "B", 2700
data, "/A:top/B:leaf1", 2701
data, "/B:top", 2702
Andy