Subject: [netmod] YANG Metadata Issue: leaf-list

From: Andy Bierman <[email-masked]>
Date: Sun, 19 Oct 2014 09:50:40 -0700

Hi,

I have run into some issues implementing
draft-lhotka-netmod-yang-metadata-00.

(1) The annotations for leaf-list nodes are expensive to implement in
a constrained or streaming-based server.  Every other node type
is easy to stream because all the data can be rendered before
moving on to the next node.  But the leaf-list meta-data follows
all the leaf-list nodes:

   For example, in the following leaf-list instance with four entries,
   the "inactive" annotation is added to the second and third entry in
   the following way:

       "folio": [6, 3, 7, 8],
       "@folio": [
         null,
         {"example-inactive:inactive": true},
         {"example-inactive:inactive": true}
       ]

The server has to remember a lot of state and/or go through the leaf-list
twice.  It is possible that the last node is gone and the next node is
unknown in a streaming server, This could take a lot of resources
for large leaf-lists.

(2) The module-name as prefix is not really needed unless
there are annotations with the same name advertised by the server.

(3) Multiple annotations can be rendered in any order within an array entry:
This should be clarified (and maybe an example).

       "folio": [6, 3, 7, 8],
       "@folio": [
         null,
         {"example-inactive:inactive": true,
           "example:foo":42 },
         {"example:foo":53,
           example-inactive:inactive": true}
       ]

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Oct 2014 12:55:52 +0200

> unknown in a streaming server, This could take a lot of resources

Do you have an alternative proposal? This encoding has an advantage that
the receiving party may just ignore the annotation and nothing alse
changes. If we somehow bundle annotations with each leaf-list entry, it
will be no more the case.

> there are annotations with the same name advertised by the server.

This is true but if the namespace encoding is mandatory, the instance
document needn't change as a side-effect of adding a new module to the
data model. I think this is important because it it not only the server
that potentially adds annotations. If an old client that only knows
about one "foo" annotation always uses the namespace id, it can then
safely ignore a new module advertised by the server, even if it defines
a new annotation with colliding name.

> This should be clarified (and maybe an example).

I think this follows from the fact that JSON objects are unordered by
definition. So the annotation object may precede or follow the annotated
member, and also the order of its members is undefined. 

>            example-inactive:inactive": true}

Lada

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

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Oct 2014 06:57:29 -0700

> will be no more the case.
No, I cannot think of an alternative that preserves the original encoding
and does not require any state to be maintained for previous entries.
I guess my conclusion is that JSON s intended for applications where
the complete data structure is held in memory. It is not meant to be
streamed.

> a new annotation with colliding name.

This is a trade-off. Unfortunately, it make the JSON more verbose.
Why not just use XML if you don't care about verbosity?
The rule is not mandatory for element names, is it?

> member, and also the order of its members is undefined.

OK -- this is supposed to make output simpler I guess, but the unordered
objects
making parsing even more stateful.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Oct 2014 17:41:04 +0200

> the complete data structure is held in memory. It is not meant to be

In general, that's my conclusion, too. On the other hand, I suspect that
only limited parts of any data model are potential candidates for
streaming, e.g. log messages. Perhaps we could think about providing
some form of support for streaming such selected parts, in YANG and/or
the protocol.

> The rule is not mandatory for element names, is it?

For elements (data node instances) the rule has changed in -01 following
Martin's suggestion: a namespace identifier is used if (and only if) the
namespace changes wrt parent node. This encoding is also stable in the
sense that adding a new module to the data model does not change the
instance encoding.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Oct 2014 09:07:27 -0700

> some form of support for streaming such selected parts, in YANG and/or

Streaming applies to way the server outputs the JSON to the client, not
the same as an ever-changing log file.  Almost all operational data,
and even some config data is distributed across the system.
Storing that data (after retrieving it) can have a high cost.

> sense that adding a new module to the data model does not change the

I agree this is better than before.
I wish we could have short module numbers instead of long module names as
prefixes.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Oct 2014 18:25:00 +0200

On 20 Oct 2014, at 18:07, Andy Bierman <[email-masked]> wrote:
> I wish we could have short module numbers instead of long module names as prefixes.

Module names are not that bad and, unlike URIs, they are YANG identifiers. The URI/prefix duality used by XML has its share of problems, too.

Lada