Subject: [netmod] Moving the discussion back toward new concepts

From: Phil Shafer <[email-masked]>
Date: Fri, 24 Jul 2009 16:06:01 -0400

"Linowski, Bernd (EXT-Other - DE/Dusseldorf)" writes:
>For example, mapping of recursive structures is an area where
>things get difficult.
>
>In 3GPP a 3GSubNetwork might contain other 3GSubNetworks, in the SID
>a Hardware instance might contain other Hardware instances.
>Currently, you have to use a leafref-typed leafs to point the
>the parent (and/or the children) to emulate recursive containment.
>This also has the disadvantage that the hierarchy is not visible
>in the NETCONF payload. It also makes filtering based on
>a location in the (conceptual) containment tree formed by recursice
>structures difficult.

This is great stuff.  IMHO you should redo your "motivation" section
into three sections:

(a) Things YANG can't do
(b) Things YANG isn't good at
(c) Things we don't now how to do in YANG

Recursive content belongs in (a).  Give an overview of the issue and
then this example.  Repeat this for all the topics in your motivation
section.  It will go a long way to helping turn your document from
"an alternative means of doing what YANG can do" into "a means of
extending YANG to do what it could not do before".

For example, your "complex types" are a red herring.  The difference
between:

    complex-type ManagedHardware {
        abstract true;
        key object-id;
        leaf objectId { type string { max-length 32; } }
        leaf serialNumber { type string; config false; }
        leaf commonName { type string; }
    }

    complex-type Equipment {
        extends ManagedHardware;
        leaf installed {type boolean; config false; }
        leaf version { type string; }
        leaf redundancy {type uint16; }
    }

    element equipment {
        type Equipment;
    }

and:

    grouping ManagedHardware {
        key object-id;
        leaf objectId { type string { max-length 32; } }
        leaf serialNumber { type string; config false; }
        leaf commonName { type string; }
    }

    grouping Equipment {
        uses ManagedHardware;
        leaf installed {type boolean; config false; }
        leaf version { type string; }
        leaf redundancy {type uint16; }
    }

    container equipment {
        type Equipment;
    }

is near zero.  By introducing equivalent syntax, you've moved the
discussion from concepts you want to add into the realm of "two
equivalent ways to do the same thing".  This is a lose, but for
your ideas and for the working group.

Let's move the discussion back and inspect the real underlaying
issues of things you don't think you can do in YANG, because it's
really hard to see these clearly.

My concern is that most of your issues are related to generating
code and data from YANG modules, rather than real modeling issues.
If you want "ManagedHardware" to be a Java class, say:

    grouping ManagedHardware {
        java:class ManagedHardware {
            java:abstract true;
        }
        key object-id;
        leaf objectId { type string { max-length 32; } }
        leaf serialNumber { type string; config false; }
        leaf commonName { type string; }
    }

Nothing else in YANG needs to change to give you this ability to
fine tune your code generation.

I can see value in standardizing these code generation hooks, but
don't see this justifying the "complex-type" and "element" statements.

If you want polymorphism, adding that can be done with an "isa"
statement (and/or extension function).  If you want recursion, that
change can be made.  But there's no need to invent new mechanisms
for expressing concepts that already exist.  Making users understand
the diferences, overlap, and how to choose between "element" and
"container" is expensive.

Also "element" is a poor choice for a statement, since "element"
is already overloaded.  All XML is encoded in elements, so container,
list, leaf, etc all turn into elements.

I meant to diff your ipfix against the real one, but my guess is
that it's mostly s/grouping/complex-type/.  If you'd used the
existing YANG statements, such a diff might help show what is
won by using your new concepts.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Jul 2009 14:19:35 -0700

Phil Shafer wrote:
....
> really hard to see these clearly.

excellent point.

The problem statement is not well specified,
and (IMO) there is no evidence of any consensus
on this critical prerequisite to meaningful
discussion of solutions.

Why don't we just standardize Python classes
and not bother with a DML at all? (only kidding ;-)

>  Phil

Andy