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

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Dec 10, 2013 at 10:55:28AM -0800, Randy Presuhn wrote:

> >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.
>
> To elaborate slightly: I like this idea as the basis for
> a standardized approach (*not* merely a "MAY") to be used
> whenever practical for migrating ASCII-only SNMP objects
> intended for human consumption.

I am sure we discussed this option back in a day and I am sure there
were people who said that an SNMP agent could store something that may
accidentally now might look like an escaped unicode sequence but it
was not intended to be one. And there might be interesting
interactions with the size (length) restriction. Such thinking will
force the conclusion that neither the HTML convention nor the \u
convention can be used. So the only alternative is to use one of the
25 ASCII code points as an escape character that per RFC 2579 have no
meaning in a DisplayString, e.g. ESC (ASCII code 0x1b). While this
approach avoids any conflicts, it leads to a very SNMP specific
solution, which is not commonly understood and needs special
processing by both machines and human brains. But then, SNMP would
only add a little bit more to the noise out there already:

http://billposer.org/Software/ListOfRepresentations.html

Anyway, for a standardized approach, someone would have to write a
document that defines how unicode code points are represented as
escaped charater sequences in DisplayStrings. I do not think that this
document is in charge of doing this. Hence, until such a standard is
written, I think things need to be implementation specific.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>