I do not think the goal should be to emulate SMIv2 compliance levels using features. So I propose to do nothing about entity4CRCompliance.
The other question (which should perhaps have been a separate issue) is whether non-existing values are indicated by zero-length strings or non-existing objects. I think in general we prefer to simply not report those objects in the YANG world. If so, I am not sure whether the goal to not depart too much from the ENTITY-MIB overrules this. Note that there are a couple of objects where non-existing values lead to zero-length string or other special values. (The 'alias' description is kind of interesting - the server may set the value of this node to a locally unique value; entPhysicalAlias says something different, namely On the first instantiation ... is set to the zero-length string.) Looking at the YANG fragment, I am also not sure how useful it is to carry the 32 'something' restriction forward. Note that 32 means unicode characters in YANG but space of the UTF-8 encoding of characters for SMIv2 (since it all ends up being a restriction for the OCTET STRING). Perhaps this deserves a feature, namely, whether an implementation supports flexible names or restricts names according to the SMIv2 ENTITY-MIB rules. /js On Thu, Dec 15, 2016 at 04:01:10PM +0100, Martin Bjorklund wrote: > Hi, > > Issue https://github.com/netmod-wg/entity/issues/11 > > RFC 6933 introduced a new compliance level for constrained resources > - entity4CRCompliance. Do we need a corresponding feature? > > In YANG, we cannot to the equivalent of compliance levels, so we would > need to mark all nodes with some optional feature, except the few > nodes that a constrained device would implement. > > OTOH, most nodes are already optional and config false. So a > constrained server that doesn't know the serial number for example > could just no return it. There is one catch though; the current text, > copied from the MIB, says e.g.: > > If the manufacturer name string associated with the > physical component is unknown to the server, then this > node will contain a zero-length string. > > Maybe we should change this so that the object isn't returned at all > instead of returning a zero-length string. > > > > /martin > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
