Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt

From: Randy Presuhn <[email-masked]>
Date: Mon, 9 Dec 2013 11:40:41 -0800 (GMT-08:00)

Hi -

>From: Benoit Claise <[email-masked]>
>Sent: Dec 9, 2013 8:11 AM
>To: NETMOD Working Group <[email-masked]>
>Subject: [netmod] AD review of draft-ietf-netmod-system-mgmt
...
>I understand the MIB variables don't map 1:1, but telling that
>             os-name        part of the sysDescr MIB variable
>             os-release     part of the sysDescr MIB variable
>             os-version     part of the sysDescr MIB variable
>             machine?       part of the sysDescr MIB variable
>... is also useful info.

Kinda sorta.  One *might* find os-name, os-release, and os-version
in sysDescr, but their presence is only a "should", and cannot be
relied upon.  Same goes for "machine" if one treats that as "hardware
type".

...
>NEW:
>   leaf location {
>          type string;
>          description
>            "The system location. In most cases, the "location" of an "interface" entry

This text is broken.  The "location" is *not* the location of an interface;
it is the location of the system.

>            is mapped to sysLocation. sysLocation is defined as a DisplayString [RFC2579]
>            which uses a 7-bit ASCII character set. An implementation that performs this
>            mapping MUST restrict the allowed values for "location" to match the
>            restrictions of sysLocation.";

I understand why folks might do this, but it still gives
me heartburn.  I believe it was a mistake when we failed
to extend the syntax of these MIB objects to permit
Unicode, and I believe it's a mistake to perpetuate the
limitation here. I recognize that this is a messy problem,
but surely we can do better than this, even if it's as
simple a hack as having "location" and "legacy-location".

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Dec 2013 13:23:30 +0100 (CET)

> simple a hack as having "location" and "legacy-location".

I don't think it makes much sense to have two such similar objects in
this data model.

One option would be to simply remove the connection between
sysLocation and this new location leaf (and same for contact),
essentially making the snmp object the "legacy" object.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Dec 2013 13:50:41 +0100

> essentially making the snmp object the "legacy" object.

Another option is to turn the logic around. That is, if there is a
non-ASCII character in the YANG object, the mapping to the
corresponding MIB object must take precautions to comply with the MIB
restrictions (e.g., representing the non-ASCII character using \u and
\U escape sequences). The mapping to the MIB object would also have to
do proper truncations. The details of the mapping I assume would be
implementation specific.

This approach allows us to move to a unicode-based world rather than
carrying old ASCII restrictions forward endlessly (which is what I
think Randy is concerned about).

/js

-- 
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: Tue, 10 Dec 2013 19:22:14 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> > > >            mapping MUST restrict the allowed values for "location" to
> > > >            match
> > > >            the

An implementation MUST NOT restrict?  Note that the current text
simply says MAY restrict.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 Dec 2013 17:26:12 +0100

Randy,
> relied upon.  Same goes for "machine" if one treats that as "hardware
Ack. That should be mentioned then.

Regards, Benoit
> .