Dear all,
Here is my AD review of draft-ietf-netmod-entity-06.
Note that if you post the new version soon (before the end of this
week), I could start the IETF last call, and the draft could be on Jan
11th IESG telechat.
- I don't believe that the RFC 2119 keywords are right on the following
sentences (SHOULD => should):
o The hardware data model SHOULD be suitable for new implementations
to use as is.
o The hardware data model defined in this document can be
implemented on a system that also implements ENTITY-MIB, thus the
mapping between the hardware data model and ENTITY-MIB SHOULD be
clear.
-
1.2. Tree Diagrams
Tree diagrams used in this document follow the notation defined in
[I-D.ietf-netmod-yang-tree-diagrams
<https://tools.ietf.org/html/draft-ietf-netmod-entity-06#ref-I-D.ietf-netmod-yang-tree-diagrams>].
You could remove the above and add the reference to section 3.
This document defines the YANG module "ietf-hardware", which has the
following structure [I-D.ietf-netmod-yang-tree-diagrams
<https://tools.ietf.org/html/draft-ietf-netmod-entity-06#ref-I-D.ietf-netmod-yang-tree-diagrams>]:
Martin, be consistent with all your YANG modules. So keep your temp
versions of RFC7223bis and RFC7277bis consistent as well.
- Some objects are read-write in RFC6933:
entPhysicalSerialNum
entPhysicalAlias
entPhysicalAssetID
entPhysicalUris
For example, entPhysicalSerialNum being read-write always bothered me.
serial-num is now "config false", which is a good news IMO.
In the reverse direction, entPhysicalMfgName is read-only in RFC6933, while it's
"config true" in draft-ietf-netmod-entity
You should mention these ro/rw differences with RFC6933.
There might be other differences.
-
UUIDorZero
entPhysicalUUID OBJECT-TYPE
SYNTAX UUIDorZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains identification information
about the physical entity. The object contains a
Universally Unique Identifier, the syntax of this object
must conform toRFC 4122, Section 4.1
<https://tools.ietf.org/html/rfc4122#section-4.1>.
A zero-length octet string is returned if no UUID
information is known."
The YANG module is:
leaf uuid {
type yang:uuid;
config false;
description
"A Universally Unique Identifier of the component.";
reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>:
entPhysicalUUID";
}
Where:
typedef uuid {
type string {
pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
+ '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
}
description
"A Universally Unique IDentifier in the string representation
defined in RFC 4122. The canonical representation uses
lowercase characters.
The following is an example of a UUID in string representation:
f81d4fae-7dec-11d0-a765-00a0c91e6bf6
";
reference
"RFC 4122: A Universally Unique IDentifier (UUID) URN
Namespace";
}
Again a difference between the MIB and YANG module to mention in the document?
Regards, Benoit (as OPS AD)
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
