Subject: [netmod] length limits on system/name,contact,location

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Aug 2012 11:09:49 -0700

Hi,

>>
>> Can we raise this hard-wired arbitrary limit to 1023?
>
> You probably want to start a separate thread as this has nothing to do
> with GPS coordinates. I assume the 255 is inherited from MIB
> world. That said, if we consider changing this limit, then we should
> remote it rather than replacing it by another arbitrary limit, perhaps
> adding text similar to .../interface/name.
>

We should not allow these admin strings to have structure, like
the interface name leaf.

I thought of no limit, and let the server return a too-big error-tag
if it cannot hold the text:  Maybe that would be best.  e.,g.:

[remove length-stmt and reference-stmt]

  leaf name {
      type string;
      description
        "The administratively assigned system name.
         The server MUST support values from 0 to 255 characters in length,
         and MAY support larger values.";
    }

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Aug 2012 20:18:52 +0200

>          and MAY support larger values.";

This 255 limit seems arbitrarily new. In SNMP land, things are limited
to 255 ASCII characters (octets). This description would limit things
to 255 UTF-8 encoded characters, that can be very well more than 255
octets.

/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: Andy Bierman <[email-masked]>
Date: Thu, 9 Aug 2012 11:22:50 -0700

> to 255 UTF-8 encoded characters, that can be very well more than 255

How is that any different than the current text:

   leaf name {
       type string {
           length "0 .. 255";
       }
   }

This is the same, except the "MAY support larger values" part.
This says MUST NOT support larger values.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Aug 2012 20:56:36 +0200

> This says MUST NOT support larger values.

In both cases, 255 UTF-8 code points is not the same as 255 ASCII
characters.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Aug 2012 12:00:29 -0700

> In both cases, 255 UTF-8 code points is not the same as 255 ASCII

But the YANG length-stmt is in units of characters, not octets.

9.4.4.  The length Statement

   The "length" statement, which is an optional substatement to the
   "type" statement, takes as an argument a length expression string.
   It is used to restrict the built-in type "string", or types derived
   from "string".

   A "length" statement restricts the number of Unicode characters in
   the string.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Aug 2012 21:34:21 +0200

>    A "length" statement restricts the number of Unicode characters in

Exactly. 255 characters in YANG != 255 octets in SNMP DisplayStrings.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Aug 2012 12:46:06 -0700

> Exactly. 255 characters in YANG != 255 octets in SNMP DisplayStrings.

So.  It's been that way from the first version.
I removed the reference to the SNMP object.
This isn't SNMP and the characters are not limited to DisplayString.
I said 'characters', not 'octets'.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Aug 2012 21:51:28 +0200

> I said 'characters', not 'octets'.

So then we finally agree that this is a totally arbitrary limit.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Aug 2012 13:01:11 -0700

I suggested this leaf 3 emails ago:

   leaf name {
       type string;
      description

The client needs a min-limit which I picked arbitrarily to be 255.
But we can have no limits and leave it up to the servers to
implement something reasonable:

   leaf name {
       type string;
       description
         "The administratively assigned system name.";
   }

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 9 Aug 2012 19:24:25 -0400

>This says MUST NOT support larger values.

Isn't supporting longer lengths just a deviation?

Thanks,
 Phil

---

From: t.petch <[email-masked]>
Date: Fri, 10 Aug 2012 09:08:56 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 09, 2012 7:09 PM
> [remove length-stmt and reference-stmt]

I like having a limit, because of human behaviour when there isn't one.
Cobol was the first I encountered and the absurd names that people came
up with seriously impaired comprehension.  The problem is that people
want to encode everything including the kitchen sink into a label,
instead of recognising that it is a label and should be chosen to
provide a convenient index into more detailed information.

So, for me, 255 characters - not octets - is excessive, 63 is almost
always enough.  Think of writing it, transcribing it, saying it over the
phone to third level support ......

Tom Petch

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Aug 2012 02:27:31 -0700

Ok, so we will leave the current objects alone.  I see no consensus to change anything. 

Andy

Sent from my iPhone

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Aug 2012 12:45:02 +0200

> Ok, so we will leave the current objects alone.  I see no consensus

I think we were talking about these three objects:

       leaf contact {
         type string {
           length "0..255";
         }
         description
           "The administrator contact information for the system.";
         reference
           "RFC 3418 - Management Information Base (MIB) for the
                       Simple Network Management Protocol (SNMP)
                       SNMPv2-MIB.sysContact";
       }

       leaf name {
         type string {
           length "0..255";
         }
         description
           "The administratively assigned system name.";
         reference
           "RFC 3418 - Management Information Base (MIB) for the
                       Simple Network Management Protocol (SNMP)
                       SNMPv2-MIB.sysName";
       }

       leaf location {
         type string {
           length "0..255";
         }
         description
           "The system location";
         reference
           "RFC 3418 - Management Information Base (MIB) for the
                       Simple Network Management Protocol (SNMP)
                       SNMPv2-MIB.sysLocation";
       }

My point remains that this definition is potentially misleading since
sysContact, sysName, and sysLocation have a different character set
and a different length restriction. I think it is useful to be
explicit about such differences. In the interfaces YANG model, Martin
wrote text such as (replace XXXX with sysContact, sysName, or
sysLocation):

            This leaf MAY be mapped to XXXX by an implementation.
            Such an implementation MAY restrict the allowed values for
            this leaf so that it matches the restrictions of XXXX.
            If a NETCONF server that implements this restriction is
            sent a value that doesn't match the restriction, it MUST
            reply with an rpc-error with the error-tag
            'invalid-value'.

And in the interface model, Martin dropped the length restrictions
altogether. I think we should be consistent with this. I also note
that we do not impose length restrictions in other data models, e.g.
the NETCONF access control model (see user-name-type or
group-name-type).

/js (as contributor)

PS: If we would have explicit conformance statements, we could define
    a minimum length that implementations must support as part of the
    conformance definition instead of hardwiring this in the data
    model.

---

From: Phil Shafer <[email-masked]>
Date: Fri, 10 Aug 2012 13:36:48 -0400

>I like having a limit, because of human behaviour when there isn't one.

Yup, customers stuff all sorts of vital information into our description
strings.  With no limit, I can see someone expecting to use this as backing
store for their OSS system.

>phone to third level support ......

63 is likely too small, given the above comment.  I've seen customers
using descriptions with >128 bytes in the wild.

Thanks,
 Phil

---

From: Xiang Li <[email-masked]>
Date: Fri, 10 Aug 2012 13:15:31 -0500

> provide a convenient index into more detailed information.

For a standard model, I also prefer to having a limit, be it 255 or some 
other
appropriate length. I feel it might defeat the purpose for a standard 
model if we
let each server implementation to determine the length to support.

I think it may be misused if there is no limit and is arguably "harder" to
implement.

--Xiang Li

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Aug 2012 11:34:05 -0700

On Fri, Aug 10, 2012 at 11:15 AM, Xiang Li <[email-masked]> wrote:
> appropriate length. I feel it might defeat the purpose for a standard model
> if we

This is what I proposed:

 leaf name {
      type string;
      description

Apparently YANG writers skip the description-stmts and they don't
seem to count as normative behavior.

The length-stmt says the "the server MUST support this range of
value lengths and only this range".  The above text requires
the same range of value lengths be supported, but allowed larger
strings without the server deviating from the standard.

The proper way to deal with conformance issues is with a real
conformance model.  NETCONF/YANG has a simplistic
conformance model, so we have no concept of this, or
machine-readable stmts to deal with "server MUST support this
minimum functionality, and MAY support more functionality."
We should never be defining any administrative fields with arbitrary
upper limits built into the definition.

Andy

>>>           The server MUST support values from 0 to 255 characters in
>>
>> length,
>>>