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

From: Randy Presuhn <[email-masked]>
Date: Tue, 10 Dec 2013 10:55:28 -0800 (GMT-08:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Dec 10, 2013 4:50 AM
>To: Martin Bjorklund <[email-masked]>
>Cc: [email-masked], [email-masked]
>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 <[email-masked]> wrote:
>> > Hi -
>> > 
>> > >From: Benoit Claise <[email-masked]>
>> > >
>> > >            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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Dec 2013 20:57:45 +0100

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

> 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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 Dec 2013 13:18:10 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "Martin Bjorklund" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, December 10, 2013 11:57 AM

...
> meaning in a DisplayString, e.g. ESC (ASCII code 0x1b).

Nope.  The escaped sequence is still longer, so the length-based
rationale doesn't work.

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

Whatever is easy, if not trivial to support with the scripting tools used by
operators would probably the best bet.  A C-like \u or HTML-like
&# convention is probably a really good bet.  I think the HTML escapes
might be less dangerous than the C-like ones (considering exotic formatting
capabilities), but am not married to one or the other.

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

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Dec 2013 22:24:45 +0100 (CET)

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Dec 2013 09:38:39 +0100

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

If someone configures via legacy non-unicode interfaces, well then
there is no unicode in the configured names. I do not think we can fix
that problem. This requires to change the legacy non-unicode
interfaces, which I think is not the task of this WG.

/js

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 Dec 2013 17:30:03 +0100

Dear all,
> to fit whatever constraint there is.
If the WG is fine with this proposal, fine with me.  You should adapt 
the proposal then.
For consistency reasons, that principle should be applied to 
description/ifAlias in draft-ietf-netmod-interfaces-cfg.
This could be considered as IETF LC comment, I guess.

> interfaces, which I think is not the task of this WG.
Agreed.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Dec 2013 21:27:58 +0100

> But the WG decided that the current specified behavior was more

This text only talks about length restrictions, not about character
set differences. I have to re-read the mailing list archive to see
what exactly happened.

As a technical contributor, I think we look kind of foolish if we
restrict unicode usage due to some legacy interfaces.  The guideline
"Use 7-bit ASCII because of some protocols designed in the late 80s."
can't be the long term answer to internationalization. OSes really
have moved on. I can put fancy characters into my interface name on
Linux. The kernel does not care and the tools do work well with it.

/js (speaking as a technical contributor)