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

So what is the proposal?  All implementations MUST allow arbitrary
strings, and implementations that map this to the SNMP object MUST be
careful...?

My original idea was that implementations should be free to either
restrict the values to match the DisplayString, or do some
implemenation-specific translation.  From -00:

              This leaf MAY be mapped to ifAlias by an implementation.
              Such an implementation MAY restrict the length of the
              value of this leaf so that it matches the restrictions
              of ifAlias.

But the WG decided that the current specified behavior was more
correct.



/martin