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

["Randy Presuhn" <[e-mail]>]

Hi -

> From: "Martin Bjorklund" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> Sent: Wednesday, December 11, 2013 11:52 PM
> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
> Randy Presuhn <[e-mail]> wrote:
> > Hi -
> > 
> > >From: Juergen Schoenwaelder <[e-mail]>
> > >Sent: Dec 11, 2013 12:38 AM
> > >To: Randy Presuhn <[e-mail]>
> > >Cc: [e-mail]
> > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > >
> > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > 
> > >> > 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.
> > >> 
> > >> Perhaps, though that is the route to being stuck with ASCII until the
> > >> successor to Netconf rolls along.
> > >
> > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > >days), you can use unicode characters. The code that maps names to
> > >legacy non-unicode interfaces then needs to do suitable translations
> > >to fit whatever constraint there is.
> > 
> > Not if the data definition restricts the values to an ASCII
> > subset, as has been proposed.  What's in the draft at the
> > moment will bring its own interoperability problems, but
> > at least it's a baby step forward.
> 
> So it seems we have a chance to fix this now.  But I need to
> understand what exactly you and/or Juergen propose.  Preferrably
> concrete text.  I *think* that the proposal is something like this:
> 
>    o  An implementation MUST allow any legal "string" (YANG string).

There are good reasons to restrict formatting and control characters -
I'll assume YANG strings do this already.  If not, that's another long
discussion.
 
>    o  An implementation that maps this value to the corresponding MIB
>       object, which has size and character set limitations, MUST use
>       some mechanism out of the scope for this document to ensure that
>       the MIB object syntax is still valid.

Yes this seems reasonable.

But it doesn't cover a "round trip".  If the value is modified via the MIB
interface to include what looks like the implementation-specific encoding
into ASCII of a non-ASCII Unicode code point, does retrieving that value
via the Netconf interface get the Unicode code point or the implementation-
specific ASCII encoding of it?  If it does (and I think it should) then there
needs to be some though put into what happens when the code point
encoded using ASCII would, if converted to Unicode, be illegal (for
whatever reason) in the YANG string.  It's probably best to keep the
SNMP instrumentation ignorant of all this, so code in the Netconf side
would need determine whether any of the ASCII "escape sequences"
would produce forbidden code points, and, in such cases, *not* evaluate
those sequences and just pass them through unevaluated.

 
> Also, just to make sure, we are talking about:
> 
>    system/location        -- sysLocation
>    system/contact         -- sysContact
>    interface/description  -- ifAlias

Perhaps also sysDescr (even though read-only, my comment above seems applicable,
particularly since on at least some systems this comes from a static configuration
file, and would be useful to support local language in some minimal way.)

sysName (think IDN) might also be worth thinking about.  There was a long debate
about this a while back; I don't know what current thinking is.

Randy