Subject: Re: [netmod] identifier length survey

From: Gerhard Muenz <[email-masked]>
Date: Sun, 05 Apr 2009 11:47:04 +0200

Hi,

WashamFan wrote:
> 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.

If you (and others) argument like this, we also have to standardize the
minimum maximum number of identifiers per module, the minimum maximum
string length, the minimum maximum element depth in XML,.......
And at the and, we could standardize something like "the module must be
implementable with 64kB of memory only".

To me, it seems arbitrary to start restricting the identifier length
while leaving all the other parameters unlimited. If you interpret the
lack of a limit as "infinity MUST be supported", then not putting a
limit to the number of identifiers also leads to a standard that no
real-world implementation can comply with.

There will always be situations where a device returns "out of memory".
Also, it is not necessary that all YANG-implementations support all
modules. An agent can be optimized for the IPFIX-PSAMP module. It does
not need to support longer identifiers than those specified in the
module. Yet, it must be able to parse and possibly ignore longer
identifiers.

> the limit constraint MATTERS interoperability.

As I understand, it matters because certain prototype implementations do
not support longer identifiers. Regardless of a minimum maximum
identifier length in the standard, I would not call such implementations
non-conform, they just have certain restrictions (or capabilities).

Recommending identifier lengths less or equal 64 is a good idea. Yet,
I'm still not convinced that a minimum maximum length must be standardized.

Cheers,
Gerhard

> 
> washam
> 
>> ...
>> > 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.
>> ...
>> 
>> 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: Ladislav Lhotka <[email-masked]>
Date: Sun, 05 Apr 2009 12:53:15 +0200

Hi,

I fully share Gerhard's view.

Interoperability means that any device can talk to any manager, provided
that the manager implements the device's data model. It is the
particular data model that determines the identifier length that both
parties have to support. YANG language specification needn't care about
this.

Lada

Gerhard Muenz píše v Ne 05. 04. 2009 v 11:47 +0200:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Apr 2009 06:29:44 -0700

> I fully share Gerhard's view.

So it's OK if I ask the IPFIX WG to
check the ipfix-psamp data model so
all identifiers are 8 chars or less?

If my compliant implementation can pick any identifier
length to support, then why can't I pick 8? or 1?
I want the IPFIX WG to ONLY produce standards that
will work on compliant YANG implementations.

The identifier string is used on-the-wire quite a bit.
It is used by readers and operators even more.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Apr 2009 06:39:17 -0700

> parties have to support. YANG language specification needn't care about

If we make this change,
then we also need to remove any other CLRs
in YANG related to saving memory,
starting with reordering list keys.
This is extremely disruptive to ordinary
XML applications that do not know YANG agents are fragile.

If a YANG agent can handle infinite length identifiers,
then it should have no problems whatsoever buffering
just 1 <rpc> element.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Apr 2009 07:37:26 -0700

> parties have to support. YANG language specification needn't care about

I do not understand why the current text is such a problem.
It allows implementations to use any size identifiers
they want, just like C.

It insures for all users that a 'minimum maximum'
is supported by all implementations, just like C.

If you turn off or ignore all warnings, then you
get what you get, and it's your own fault, just like C.

I think the current text is fine and there is no need to
change it, except s/63/64/ to support SMIv2.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Apr 2009 09:29:11 -0700

> implementable with 64kB of memory only".

C99 spec:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf

See sections 5.2.4.1 and 6.4.2.1, note 6 to see how the
ISO C standard handles the 'minimum maximum' problem.
They go into great detail wrt/ the minimum requirements
a tool that claims to support C99 must implement.

They do this so C programmers that use only the C99 subset of
the C language can know exactly what to expect from any C99
compiler.

YANG is like C99 and XML is like C in this analogy.
IMO, compatibility with SMIv2 and C99 is
quite useful to real applications.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 05 Apr 2009 20:04:56 +0200

> all identifiers are 8 chars or less?

No, there is no reason to call for any data model changes - as long as
the data model complies with the (future) guidelines. But anybody
wanting to implement the IPFIX/PSAMP data will have to choose or write
an appropriate implementation. For identifier length - which is by far
not the only parameter to observe - 8 chars are insufficient but 32 may
be enough.

> length to support, then why can't I pick 8? or 1?

You can, but you will be able to use it only for a certain subset of
valid YANG models. This is nothing special, every implementation has its
limits and won't be able to digest some valid data models (with too long
identifiers, too long strings, too many levels of hierarchy, ...)

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Apr 2009 11:49:13 -0700

> identifiers, too long strings, too many levels of hierarchy, ...)

IMO, this would make the YANG standard much less useful.
Among all the other problems with no specified limit is the
confusion is causes.  You say an implementation that supports
1-char names is complaint.  Phil says no.  I think another
opinion was 'it depends on the memory available'.

The current text is quite clear to implementors.
Removing it causes a lot of confusion, which is a bad thing
wrt/ interoperability.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 05 Apr 2009 22:02:09 +0200

> XML applications that do not know YANG agents are fragile.

I wouldn't mind removing this and other CLRs, like forbidding empty type
for list keys.

> then it should have no problems whatsoever buffering

I can only repeat: nobody wants to force implementations to support
identifiers of any length.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 05 Apr 2009 22:12:40 +0200

> IMO, this would make the YANG standard much less useful.

I don't think it affects YANG in any way. The role of YANG standard is
to specify what a valid identifier (and, in general, valid YANG module)
is and various memory-related limitations of implementations are
irrelevant to it, as long as they operate with valid YANG modules.

> opinion was 'it depends on the memory available'.

The one char limit was an extreme argument. The point I wanted to make
was that no implementation will become non-conformant just because it
has a fixed limit on identifier length, or doesn't have one, for that
matter.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Apr 2009 13:25:47 -0700

> Andy Bierman píše v Ne 05. 04. 2009 v 06:39 -0700:
....
> identifiers of any length.

I do.
I want to force implementations to support certain minimums,
like those in the ISO-C spec.  I want to insure that all
YANG compilers can support a minimum level of complexity
just like C compilers.  It is unrealistic to think
that all implementations will have unlimited
resources, or have any consistency across implementations.

I cannot cut-and-paste any ISO text, but I will paraphrase it
for YANG, using the same values.  Again, these are the
minimums that an implementation MUST support, and
any behavior beyond that is undefined in the standard:

   127 levels of definition nesting
    63 nesting levels of conditional inclusion (if-feature, when)
    63 significant initial characters in an internal identifier
    31 significant initial characters in an external identifier
  4095 exported identifiers in one module
   511 identifiers with block scope declared in 1 block
  4095 characters in 1 logical source line
  4095 characters in a character string literal (e.g., description, reference)
  1023 cases within 1 choice
  1023 members within a single container or list
  1023 enum/bit constants within a single enumeration or bits data type
    63 levels of nested union definitions within a single type-stmt

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 05 Apr 2009 23:27:38 +0200 (CEST)

Hi,

> I want to force implementations to support certain minimums,
                  ^^^^^^^^^^^^^^^
> like those in the ISO-C spec.

Gerhard asked an important question - what do you mean when you say
"implementation"?  There is a big difference between the NETCONF
server (which implements a YANG module) and a generic YANG tool that
your 'yangdump' (which validates/translates a YANG module).

There is a reason that C99 picked these limits.  The identifier
limit for example was chosen based on what existing linkers could
handle.  Using the same argument for YANG identifiers doesn't seem too
convincing.

Limits were chosen with a target machine of 512K memory in mind.

[see 5.2.4.1 and 6.4.2.1 of
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf]

I think we would make a huge mistake if we blindly copied these limits
into YANG.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Apr 2009 15:45:42 -0700

>> I want to force implementations to support certain minimums,

ANY tool that uses a YANG file as input
is a YANG implementation

            ^^^^^^^^^^^^^^^
> Limits were chosen with a target machine of 512K memory in mind.

good -- that is about the limit for some embedded
NETCONF servers I have in mind.

> I think we would make a huge mistake if we blindly copied these limits

Why? It just sets minimum values,
and nothing else.  Of course your implementation
is encouraged to support more.

I *never* said we must use the same values for the constants,
although I want NETCONF/YANG to be supported on very small
embedded servers, so I do not think these values are
unreasonable for the *minimum* implementation requirements.

The values could be updated.
This thread started because Phil insisted all implementations
of YANG need to support the *same* limits.

This is not actually possible without specification.
Having tools fail randomly based on implementation
strategy does not make a good standard.  We are
producing a standard for NETCONF, not some generic language
for XML.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 05 Apr 2009 17:08:06 -0700

>> I want to force implementations to support certain minimums,

The YANG standard must work 1 of 2 ways:
   - either it is OK for tools for use implementation
     strategies which impose a hard-limit on certain
     aspects of the software design
   - or it is not OK for tools to use implementation
     strategies that impose any hard limits.

If (1), then setting minimum implementation limits
is appropriate for better interoperability.

If (2), then the standard needs to say that implementations
SHOULD NOT restrict any aspect of YANG module contents,
such as identifier length, number of objects, nest level,
number of must or unique statements, size of description
or reference statements, namespace URI, etc.

Simply removing the current text increases confusion,
so that is a bad option.  IMO, leaving the current text
is the best option because we have no operational need
for long identifiers.  In fact, they might even harm
interoperability if they are too unreadable.
Making rules that promote good YANG use are already
being done all over the spec, so singling it out here
does not make much sense.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Apr 2009 10:24:56 +0200 (CEST)

> ANY tool that uses a YANG file as input

[...]

> NETCONF servers I have in mind.

But a NETCONF server is, if I understand your defintion above
correctly, not a YANG implementation.

> unreasonable for the *minimum* implementation requirements.

We share the same goal - I also want *NETCONF* to be supported by
small devices.  But I don't think these limits help much.  A small
device which implements just a few data models may very well be able
to handle one identifier of length 100.  But the same device might not
be able to handle a data model with "one instance of every one of the
limits".

/martin