Subject: Re: [netmod] identifier length survey

From: "Jon Saperia" <[email-masked]>
Date: Fri, 03 Apr 2009 01:57:15 +0000

I will not say what the correct exact number should be (64 seems ok) 
but a limit from a couple perspectives does seem to matter:
    1. I have seen mail in this thread talking about the size of 
configuration files.  Things that tend to make them larger are not as 
helpful.
    2. From the perspective of an NM application and DB building 
perspective larger is problematic, especially for larger networks, 
unspecified leaves a bit too much to the imagination of the application 
developer. I think an important objective is better tools - leaving 
this unspecified works in the opposite direction.
    3. From the perspective of people that are concerned with bandwidth 
utilization - some of the people I work with - efficiency over the wire 
does make a difference and this (no limit) seems also to point in the 
opposite direction.
So while XML might not have limits, the whole purpose/justification for 
YANG from what I recall is that we need this for the specialized 
purpose of defining and transmitting config information.  As a result, 
the limit is not a CLR, it is something that makes the tool appropriate 
to the purpose it is being created for.
/jon
On Apr 2, 2009, at 1:46 PM, Andy Bierman wrote:
Phil Shafer wrote:
Andy Bierman writes:
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)).
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.
Thanks,
Phil
Andy
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod