Subject: [netmod] Top-level grouping with nested typedefs and groupings bug (RFC6110)

From: Jernej Tuljak <[email-masked]>
Date: Tue, 06 Nov 2012 15:45:01 +0100

Hi,

RFC6110 says the following:
--------------------------------------------------
8.2.  Modularity

    Named pattern definitions that are mapped from non-top-level YANG
    groupings MUST be placed inside the embedded grammar corresponding to
    the YANG module where the grouping is defined.

10.20.  The 'grouping' Statement

    As explained in Section 8.2, a named pattern definition MUST be
    placed:

    o  as a child of the root<rng:grammar>  element if the corresponding
       grouping is defined at the top level of an input YANG module;

    o  otherwise as a child of the embedded<rng:grammar>  element
       corresponding to the module in which the grouping is defined.

10.54.  The 'typedef' Statement

    This statement is mapped to a RELAX NG named pattern definition<rng:
    define>, but only if the type defined by this statement is used
    without restrictions in at least one of the input modules.  In this
    case, the named pattern definition becomes a child of either the root
    or an embedded<rng:grammar>  element, depending on whether or not the
    'typedef' statement appears at the top level of a YANG module.  The
    name of this named pattern definition is set to ARGUMENT mangled
    according to the rules specified in Section 9.2.
--------------------------------------------------

If this text is strictly followed a syntactically incorrect hybrid RNG 
schema will get generated by an implementation in case a grouping or a 
typedef is defined within the subtree of a used top-level grouping. One 
will end up with a global definition which references named patterns 
from local (embedded) grammars. This cannot be done in RNG.

After global definitions get separated into a separate include file it 
breaks completely. A standalone RNG grammar needs all referenced 
definitions in the same grammar (through local definitions or included 
ones).

I fixed this in our implementation by treating any typedef or a grouping 
located within a used top-level grouping as a global definition but 
Ladislav suggested, that this may lead to name clashes (I agree). 
However I believe this could be solved with another name-mangling rule 
in section 9.2 which handles this special corner case. Example (module 
"test"):

typedef g1 { ... }

grouping g1 {
     container foo {
         grouping inner {
              ...
         }
         typedef inner { ... }
         ...
     }
}

container g1 {
     container foo {
         grouping inner {
             ...
         }
        typedef inner { ... }
         ...
     }
}

When "g1" grouping gets used and module "test" is also an input module:

test__g1 (global rng:define for the top-level typedef)
_test__g1 (global rng:define for the top-level grouping)
_test__special_prefix__g1__foo__inner (global rng:define for first inner 
grouping)
test__special_prefix__g1__foo__inner (global rng:define for first inner 
typedef)
_test__g1__foo__inner (local rng:define for second inner grouping)
test__g1__foo__inner (local rng:define for second inner typedef)

There is no way to define another top-level schema node, grouping or 
typedef named "g1" in this module, so it should be okay. I could be 
missing something though. This also exposes internal definitions which 
may not be what a YANG modeler would want.

This is how our implementation currently does it.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 06 Nov 2012 10:45:17 -0500

Hi Jernej,

good catch, it is indeed a bug. I think your proposed solution with additional name mangling might work but we have to consider and test the various corner cases.

Anyhow, this bug cannot be dealt with through errata because the required change to the mapping procedure is significant. So this needs to be fixed in a future revision of RFC 6110.

Thanks, Lada
 
Jernej Tuljak <[email-masked]> writes:

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C