Subject: [netmod] namespace URI length

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

Hi,

RFC 2396 is silent about URI length (as one would expect).

RFC 2068, sec. 3.2.1 (HTTP 1.1) says:

      Note: Servers should be cautious about depending on URI lengths
      above 255 bytes, because some older client or proxy implementations
      may not properly support these lengths.

Clearly the same issue exists for namespace URI as identifier length,
only worse, because a tool is allowed to accept 1 char URIs and
be considered compliant. YANG writers provide the URI value directly,
and they need to know every compiler will always accept (or reject)
a given length URI.

IMO, "MUST support 1 to 1024 characters" should be sufficient.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 6 Apr 2009 08:23:39 -0400

>IMO, "MUST support 1 to 1024 characters" should be sufficient.

Section 3.2.1 of rfc 2068 also says:

   The HTTP protocol does not place any a priori limit on the length of
   a URI. Servers MUST be able to handle the URI of any resource they
   serve, and SHOULD be able to handle URIs of unbounded length if they
   provide GET-based forms that could generate such URIs. A server
   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
   than the server can handle (see section 10.4.15).

This paragraph appears directly above the paragraph you quoted.

We can add HTTP to the list of example protocols with an unbounded
limit that can be implemented on machines with finite memory.
Heck, since NETCONF uses URIs and URIs have no length limit, we
can add NETCONF to that list also.

Would defining an error code (identifier-too-long) be a reasonable
resolution?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Apr 2009 14:48:35 +0200 (CEST)

> Would defining an error code (identifier-too-long) be a reasonable

But this is not a protocol issue.  Either your device supports a given
data model with its identifiers and URI, or it doesn't.  This whole
debate has nothing to do with how NETCONF *servers* should behave, but
what generic YANG tools (such as 'yangdump', 'pyang', 'smidump')
should do.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 6 Apr 2009 08:49:47 -0400

>what generic YANG tools (such as 'yangdump', 'pyang', 'smidump')

Yup, and such tools are always build tools or clients, so the error
wouldn't make much sense.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 06 Apr 2009 15:06:17 +0200

> wouldn't make much sense.

Yes, and moreover these tools are run on general computers where the
fixed size limits make even less sense.

Lada

> 
> Thanks,
>  Phil
> _______________________________________________
> 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: Mon, 06 Apr 2009 07:45:52 -0700

>    than the server can handle (see section 10.4.15).

The very next sentence in RFC 2068:

But this issue is about YANG the DML, as used by NETCONF.
I find the XML arguments to be irrelevant.
YANG removes lots of features from XML that
are not desirable in NETCONF.  Infinite length
identifiers are no different the mixed content
or XML attributes in this regard.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Apr 2009 08:13:57 -0700

> what generic YANG tools (such as 'yangdump', 'pyang', 'smidump')

If the agent consumes YANG/YIN files directly, then IMO
it is a YANG application.  But in this case, the
agent would not be able to return any error except
in the logfile during a reboot.

IMO, a sentence on translation limits is useful.
Except you can't say an implementation MUST NOT run out
of memory.  So those C99-style minimum maximums are
just guidelines anyway, since available memory
during an invocation of the tool is unknown.

In real code, the tool can just emit
a 'resource-denied' error no matter what really happened
(e.g., hard limit on foo-stmt reached).  There is no
way to enforce a "no hard-limits CLR".

I understand your point about other YANG statements.
Since must-stmt is defined in the ABNF as unbounded,
I implemented it as a queue of structs.  But only
1 when-stmt is allowed so that is a pointer, not a queue.
Whatever the spec says will determine what code is used.
If the identifier rule was written differently, I would
change the 1 line of code related to identifier length
and move on.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 6 Apr 2009 11:18:09 -0400

>      may not properly support these lengths.

Yes, this is the one you quoted, but you didn't quote the bit about
"SHOULD be able to handle URIs of unbounded length".  The good news
is that YANG and NETCONF need not concern themselves with "older
client or proxy implementations", so the "Note" doesn't affect us.

>I find the XML arguments to be irrelevant.

My point was that URIs in XML are not limited in length so the value
of the "xmlns" attribute does not have a length limit.  This is
true for NETCONF as well; elements in NETCONF are allowd to have
monstrously long URIs.  Unbounded strings are not new, and there
are many other memory-related issues that have already been mentioned
on this thread.

>or XML attributes in this regard.

No, this simply isn't true.  We avoid specific features of XML for
specific reasons.  Mixed content makes data manipulation difficult
in languages like XSLT;  attributes have namespace issues.  There
are concrete reasons we avoid them.

Lacking such a reason here, why do we need a CLR to limit identifier
length?

This has become a very repetative debate.  Since neither you nor I
are adding anything more, would the WG chairs please kindly consider
calling for a concensus or finding another way to put this issue
to bed?  This is too small an issue to eat this much time and space.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Apr 2009 08:39:52 -0700

> to bed?  This is too small an issue to eat this much time and space.

OK, You wore me down (as usual).
I don't care anymore.  Remove the CLR.
I'm going to put a paragraph in the YANG usage guidelines
draft about 'SHOULD NOT exceed 64 characters' and why.
Since no WG in the history of the IETF has ever even
wanted an identifier over 64 chars, this will probably
not even get read, let alone cause any problems.

Andy