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

From: Randy Presuhn <[email-masked]>
Date: Fri, 13 Dec 2013 14:00:00 -0800 (GMT-08:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Dec 13, 2013 11:58 AM
>To: Randy Presuhn <[email-masked]>
>Cc: Martin Björklund <[email-masked]>, [email-masked]
>Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>
>On 13 Dec 2013, at 20:34, Randy Presuhn <[email-masked]> wrote:
>
>> Hi -
>> 
>>> From: Martin Bjorklund <[email-masked]>
>>> Sent: Dec 12, 2013 11:22 PM
>>> To: [email-masked]
>>> Cc: [email-masked]
>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>>> 
>>> Randy Presuhn <[email-masked]> wrote:
>>>> Hi -
>>>> 
>>>>> From: Juergen Schoenwaelder <[email-masked]>
>>>>> Sent: Dec 12, 2013 3:52 AM
>>>>> To: Randy Presuhn <[email-masked]>, [email-masked]
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>>>>> 
>>>>> 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.
>>>> 
>>>> Very odd.  It restricts the C0 controls, but permits the C1
>>>> control codes?  I hope someone thought that through carefully.
>>> 
>>> It is what XML Schema 1.0 says is a string.  See
>>> http://www.w3.org/TR/xmlschema-2/#string and the reference to
>>> http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Char
>> 
>> Let me be more direct.  To exclude, for example,
>> VT (vertical tab) but at the same time to include
>> RI (reverse line feed) in the set of permitted
>> characters seems ill-advised, to say the least.
>
>That was the (somewhat arbitrary) decision taken for XML 1.0.
>And since it is the serialization format for NETCONF, it was
>quite logical to adopt it for YANG, too.

This has nothing to do with serialization.  This is
a question of which code points are permitted within
strings intended for human consumption.

>> I hope the rationale for including the C1 controls
>> (%x80-9F) while quite correctly severely limiting
>> the C0 controls is documented somewhere.
>
>Note that XML 1.1 allows #x1..#x1f, represented as
>character references.
...

That's beside the point.  Permitting a reverse line feed
(or any of the other C1 controls) in sysContact, while
prohibiting a vertical tab, makes no sense at all.  See
http://en.wikipedia.org/wiki/C0_and_C1_control_codes#C1_set
for an overview of this rogues' gallery of characters,
and consider whether it's really a good idea to permit
them for use in labeling interfaces, etc.

Note that we took a somewhat different course in defining
SnmpAdminString in RFC 3411, and this results in a technical
incompatibility.  RFC 3411 addresses the issue of C0 and C1
with a mere recommendation: "The use of control codes should
be avoided."  What this means is that it is perfectly legal,
though operationally not recommended, for a MIB object with
syntax SnmpAdminString (not further constrained by the object-
type's description) to contain code points *prohibited*
by the RFC 6020 string type.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 14 Dec 2013 11:17:16 +0100

Randy Presuhn <[email-masked]> writes:

...

> strings intended for human consumption.

So you are advocating a more restricted string type, rather than more liberal, right? That wasn't clear to me. In this case I tend to agree. It should be possible to find a subset of UCS that satisfies all thinkable needs of network management and yet avoids the dark alleys of Unicode and possible pitfalls for interoperability.

Judging from another ongoing discussion in the JSON WG, it was a very good decision to remove floating-point numbers from YANG.

Lada
 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C