Subject: [netmod] identifier length

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Mar 2009 13:03:19 -0700

Hi,

Re the identifier length issue raised in the NETMOD WG meeting
yesterday:

yang-04, sec 6.2, para 1, sentence 3:

OLD:

    Implementations MUST support identifiers up to 63 characters in
    length.

NEW:

    Identifiers MUST be between 1 and 63 characters in length.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 27 Mar 2009 09:06:28 -0400

>    Identifiers MUST be between 1 and 63 characters in length.

I see no value in this restriction, given that:

(a) xml does not limit element names to 63 characters
(b) "characters" in a utf world are distorted (for example, multiple
    ways to make the same utf-8 content)
(c) memory impacts are minimal; current memory debates are over MBs, not Bs
(d) identifier lengths are self-regulating; a module with 128 byte element
    names will not be accepted by any sane community of users
(e) even 63 is mostly unreadable; a module with names that eat more than, say,
    half your screen width will be unacceptable
(f) YANG identifiers are scoped by their parents, so you don't
    need to encode the path in names like "ospfNbrAddressLessIndex";
    this removes them motivation/need to make butt-ugly long names
(g) if one really really needs 64 characters, having to use an abbreviation
    because of a YANG CLR would be irritating, especially if you are
    using the vocabulary from another standard.  We should avoid making
    people use identifiers in yang modules that are different from the terms
    used in such standards.
(h) no one likes CLRs

Long names aren't a problem for YANG.  Limiting them is unnecessary.
I would propose complete removal of the 63 character limit.  It
lets us avoid this issue and other related ones (like "what does
'characters' mean?  Is 63 before or after utf-8 encoding?  Does the
style of encoding (combine .vs. non-combine) impact this?  Do we
have enough utf-8 expertise to say?").  IMHO it's an issue that's
not worth fretting over.  It will be self-clocking, since no one
will like using modules with long names.  Drop the limit completely.
Or make it an authoring guideline:  "Be aware that no one likes
modules with long identifiers.  Or prefixes.  Or ones that are
overly deep.  Or ...."

FWIW:  The longest (by far) identifier in JUNOS is 45:

    maximum-initial-router-advertisement-interval

Thanks,
 Phil  (who never made an identifier longer that 20 characters)

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Mar 2009 07:53:20 -0700

> Long names aren't a problem for YANG.  Limiting them is unnecessary.

I do not understand your inconsistent application of this argument
whenever it suites your implementation preference.

When it comes to forcing every single YANG modeler
to use shallow keys instead of deep keys,
and force every NETCONF tool to reorder the list keys
so they are first -- just so your implementation
does not have to buffer any of the incoming PDU --
then saving a few bytes of memory in the agent is critical.

But when it comes to identifiers, the agent is expected
to handle infinitely long strings, and just 'make sure'
they are unique in the first 63 chars?  That does not work.

Please find another IETF standard protocol in which
something as fundamental as the identifier length is
left undefined.  I don't think you can, because
this is extremely important to tool interoperability.

>     maximum-initial-router-advertisement-interval

We have no operational need whatsoever for identifiers over 63
UTF-8 characters long.  That much is obvious.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Mar 2009 16:22:52 +0100

> they are unique in the first 63 chars?  That does not work.

The agent already has to buffer the 2G attribute I am sending in the
<rpc> element so that it can be echoed back. Now, that is a NETCONF
issue and not a NETMOD issue but still if we talk about consistency...

/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: Fri, 27 Mar 2009 08:43:54 -0700

> issue and not a NETMOD issue but still if we talk about consistency...

YANG does not support XML attributes.
This issue has to do with interoperability of YANG module
definitions, not NETCONF PDU content.

This issue started because Phil said in the meeting that
a usage guideline for the IETF wrt/ YANG module identifier
length needed to be defined in the YANG spec itself.
Now the claim is that no identifier length is needed.

I agree with you.
I withdraw the change request.

The current text says that any tool that rejects any YANG
identifier over 63 characters long is fully compliant with
the standard.  That is fine.

If you think it is a good idea to write modules that are
are allowed to be rejected with a fatal error by any YANG tool,
then good luck with that.

I plan to change the CLR in the usage guidelines draft
so it says that every IETF standards-track YANG module identifier
MUST be compatible with any compliant YANG tool.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 27 Mar 2009 12:07:51 -0400

>Now the claim is that no identifier length is needed.

My comment was that either this is an interoperability issue for
YANG that needs fixed in YANG, or it's a CLR that isn't needed in
either that YANG spec or the IETF guidelines.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 27 Mar 2009 11:04:31 -0700

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: "NETMOD Working Group" <[email-masked]>
> Sent: Friday, March 27, 2009 6:06 AM
> Subject: Re: [netmod] identifier length
...
>     ways to make the same utf-8 content)

I do hope the specification calls out the specific normalization
form to be used.  A stringprep profile would probably make sense.

Randy