Hi Martin,
Thanks.
Only kept the relevant excerpts.
- 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.
Ah. So no good news in this case...
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".
Sure. It was mainly an observation.
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.
Talking as a contributor this time.
It seems that inventory management is kind of broken when someone can
change 'serial-num', 'mfg-name', and 'model-name. Now, an attacker who
could modify YANG objects can do way more damage that playing with
inventory management. "forwarding" in
https://tools.ietf.org/html/draft-ietf-netmod-rfc7277bis-01 comes to mind.
-
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."
This works.
Thanks, Benoit
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
