Subject: [YANG] YANG syntax

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Mar 2008 11:58:18 +0100

Hi,

here are my comments and questions on YANG syntax and its description in
the -02 draft:

- An unquoted + is allowed as a string parameter. I think this is too
fragile as + can appear in numbers and also as a concatenation operator.
I suggest to require isolated + to be quoted.

- The draft should probably clearly specify that recursive containment
is not allowed.

- Can a submodule use definitions from its parent module - automatically
or via "include"?

- Production rules for all statements except module and submodule are
labelled "<keyword>-stmt". For the sake of consistency, the rules for
module and submodule should be renamed to module-stmt and
submodule-stmt.

- Is it necessary to keep meta-stmts and submodule-meta-stmts distinct?
Their productions are identical.

- float-value requires a sign ("+/"-") in the exponent, pyang allows
floats like 6.022E23. Maybe the sign should be made optional?

- The "boolean" type in W3C and RELAX NG datatype libraries allow as
values either true/false or 1/0. Would it be a problem to allow this in
YANG, too?

- I don't really understand the keyref statement and its path
expression. An example would be helpful.

- bit-stmt - all substatements are optional but braces are required.

- presence keyword is missing in Table 30 in App. B.

- unique-arg  should have "1*SP" instead of "1*sp"

- descendant-schema-nodeid should be an alternative?
  descendant-schema-nodeid
                       = node-identifier /
                         absolute-schema-nodeid

- What is the role of unknown-statement in stmtsep and stmtend?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

_______________________________________________
YANG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/yang

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Mar 2008 14:53:04 +0100 (CET)

Hi,

Thank's for the feedback!

> I suggest to require isolated + to be quoted.

It's not only isolated + signs, but also if the string itself includes
a + sign:
    
    "1 + 2"  // ok
    1 + 2    // nok
    
The simplest way would be to always require a + within a string to be quoted:

  If a string contains any whitespace characters, a semicolon (";"), a
  plus sign ("+"), curly braces ("{ }"), or comment sequences ("//",
  "/*", or "*/"), then it MUST be enclosed within double or single
  quotes.

But that means that:

   default +1;    // nok
   default "+1";  // ok

This would mean that a + sign either in isolation or within a string
must be quoted.

I think I prefer the simple rule.  Any comments?

> - The draft should probably clearly specify that recursive containment

Ok.  I'll try to write some text.

> - Can a submodule use definitions from its parent module - automatically

No.  You can never include a module (just submodules).

> module and submodule should be renamed to module-stmt and

Fixed.

> Their productions are identical.

No reason.  Fixed.

> floats like 6.022E23. Maybe the sign should be made optional?

Yes I think so.  This is supported by the standard strdtoX functions.
Any comments?

> values either true/false or 1/0. Would it be a problem to allow this in

I'll pass on this and see if Juergen will comment.

> expression. An example would be helpful.

Do you need more than what's in 8.8.4?

> - bit-stmt - all substatements are optional but braces are required.

Fixed.

> - presence keyword is missing in Table 30 in App. B.

Fixed.

> - unique-arg  should have "1*SP" instead of "1*sp"

Yes, but it is actually valid ABNF (by accident!) since rule names are
case insensitive.

But I think it should be "sep" instead of "1*sp".   That also
allows newlines, just like key-arg.   Alternatively, both key-arg and
unique-arg should use "1*SP", and if you want newlines you can use
string concatenation.

> - descendant-schema-nodeid should be an alternative?

No, if it is absolute it is not descendant.  descendant-schema-nodeid
means that it is a relative w/o leading dots, i.e. it reference
soemthing below the current point.

> - What is the role of unknown-statement in stmtsep and stmtend?

It covers extension statements.  The grammar must allow e.g.:

  description "bla bla" {
    my-ext:type "cli-help";
  }

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Mar 2008 15:17:06 +0100

> I'll pass on this and see if Juergen will comment.

Allowing multiple representations for a given value of a type adds
quite some complexity since we then have to say what is the canonical
representation for comparisons and we have to explicit whether or when
implementation have to remember which representation was used. So I am
a big fan of one representation per value and since a a boolean type
has just two values, the boolean YANG type only has "true" and
"false".

/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/>
_______________________________________________
YANG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/yang

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Mar 2008 07:33:16 -0700

> I think I prefer the simple rule.  Any comments?

I prefer to leave the string encoding rules the way they are.
The differentiator is whether the string contains whitespace,
curly braces, or a start of comment.  A no-whitespace string
is OK in YANG, which is a pain to parse, but easier on the user.

Equivalent:
    default 1+3;  //  ok
    default "1+3"; // ok
    default "1+" + "3";  //ok

Legal:
    config "fa" + "lse";  //ok
    range min..max;  // ok
    type min..max;   // ok but now an ID not 3 tokens

The '+' operator needs to be unquoted and also needs to be
isolated (in whitespace), to be a concat operator, not a plus sign.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Mar 2008 15:45:38 +0100

> isolated (in whitespace), to be a concat operator, not a plus sign.

But you can have for example

description + ;

where the + is not an operator. I think this should be avoided.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Mar 2008 08:03:29 -0700

> where the + is not an operator. I think this should be avoided.

So a '+' by itself (not within quotes) would have to be quoted.
My parser does not break up the character stream into

    (keyword  [string]  stmt-end)

sequences like the YANG document defines, which creates corner
cases like this one.  But if it did, your example would not be
hard to parse at all.  Since the 'string' portion of the tuple
is clearly just 1 token (+), there is nothing to concatenate.

Also, since unquoted strings are not concatenated, and keywords and
tokens like ';' can never be quoted, the corner-case above isn't
really a problem.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Mar 2008 08:41:24 -0700

Martin Bjorklund wrote:
>....

Should there be some new text explaining some submodule details more clearly:

  - submodules must be self-contained -- if a foreign symbol is
    encountered (e.g., type or grouping name) then it must be
    found through the import or include mechanisms.

  - since a sub-module can never import or include its parent(s),
    it cannot use any definitions from those files.

  - the one exception to this rule is the module prefix, which
    may optionally be used within its submodules.  (This means
    a compiler parsing a sub-module must also partially parse
    the top module, via the belongs-to clause, to get the module prefix).

  - all submodule definitions are conceptually at the 'top' level, even if
    they are located in deeply nested submodules.  The submodule structure
    may be hierarchical, but the exported definitions are associated only
    with the module, not the submodule.  The 'export tree' is the conceptual
    union of the module and all submodules.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 29 Mar 2008 09:20:38 +0100

>    default "+1";  // ok

That's actually another thing I wanted to mention: if I read the grammar
correctly, +1 is not a valid number - the plus sign is not allowed. I
think it should be.

> Do you need more than what's in 8.8.4?

Oh, sorry, I confused the literal "/" with ABNF operator / in
path-key-expr. I have to correct it in the YIN schema.
 
> unique-arg should use "1*SP", and if you want newlines you can use

I vote for 1*sep.

> soemthing below the current point.

The descendant-schema-nodeid now doesn't allow a single node-identifier,
it must be at least node-identifier "/" node-identifier. So the rule
should probably be

descendant-schema-nodeid
                       = node-identifier
                         [absolute-schema-nodeid]

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C