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

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Dec 12, 2013 at 12:42:57AM -0800, Randy Presuhn wrote:
>
> >    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.

RFC 6020 says:

   The string built-in type represents human-readable strings in YANG.
   Legal characters are tab, carriage return, line feed, and the legal
   characters of Unicode and ISO/IEC 10646 [ISO.10646]:

     ;; any Unicode character, excluding the surrogate blocks,
     ;; FFFE, and FFFF.
     string = *char
     char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
            %x10000-10FFFF

And so far, we have used these strings without further restrictions in
data models when there was something to be named.
  
> >    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.

It might not be the job of these documents to engineer a round-trip
solution if one is required.
 
> 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.

sysName is defined like this:

            "An administratively-assigned name for this managed
            node.  By convention, this is the node's fully-qualified
            domain name.  If the name is unknown, the value is
            the zero-length string."

Since it is a DisplayString, sysName can represent IDNs only in their
ASCII representation. The .../system/hostname leaf in the system data
model is of type inet:domain-name and RFC 6991 says in the description
of domain-name:

         Domain-name values use the US-ASCII encoding.  Their canonical
         format uses lowercase US-ASCII characters.  Internationalized
         domain names MUST be A-labels as per RFC 5890.

This lines up - you can of course argue whether this is what operators
will prefer to have in their config files since it is not cut'n'paste
friendly.

/js

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