Subject: [netmod] draft-ietf-netmod-entity issue #11

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Dec 2016 16:01:10 +0100 (CET)

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Dec 2016 16:21:31 +0100

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:
> _______________________________________________
> netmod mailing list
> [email-masked]
> 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/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Dec 2016 16:31:10 +0100 (CET)

> using features. So I propose to do nothing about entity4CRCompliance.

Ok.

> report those objects in the YANG world.

I agree.

> If so, I am not sure whether
> values lead to zero-length string or other special values.

I think this "depature" is fine.

> (The

The MIB says that the object is set to a zero-length string OR a
locally unique value.  After this a manager can change this value.  So
I believe this semantics is reflected in the YANG model (esp. if we
make it clear that a zero-length string in the MIB maps to a
non-existing node in YANG).

> the SMIv2 ENTITY-MIB rules.

Hmm, this cannot easily be done with a YANG feature, but maybe we can
simply change these strings to unrestricted strings, and then state
that a server MAY impose additional restrictions on valid values?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Dec 2016 16:47:35 +0100

> that a server MAY impose additional restrictions on valid values?

Yes, I would go towards less restrictions in general with a caveat
that systems implementing a direct mapping to the ENTITY-MIB MAY
impose additional length restrictions on valid values.

/js

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 15 Dec 2016 13:58:44 -0800

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".

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Dec 2016 09:53:02 +0100 (CET)

> to permit a clear distinction between "information not available"

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

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 16 Dec 2016 11:54:28 -0800

Hi -

> types have a natural value for "not available".

Just providing background.  I don't know whether the distinction is
needed in netconf-managed environments.

> to avoid "holes" in the tables; I don't know if that applied to this

I think the fear of holes belongs in the "folklore" category.

Due to the way access control works in SNMP, holes in tables
are always a possibility when retrieving information.  Employing
sentinel values can't change that reality.  However, for some
objects (by no means all) the distinction between "I don't know"
and "I won't tell you" was important to SNMP-based management.
Whether this is also true in netconf-land is a another question.

Randy