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

[Randy Presuhn <[e-mail]>]

Hi -

>From: Juergen Schoenwaelder <[e-mail]>
>Sent: Dec 10, 2013 4:50 AM
>To: Martin Bjorklund <[e-mail]>
>Cc: [e-mail], [e-mail]
>Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>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.
>
>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).

I really like this idea, though I'm not sure which of the various
ways of doing escape sequences would be most helpful.  For example,
the &#mumble; convention of HTML would also be a possibility.  But
whatever the mechanism, I think something like this would be a huge
win.  (Note that there are obnoxious corner cases, such as the SNMP
interface being used to configure an sequence which would, if interpreted
as an escape, result in a forbidden or impossible code point.)  Still,
I really like this idea.

Randy