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

2016-12-16 Thread Randy Presuhn 

Hi -

On 12/16/2016 12:53 AM, Martin Bjorklund wrote:

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


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


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.


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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2016-12-16 Thread Martin Bjorklund 
Randy Presuhn  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
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2016-12-15 Thread Randy Presuhn 

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

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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2016-12-15 Thread Juergen Schoenwaelder 
On Thu, Dec 15, 2016 at 04:31:10PM +0100, Martin Bjorklund wrote:
 
> > 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.
> 
> 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?

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2016-12-15 Thread Martin Bjorklund 
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.

Ok.

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

I agree.

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

I think this "depature" is fine.

> (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.)

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

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

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


> /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
> > netmod@ietf.org
> > 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 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2016-12-15 Thread Juergen Schoenwaelder 
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
> netmod@ietf.org
> 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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2016-12-15 Thread Martin Bjorklund 
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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod