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

[Martin Bjorklund <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> wrote:
> On Tue, Dec 10, 2013 at 01:23:30PM +0100, Martin Bjorklund wrote:
> > Randy Presuhn <[e-mail]> wrote:
> > > Hi -
> > > 
> > > >From: Benoit Claise <[e-mail]>
> > > >
> > > >            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".
> > 
> > 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.
> 
> 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.

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

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


/martin