Subject: Re: [netmod] identifier length survey

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Apr 2009 00:12:01 -0700

Martin Bjorklund wrote:
> Andy Bierman <[email-masked]> wrote:
>>   1) YANG writers MUST know the minimum safe length value that
>>      can be used on all YANG tools
>>   2) no YANG/NETCONF implementation can possibly support infinite
>>      length identifiers, and letting implementors pick any arbitrary limit
>>      is not inter-operable
> 
> Why don't you think the same rule is important for the other
> constructs I mentioned?  What makes the identifier special?
> 

Identifiers are special because they cannot be optimized away.
They are mandatory-to-use within agent code to handle incoming PDUs.
In order to support small embedded NETCONF agents, setting
minimum resource limits that are reasonable is a good idea.

The current text follows the similar 'C' rules,
which simply set the minimum requirements for all tools,
and do not prevent any tools from supporting more than the minimum.
If a minimum of 63 was a problem, we would have already raised the limit
in SMIv2 a decade ago.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 01 Apr 2009 10:15:49 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> 
> 
> >> Regarding a limit as in (2), IMO this is pretty arbitrary.  Why do we
> >> have a limit on this particular thing, but not on namespace uri
> >> length; not on the 'contact', 'description' clause data; not on the
> >> number of leafs in a container; not on the number of features; not on
> >> the nested levels in the hierarchy; not on anything else!  What makes
> >> the identifier special?
> 
> The difference is between data stored in the agent and data that is not.
> 
> Good catch on the namespace-URI.
> We need a similar rule for that (for the agent)
> 
>    Implementations MUST support namespace URIs at least 1023 characters
>    in length.
> 
> The other clauses are not stored in the agent so they do not matter.

The depth is stored in the agent; the number of leafs is storeed in
the agent; the number of typedefs etc.

These identifiers are comparable to XML element names, and as has been
pointed out before, XML seems to be quite interoperable.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Apr 2009 03:38:06 -0700

> pointed out before, XML seems to be quite interoperable.

They are more comparable to SMIv2 descriptors for out purposes,
and SMIv2 has proven to be quite inter-operable.

Please provide at least ONE use-case demonstrating that
adopting the same guideline as SMIv2 will cause some actual
problem in an actual network somewhere.

I realize that in theory somebody could want a 6 billion character
identifier, but I don't this is a real problem the IETF needs to solve.
The IETF just needs to make sure some reasonable defaults are
supported on every NETCONF/YANG implementation.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Apr 2009 03:45:37 -0700

> pointed out before, XML seems to be quite interoperable.

Then why does your agent need to force the list keys to
be ordered first?  Your agent should be able to deal with
this.  Every other XML application can deal
with the elements delivered in schema order.
Why is it OK for NETCONF to be special in this one aspect of XML usage,
but no others?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 01 Apr 2009 12:46:23 +0200 (CEST)

> problem in an actual network somewhere.

rfc 2578 says:

   For all descriptors appearing in an information module, the
   descriptor shall be unique and mnemonic, and shall not exceed 64
   characters in length.

Assuming "shall not" means "SHALL NOT" as in rfc 2119, this would
correspond to your alternative (2), i.e. a fixed max lentgh.  Noone
has claimed that this would be non-interoperable.  We have claimed
that the current text is.

> identifier, but I don't this is a real problem the IETF needs to solve.

Do you think anyone will ever want 6 billion nested levels in the
hierarchy?  64 levels? 32?  Should we limit the nest level because of
this?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Apr 2009 03:53:41 -0700

> hierarchy?  64 levels? 32?  Should we limit the nest level because of

Stop answering my question with irrelevant questions.
Several people have offered reasons why supporting infinite length
descriptors are a memory, tools compatibility, and/or implementation burden.

The SMIv2 rule is more strict than YANG, and it has never
caused any problem at all.

You have not demonstrated that the "at least 63" rule
will cause any problems whatsoever.  If you really want to
use large descriptors in your data models, you can do it.

Several people agree there is a need to force implementations
to support at least 63 chars.  IMO, nobody agrees that forcing the
agent to support infinity is needed.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 01 Apr 2009 13:09:14 +0200 (CEST)

> Stop answering my question with irrelevant questions.

I'm sorry, but you asked one question (a use-case for when SMIv2 rules
lead to interoperability), and I replied to that.

> descriptors are a memory, tools compatibility, and/or implementation burden.

[re-reading this thread]  I cannot find those reasons from "several
people" in this thread.

> caused any problem at all.

Which is fine.  As I have stated earlier, I prefer the SMIv2 rule
before the current text.

> will cause any problems whatsoever.

See e.g. Phil's message
http://www.ietf.org/mail-archive/web/netmod/current/msg02317.html.

I think we have reached an end in this discussion.  Maybe the chairs
can see if there's consensus to be found in this thread?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Apr 2009 04:19:59 -0700

> Andy Bierman <[email-masked]> wrote:
...
> http://www.ietf.org/mail-archive/web/netmod/current/msg02317.html.

I do not accept the premise of Phil's mail that anybody wants
to use super-long descriptors.  It does not matter if
every toolkit supports it unless the IETF agrees it is a MUST
instead of a SHOULD or MAY.  There is no reason
to make it a MUST.

If the limit of 63 is too short then suggest a higher number.
How about 1023? That is fine with me too.

But nobody has an actual use-case for anything above 63.
Pick a positive finite number, because infinite length
strings are hard to store on small embedded devices ;-)

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 01 Apr 2009 13:32:55 +0200

> descriptors are a memory, tools compatibility, and/or implementation burden.

Nobody wants to support infinite length, but somebody might want an
identifier with 64 characters, which is considerably less than infinity.
On the other hand, allocating 64 bytes for every identifier can be waste
of memory, too.

BTW, one of the main virtues of the new GNU utilities over the old Unix
ones is the absence of such hard limits, and they all run on my pocket
devices.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Apr 2009 05:09:46 -0700

Martin Bjorklund wrote:
>....

My only strong objection is to 'infinity' or 'unspecified'
as the minimum limit.  I have no problem with changing
the current text to "MUST be between 1 and 63 characters".
I have no problem with picking a higher value than 63,
if that is considered too short.

Andy

---

From: David Reid <[email-masked]>
Date: Wed, 01 Apr 2009 09:51:16 -0400

> Hi,
> 
> There seems to be 3 options wrt/ identifier length
> in the YANG language:
> 
> 
>    1) 1 .. infinity  (no rule at all)
>    2) 1 .. N         (MUST for every module:
>                       "identifiers MUST be 1 to N chars long")
>    3) 1 .. N         (MUST only for standard modules:
>                       current text: "tools MUST accept 1 to N chars")
> 
> Which do you prefer and why?

I prefer 2, with a value for N of 64, because my code generator can't
support infinite lengths and because I have never seen a problem with the
SMI 64 limit. I'd be happy copying the text exactly from rfc 2578.

-David Reid

---

From: Steve Moulton <[email-masked]>
Date: Wed, 01 Apr 2009 10:17:36 -0400

On Saturday, March 28 2009, Andy Bierman <[email-masked]> wrote:

> If the result is (2) or (3), then the WG needs to pick a value for N,
> which will hopefully be 63.

I'd prefer 2 (though I'd kinda prefer 64 but won't refuse the bit at 63).   
Either of these is adequately long to generate unique leaf node identifiers, 
and for those of us who do source code tools, will make life across
various development environments easier.

	- Steve

---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
moulton at snmp.com  Knoxville, TN 37920-9716 USA  http://www.snmp.com

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Apr 2009 09:50:21 -0700

Ladislav Lhotka wrote:
.....
> ones is the absence of such hard limits, and they all run on my pocket

really? they invented a malloc() function that never fails?!
I wish you told me sooner, 'cause I just wasted $48 on memory sticks
recently, upgrading a couple servers.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Apr 2009 12:13:58 -0700

> I'd prefer 2 (though I'd kinda prefer 64 but won't refuse the bit at 63).

SMIv2 translation is the best (and only valid) use-case for changing
the current text.  It is supported in the WG charter.

I like the idea of cut-and-pasting the corresponding text from SMIv2.
MUST be 1 to 64, and recommend 1 to 32.  I think that solves the concerns
about somebody ignoring the "identifier over 63 chars" warnings
and a module that works on 1 toolset stops working (because the
same vendor decides to change it or another vendor uses a different
limit.)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 01 Apr 2009 23:00:58 +0200 (CEST)

> strings are hard to store on small embedded devices ;-)

Of course.  But the point is that even with 63 bytes (or whatever
fixed length) a small embedded device cannot handle an infinite number
of identifiers.  So should we also limit the total number of
identifiers?

I really do not understand this memory allocation argument.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Apr 2009 17:03:43 -0700

> of identifiers.  So should we also limit the total number of

I think a small embedded device is unlikely to have even
a 1000 identifiers, let alone a billion or so.
Although saving memory is the reason for some
other YANG decisions, it is not the reason for this one.

IMO, the only answer is, for all strings defined in a YANG file
while are used in the protocol (module-name, namespace-stmt, identifier),
a fixed length for all implementation MUST be specified.
That way for all implementations of 'yang-version 1', these
values will be the only ones allowed on any implementation.

So Phil's argument is valid:
   - warnings are not reliable so all implementations need
     to support the same values

But nobody wants to support huge (infinite!) strings, so the arbitrary
values already in use within the industry are good arbitrary values
to use in YANG.

> I really do not understand this memory allocation argument.

I don't understand the 'put the keys first' argument,
but they are about the same I think.  We could all
construct arbitrary examples (like 6 billion bytes in the PDU
between the end of the list start-tag and the list keys),
so maybe it is better to leave implementation details
out of debates completely.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 Apr 2009 06:01:39 +0200 (CEST)

> a fixed length for all implementation MUST be specified.

I understand that this is your proposal.  But if saving memory is not
the reason for this rule, then what is the reason?

In an earlier email in this thread you wrote:

andy> Code is generated using these descriptors.
andy>
andy> The memory impact from these descriptors is already
andy> non-trivial at 63 chars.

I assume it boils down to code generation, which also David Reid
listed as the reason for having a fixed limit.

> but they are about the same I think.

The difference is that the 'put the keys' first argument *is* about
saving memory, which apparently the identifier rule is not.  To be
even more specific, it is about saving *dynamic* memory.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Apr 2009 03:44:03 -0700

.....
> even more specific, it is about saving *dynamic* memory.

I think the compatibility argument is the
only one that is relevant, because the memory
argument is relatively weak.

Memory is memory.
Whether you allocate it out of the static pool,
the stack or the heap makes no difference, especially
to the standards definition.

IMO, an XML application that barfs on element order
is kind of fragile.  Forcing all YANG applications
to order keys first ripples that fragility out of
the agent, into the network.  The amount of PDU fragment
that needs to be buffered in (in reality) quite small,
especially since YANG is brand new, there are no
data models yet, and the problem is completely
avoidable unless the key(s) come from a grouping.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 2 Apr 2009 09:59:15 -0400

Andy Bierman writes:
>The amount of PDU fragment

Buffering needs are small if you have small configs, but this isn't
the case for me.  We're hitting 10-15MB configs now and it's sure
to get worse.  This is my reality.

The lack of published data models isn't relevant, since we want
vendors to publish their existing config schema as yang modules.
Hopefully the number of published models will balloon as
soon as the spec is finalized.

>We not only would like NETCONF/YANG to be
>compatible, we want it to be implementable.
>Simply stating that everybody MUST support
>infinite length strings, yet not ONE vendor
>says they can implement that, does not help solve
>any real problems.

As Lada mentioned, removing length limits from unix tools doesn't
mean that these tools cannot function in a limited memory environment.
Any tool is ultimately limited by available memory, but that is a
distinct issue from artificially limiting individual tokens without
a convincing reason.

In a modern world, there's no need to limit these identifiers.  If
the thought is that C only allows 63 character symbols, then limiting
YANG to 63 doesn't solve the problem, since there must be some sort
of translation between YANG identifiers and C symbols to prevent
conflicts between "leaf sleep" and sleep(), and using some sort of
prefix or suffix will further reduce C's 63 limit to something even
less acceptable.  Fortunately modern tools (gcc) avoid this limit,
allowing us to sidestep the issue.

C is a good parallel, since I'm sure that K&R never envisioned C
symbols like:

     __ZNK10__cxxabiv119__pointer_type_info15__pointer_catchEPKNS_17__pbase_type_infoEPPvj

Given that I've already seen a 45 byte leaf and given that no one can
predict the future needs and evolution, a 64 character limit is an
unneeded CLR.

Thanks,
 Phil (who will try to hold his tongue for longer this time)

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Apr 2009 08:22:16 -0700

> soon as the spec is finalized.

But you control your own YANG module contents.
You can put your own keys first in the YANG module.
But debating the number of bytes that need to be
buffered is pointless.  It's just another
implementation detail out of dozens that can be
optimized for robustness or optimized for speed.

> distinct issue from artificially limiting individual tokens without

This does not help the IETF define a common data modeling
language.  If a majority of vendors had said they can
support infinite length strings, then forcing everybody
to support them might be reasonable.

Since you are the only vendor who claims to be able to
implement arbitrary length identifiers, there is not any
consensus for that change in the text. I think the SMIv2 style
text has the most consensus, and that will solve your
concerns about every platform supporting the same limits.
Everybody will support 1 - 64 chars.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 2 Apr 2009 11:51:23 -0400

>concerns about every platform supporting the same limits.

I don't agree with any of this.  I'm not the only one in this debate
that sees no reason for the limit.  I'm certainly not the only one
that sees the current text as flawed.  In fact this whole topic was
one you raised at the WG meeting, pointing out the interoperability
issues with the current text.  You've been backpedaling, but I think
these is a problem as it sits.

In any case, this whole thread continues to devolve into mud
wrestling.  Would the WG chairs please step in and determine if a
concensus exists?

Thanks,
 Phil (the lean mean fighting machine)

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Apr 2009 09:09:49 -0700

> these is a problem as it sits.

At least 2 tool vendors have said
they cannot implement infinite length identifiers,
and that SMIv2 compatibility is important to them.
Since we all have to support the same range,
1 to infinity cannot be it.  It seems 1 to 64 has
the most consensus.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 2 Apr 2009 12:42:34 -0400

>they cannot implement infinite length identifiers,

Yup, and at least 2 have said the opposite.  Plus some
others.  I'll leave it to the chairs to do the counting.

>1 to infinity cannot be it.  It seems 1 to 64 has

The WG is concerned only with SMIv2->YANG, not with mapping YANG
back into the restrictions of SMIv2.  Since an unlimited string is
capable of holding 63/64 characters, using SMI's legacy restrictions
to push for a 63/64 limit in YANG doesn't hold water.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Apr 2009 10:01:02 -0700

> to push for a 63/64 limit in YANG doesn't hold water.

1) You said we all need to implement the same range for identifiers
2) I reluctantly agreed
3) By definition, that means we need to select a finite number
    for the upper bound.  Infinity is not a number, and it is not
    implementable.
4) Nobody actually wants to use identifiers over 64 characters in length

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 2 Apr 2009 13:23:58 -0400

>4) Nobody actually wants to use identifiers over 64 characters in length

All roads seem to lead you to this same outcome (64), but I'm still
stuck on the initial question:

  Why do we need to limit identifier length?

If there's no convincing reason, then it is just a Crummy Little
Rule.

We don't need it for YANG to be implementable, since we know that
XML functions perfectly well in multiple independent implementations
without a limit.

We don't need it for code generation, since we know that C++ loves
to generate symbols that are insanely large.

We don't need it for SMIv2 compatibility, since we are only interested
in mapping from SMIv2 into YANG, not vice versa, and SMIv2's
restricted strings will happily fit into our unlimited ones.

We don't need it to save memory, since the expectation is that one
uses a dictionary (or cons creation or similar approach) to ensure
that the implementation needs only one copy of the identifier, not
one per instance.

Are there any strong reasons to keep this restriction?  Isn't it
just a CLR?  Will it just be one of the list of "oh no one will
ever need that"? ("No one will ever need more that 640K", "no one
will ever need more that 8.3 filenames", "no one will ever need
more that four partitions", "no one will ever need more than one
display on their computer", "no one will ever need a book on towel
origami" (http://tinyurl.com/dygpfr)).

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Apr 2009 10:46:11 -0700

> origami" (http://tinyurl.com/dygpfr)).

I am convinced that interoperability will not be achieved
without a specific rule, and that is why we are writing this standard.
Wes, Juergen, David, Steve, and I have all stated use-cases
for picking a specific finite upper-bound instead of infinity.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 2 Apr 2009 15:11:33 -0400

>without a specific rule, and that is why we are writing this standard.

I understand that you believe that we need a 63 or 64 character
limit on identifiers.  But what I keep asking for is a reason behind
this belief.  You've given several, which I think Martin, Lada, and
I have addressed.  I tried to recap this in my last email.  Have I
misunderstood or misstated your reasoning?  Are there holes in the
logic behind the counter arguments?  Or have we slipped to the point
where this is quasi-religious, and logic yields to faith?

My worry is that this CLR is required by the way your tools encode
identifiers in your SQL tables.  Should that be the key issue in
defining standards?  Can this encoding scheme be changed to use
table lookups via a dictionary so the database keys are, say, small
numbers instead of strings?  What happen when you get a customer
that requires >15 depth and you are forced to use a different
encoding scheme?  Or a different database that doesn't have this
900-odd byte restriction?  Will we be able to remove the CLR at
that point?

>for picking a specific finite upper-bound instead of infinity.

They may have stated a preference for keeping a CLR, but not a use
case that necessitates it.  David's comment was about his toolset.
I couldn't find Juergen's comment on point and if Wes posted
something, I can't find it in the netmod archives.  Here's Steve
and David's comments:

  >SMI 64 limit. I'd be happy copying the text exactly from rfc 2578.

I dislike having a hard limit without a strong reason.  I strongly
dislike having a low limit, since I have existing tags that are 45
bytes, which is ~3/4 of the way to that limit.  If I'm approaching
the limit without trying, what happens when YANG++ (YAYANG?) starts
making C++-like butt-ugly tags?

Just because "no one needs it today" is no reason to make a rule
to prevent someone in the future from using it.  Similarly, just
because it's the SMIv2 works does not mean that YANG needs the
same restriction.

Thanks,
 Phil "Unlimited" Shafer

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Apr 2009 21:31:21 +0200

> for picking a specific finite upper-bound instead of infinity.

Clarification: The current sentence does _not_ define a specific
upper-bound - it establishes a minimum baseline everybody has to
implement but leaves the upper bound open.

I thought this was a workable compromise but it seems I was wrong...

/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, 02 Apr 2009 13:26:25 -0700

>> without a specific rule, and that is why we are writing this standard.

Just because XML does not specify a limit does not mean
that the NETCONF protocol does not have practical
limits imposed from legacy and code generation considerations.

If we were creating a generic XML standard for the W3C then
I would completely agree with you.  But we're not.
YANG is a specialized XML language for NETCONF.
It adds protocol operations to NETCONF.
It does not support XML attributes, among other
XML constructs, so it could not possibly be considered
as a generalized XML language (good -- that was not our charter).

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 2 Apr 2009 16:57:44 -0400

>limits imposed from legacy and code generation considerations.

Please elaborate on what aspects of YANG differ XML, WRT limits.
No one has the expection that an XML language will use 48M element
names, since no sane person will do this, but no one ever felt
the need in XML to say "no element name may exceed 64 bytes".

What is there about NETCONF or YANG that requires a different
attitude, that requires a CLR where XML does not?  If XML can
be interoperable without such a rule, why does YANG require it?

Is the expectation that YANG authors will be less sane than XML
authors?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Apr 2009 14:31:12 -0700

> the need in XML to say "no element name may exceed 64 bytes".

 From the NETMOD charter:

   While it is desirable to provide a migration path from existing
   MIB modules to YANG data models (modules), it is not a
   requirement to provide full compatibility between SMIv2 and YANG.
   The Working Group will determine which constructs (e.g., conformance
   statements) are not relevant for translation from SMIv2 to YANG. YANG
   is also permitted to introduce constructs that cannot be expressed in
   SMIv2.  However, all basic types that can be represented in SMIv2 must
   be expressible in YANG.

I interpret this text to mean that the NETMOD WG should take every
reasonable opportunity to remain compatible with SMIv2.
YANG uses a subset of XML.

It is arbitrary to say we MUST support this one aspect of XML
when we leave out so many parts of XML and use XPath
so 'liberally'.  YANG makes its own XML order rules,
its own NETCONF rules, its own rules for everything.

A perfectly reasonable implementation strategy for a
transition product might be a NETCONF to SNMP proxy,
in which the SNMP uses a MIB module algorithmically translated
from the YANG module to interface with legacy agent instrumentation.

> Is the expectation that YANG authors will be less sane than XML

Nobody can implement infinite length strings in their agent.
Nobody wants to use identifiers over 64 chars -- ever.
It is bad for readability to use super-long identifiers.
The 1 to 64 rule helps some implementation
use-cases and helps inter-operability.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Apr 2009 14:49:37 -0700

>> limits imposed from legacy and code generation considerations.

Actually, remembering back to when the RFC 2578 rule
was written, it was done to protect operators, not implementors.
The full test from sec. 3.1, para 3:

    For all descriptors appearing in an information module, the
    descriptor shall be unique and mnemonic, and shall not exceed 64
    characters in length.  (However, descriptors longer than 32
    characters are not recommended.)  This promotes a common language for
    humans to use when discussing the information module and also
    facilitates simple table mappings for user-interfaces.

Operators need to be familiar with NETCONF identifiers for
the YANG modules they use. It is even more important than
SNMP, because these YANG identifiers are used in the
instance-identifier data-type.  The "max 64" rule
ensures that the YANG readers and network operators (amongst others)
never have to read super-long identifiers in NETCONF/YANG.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Apr 2009 19:30:41 -0700

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, April 02, 2009 8:51 AM
> Subject: Re: [netmod] identifier length survey
...
...

I have to admit being rather astonished by this thread.  The
existing text, which simply puts a limit to the longest identifier
implementations are *required* to support (and in no way
prevents implementations from supporting longer things)
seems eminently reasonable.  Consider it from the perspective
of someone attempting to test whether a tool conforms to the
specification.  If there is no "minimum maximum length"
requirement, then any tool which *ever* emits an "identifier
too long" error is arguably non-conformant, and conformance
test tools will almost certainly include grotesquely and ever-
increasingly long identifiers as part of their test cases.
This would seen to be a type of pathological behaviour
we should not encourage.

Randy

---

From: WashamFan <[email-masked]>
Date: Fri, 03 Apr 2009 10:56:29 +0800

Hi,

The interpretation by Juergen makes more sence to me. 63 or 64
limit is a minimum baseline for interoperability, but not expected
to impose a upper-bound at all.

When I write a identifier within 63 or 64 characters, I don't worry
about compliant implementation would reject it. But I still can
write a identifier beyond the limit, when I know the peer could
handle it or at the risk of rejection. So the limit means it is safe
to write identifier with the limit even I don't know you much but
you are compliant. BTW, any implementation supporting beyond
the limit is compliant.

Unless all implementation can support infinity, limit MATTERS for
interoperability, then, readability.

washam

>  Fax:   +49 421 200 3103         <
>  _______________________________________________
>  netmod mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 04 Apr 2009 11:47:42 +0200

> too long" error is arguably non-conformant, and conformance

I don't agree. If there is no limit specified in the language, there is
also no way to become non-conformant. This of course doesn't mean that a
device is required to support arbitrarily long identifiers.

Imagine a really simple device that is to support a given data model.
Its designer can find out by reading the data model the *actual*
identifier length that has to be supported and implements the identifier
type to be, e.g., 32 chars long. This should IMO be perfectly fine,
whereas with the current wording the implementation can be potentially
accused as being non-conformant.

The solution suggested by Phil (no limit in the language spec and
63-char limit in the guidelines) should IMO be sufficient to avoid any
problems with identifier length.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Sat, 04 Apr 2009 06:48:56 -0700

> device is required to support arbitrarily long identifiers.

really?
I agree with Randy.
It seems to me that unless your tools have infinite memory,
there is no way to implement a compliant tool.

> accused as being non-conformant.

this is a fragile hack.
imagine 2 siblings with the same length identifier.
since XML node order is not enforced except for list keys,
any heuristic used to optimize away the identifier names
is fragile.  This hack does not address readability or
bandwidth concerns at all.

> problems with identifier length.

The guidelines spec is an Informational RPC,
and not part of the standard.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 04 Apr 2009 07:05:10 -0700

Randy Presuhn wrote:
> I have to admit being rather astonished by this thread. 

me too.
Usually, changes in an I-D are driven by use-cases.
One would think that there was a real need somewhere
to use > 64 char identifiers.

But nobody *wants* to use > 64 identifiers.
There have been some bad effects listed from
using long identifiers, but no benefits.

XML allows PIs, DTDs, XML attributes, etc. and
NETCONF/YANG supports none of it.  It seems rather arbitrary
to say YANG MUST support infinite length names
just because XML supports it.  There are plenty
of features YANG has removed from XML because they
are not needed in NETCONF.  This is just one more.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 04 Apr 2009 16:35:52 +0200

> there is no way to implement a compliant tool.

Just the opposite - implementations will be compliant even if they only
support single byte identifiers.

It is the same in XML. Although there is no limit on element name
length, a program using for instance RSS can get along with 32 bytes,
perhaps even 16, I am not sure. Does it mean that it doesn't conform to
XML 1.0?

> bandwidth concerns at all.

I am not sure where the hack is. My point is that the manager cannot
throw arbitrary identifiers on the device (and vice versa), but only the
ones present in the data model that the device supports.

> and not part of the standard.

For sane people this should be enough, and insane people are not limited
by the current wording of the YANG spec anyway.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Sat, 4 Apr 2009 12:40:03 -0400

>there is no way to implement a compliant tool.

Are you saying that if a spec allows arbitrary length strings, then
it's not possible to implement compliant tools?

Let's go the other way: How many times have the words "oh they
couldn't possibly need more than that" turned out to be wrong in a
painful and/or expensive way?  How many specs have been repaired
to remove limits or expand the number of bits in a fixed- width
value (ipv6, 32bit ASes, etc)?  How many times do we just have to
live with someone else's idea of a great limit?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 04 Apr 2009 09:57:08 -0700

> support single byte identifiers.

That would be a problem, not a feature.
That is exactly why I have been debating this issue from the start,
since it is the only real use-case for removing the '64' rule.

Somebody could ask the IPFIX WG to rename
every single object in the ipfix-psamp data model
to 1 char names because their fully compliant YANG implementation
only supports 1-char names.

The point of the YANG standard is to define a data modeling
language that all NETCONF/YANG implementations MUST support.

That way, a WG like IPFIX can write a standard data model
using 1 to 64 char names, and know that it will be
accepted by every single compliant YANG implementation.

If long names were really important, then they
are supported by Juergen's current text.
If not, the SMIv2 text is most appropriate.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 4 Apr 2009 12:50:08 -0400

>Usually, changes in an I-D are driven by use-cases.

We don't need a use case to remove a CLR; we should have a use case
to keep it.

>It seems rather arbitrary

I don't think anyone said this.

XML's lack of a length limit was used to disprove your claim that
a specification with no limit cannot be implemented on machines
without unlimited memory.  My phone groks XML, so clearly this claim
is false.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sat, 4 Apr 2009 12:55:11 -0400

> support single byte identifiers.

I disagree with this.  An SSH implementation called support a 1-character
username or comment just because the spec lists these as "arbitrary length
strings".

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 04 Apr 2009 19:12:22 +0200

> If not, the SMIv2 text is most appropriate.

Right, so for IPFIX you can use your implementation with 64-byte
identifiers, in severely resource-constrained devices you may want use a
small footprint implementation limited to 8-byte identifiers and three
levels of hierarchy (because the data models were designed accordingly),
and if very long identifiers are needed, yet another implementation
might be necessary. I don't know why any of these should be labelled as
non-compliant.

Supported identifier length, together will other important parameters,
will just be a property of an implementation.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 04 Apr 2009 13:21:56 -0400

I keep reading this discussion and wondering if I am misunderstanding 
all of the participants.

As I understand things, our primary goal here is interoperability.

It would seem that the key definition of interoperability for netmod is 
that all models can be processed by all implementations.

If so, then the message below seems to amount to a statement that 
without some sort of length limit, we will fail interoperability.
I under stand Phil's point that any specific limit we pick looks like a 
silly rule that we picked out of thin air.  But it would seem that 
interoperability requires some mandatory limit, somewhere.  (I suppose 
it can go in some document other than the protocol document, but since 
it is a piece of information needed by all protocol implementors and 
virtually all model writers, the protocol would seem the place to put it.)

Yours,
Joel M. Halpern

---

From: Andy Bierman <[email-masked]>
Date: Sat, 04 Apr 2009 10:43:29 -0700

> that all models can be processed by all implementations.

IMO, that would be the point of a standard data modeling language

> virtually all model writers, the protocol would seem the place to put it.)

It is not the document that matters, but rather
the status of the document. It MUST be normative text
in a standards-track RFC.

Unless there is an arbitrary limit that every tool MUST support
for identifier length, then no IETF WG can use YANG to
produce inter-operable standard data models.  That is more than
an inconvenience -- it is a show-stopper.

The SMIv2 limit of 64 chars has not caused
any problems in 2 decades, so it seems quite reasonable
to continue using that limit.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 4 Apr 2009 16:46:14 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Joel M. Halpern" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, April 04, 2009 10:43 AM
...
...

Calling it an "arbitrary limit" is probably partially to blame for the
adverse reaction.  It is *not* a "limit" in an normal sense.  It's a
"minimum maximum".  No tool is forbidden from supporting 
longer things.  It also does not take the place of a guideline for
module developers.  It just sets a mimum expectation for what
tools must be able to support.

Randy

---

From: WashamFan <[email-masked]>
Date: Sun, 05 Apr 2009 13:12:54 +0800

Hi,

Yes, I agree as I commented before.

We must admit some implementations have their limits in reality 
unless every implementation is able to support infinity, mustn't we?
So, 63/64 limit is a minumum baseline for all compliant 
implementations, i.e., identifiers within 63/64 chars are
safe for interoperation, but you can still have identifiers
beyond the limit but with the risk of rejection.

the limit constraint MATTERS interoperability.

washam

---

From: "tom.petch" <[email-masked]>
Date: Tue, 7 Apr 2009 20:03:22 +0200

----- Original Message ----- 
From: "Andy Bierman" <[email-masked]>
To: "Phil Shafer" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 02, 2009 11:49 PM
Subject: Re: [netmod] identifier length survey

> never have to read super-long identifiers in NETCONF/YANG.

That for me is the compelling argument why 64 is plenty big enough.

I am more likely to have to read, write, communicate and convey these 
things and want to be able to do so with the minimum risk of error, so make it
long enough that there is no over abbreviation, but not so long that 
I cannot recognise and remember it in the short term.

"dot3OmpEmulationNotBroadcastBitNotOnuLlid"
or 
"gmplsTunnelARHopExplicitReverseLabelPtr"
is quite enough.

The arguments about tools and capacity seem less relevant to
me.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Tue, 07 Apr 2009 14:35:45 -0700

> That for me is the compelling argument why 64 is plenty big enough.

The reason I changed my opinion to "don't care" is that
is really is no big deal in the code.  That argument is
a wash.  For any detail, we can probably find 2 vendors
that think it should be implemented 1 way and 2 more that
think it should be implemented another way.  It's just
code.  It takes 1/1000 as much time to change it, than
it does to argue about it.

> "gmplsTunnelARHopExplicitReverseLabelPtr"

Yes, and therefore Phil is right about the self-regulating
aspect of the CLR, not to mention the real CLR that will
be in the YANG Usage Guidelines.

WG members will object to long identifiers because
they are unreadable, not because some YANG vendor
might not like to implement their code this way or that way.

Andy