Hi, Benoit Claise <[email protected]> wrote: > 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.
You are right, fixed. > 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. I guess, but having it in the introduction seems consistent with the other documents. > 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. Of course, I try to be consistent. > So keep your temp > versions of RFC7223bis and RFC7277bis consistent as well. It would help if you pointed out the inconsistencies you found. > - 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. Actually, this was not the intention. In draft-ietf-netmod-entity-03 this is configurable. I missed this in the conversion to NMDA. > In the reverse direction, entPhysicalMfgName is read-only in RFC6933, > while it's "config true" in draft-ietf-netmod-entity Yes, this was added per request from the WG. See e.g. the thread "draft-ietf-netmod-entity issue #13". However, I think that what we have now is probably not correct. I think that all nodes 'serial-num', 'mfg-name', and 'model-name' should be config true, and the description of list 'component' updated to reflect that all these tree leafs are handled the same way. I would like to know what the WG thinks about this. > You should mention these ro/rw differences with RFC6933. Ok. > 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? I can add, in the description of leaf "uuid": "If no UUID information is known for this component, this leaf is not instantiated." /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
