Randy Presuhn <[email protected]> wrote: > Hi - > > My recollection is that part of the motivation for the use of > zero-length strings as sentinel values in situations like this > in MIB modules (rather than skipping the object instance) was > to permit a clear distinction between "information not available" > and "access denied".
Ok. But if this is an important use case, maybe we should try to have generic support for it, instead of using special values. Not all types have a natural value for "not available". I think that people often used these kinds of constructs in MIBs to avoid "holes" in the tables; I don't know if that applied to this MIB though. /martin > > Randy > > On 12/15/2016 7:21 AM, Juergen Schoenwaelder wrote: > > 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 > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
