Subject: Re: Last Call: <draft-ietf-netmod-yang-json-08.txt> (JSON Encoding of Data Modeled with YANG) to Proposed Standard

From: tom p. <[email-masked]>
Date: Thu, 25 Feb 2016 12:42:03 +0000

In the interests of clarity

- datastores are not mentioned.  These loom large in YANG and NETCONF
and, I think, have been misunderstood by those wishing to extend YANG in
various, new directions.  Therefore I think that the I-D should say
something, even if it is that the concept of datastore is alien to the
envisaged uses of JSON (I could envisage a use where datastores do
apply, but it is probably an unrealistic use:-)

-YANG 1.0 ditto.  I realise that this I-D normatively references YANG
1.1 but there is a lot of YANG 1.0 about.  My sense is that this I-D
cannot work with YANG 1.0, in which case, I think that that needs
stating.

- the examples use the exact same identifiers (foo, bar) to identify an
object and a namespace prefix.  Experts in YANG will know well the many
namespaces in YANG and their scope and so could not posssibly be
confused; but unless the I-D wants to make the point that there are many
namespaces in YANG with different scopes, then I think that the worked
examples should use distinct identifiers.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
Sent: Wednesday, February 24, 2016 2:07 PM

>
> The IESG has received a request from the NETCONF Data Modeling
Language
> WG (netmod) to consider the following document:
> - 'JSON Encoding of Data Modeled with YANG'
>   <draft-ietf-netmod-yang-json-08.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2016-03-09. Exceptionally, comments may
be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document defines encoding rules for representing
configuration,
>    state data, parameters of RPC operations or actions, and
>    notifications defined using YANG as JavaScript Object Notation
(JSON)
>    text.
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Feb 2016 14:26:17 +0100

Tom,

> On 25 Feb 2016, at 13:42, tom p. <[email-masked]> wrote:
> 

I don't understand. This draft is about encoding a data tree in JSON under the assumption that the data tree is valid with respect to a YANG data model. How is this related to datastores? In particular, I don't think the concept of datastores is alien to it in any way (proofs exist to the contrary).

> cannot work with YANG 1.0, in which case, I think that that needs

Right, this I-D references YANG 1.1 because, among other things, it also defines the encoding for "anydata", which is a new YANG 1.1 feature. All other rules are applicable to YANG 1.0. Anyway, I believe all new implementations should use YANG 1.1.

> examples should use distinct identifiers.

This is a valid point. I will change the prefixes to "foomod" and "barmod".

Thanks, Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Feb 2016 14:43:55 +0100

> apply, but it is probably an unrealistic use:-)

I do not see why an encoding document should talk about datastores.
Is there anything unclear how YANG defined data is encoded in JSON? If
not, then this document does its job.

> cannot work with YANG 1.0, in which case, I think that that needs

The JSON encoding works just fine with YANG 1.0. Perhaps this can be
stated explicitly with an informative reference to RFC 6020 if that
helps to avoid confusion.

/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/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Feb 2016 14:47:16 +0100

> On 25 Feb 2016, at 14:43, Juergen Schoenwaelder <[email-masked]> wrote:
> 

OK, this makes sense.

Lada

---

From: tom p. <[email-masked]>
Date: Fri, 26 Feb 2016 11:39:25 +0000

<focussing on datastores>

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "tom p." <[email-masked]>
Sent: Thursday, February 25, 2016 1:26 PM

Tom,

> apply, but it is probably an unrealistic use:-)

I don't understand. This draft is about encoding a data tree in JSON
under the assumption that the data tree is valid with respect to a YANG
data model. How is this related to datastores? In particular, I don't
think the concept of datastores is alien to it in any way (proofs exist
to the contrary).

<tp>

It is the I-D that introduces datastores

"   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis] defines only XML encoding of data trees,
   i.e., contents of configuration datastores, state data, input/output
   parameters of RPC operations or actions, and event notifications.
   The aim of this document is to define rules for encoding the same
   data as JavaScript Object Notation (JSON) text [RFC7159]."

and goes on to give a definition of action and RPC operation but not of
configuration datastore, state data or event notification.  To me, that
looks odd.  The I-D tells me I could take rfc6020bis and replace every
XMP snippet with JSON text and for that, I think I need a knowledge of
datastores!  I suggest adding those three missing definitions to section
2, nothing more.

Tom Petch

<snip>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 26 Feb 2016 14:07:05 +0100

> On 26 Feb 2016, at 12:39, tom p. <[email-masked]> wrote:
> 

OK, so the problem seems to be a missing reference to RFC 6241 where all three terms are defined. Would that be sufficient?

Thanks, Lada

---

From: tom p. <[email-masked]>
Date: Fri, 26 Feb 2016 17:05:05 +0000

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "tom p." <[email-masked]>
Sent: Friday, February 26, 2016 1:07 PM

> datastores!  I suggest adding those three missing definitions to
section

OK, so the problem seems to be a missing reference to RFC 6241 where all
three terms are defined. Would that be sufficient?

<tp>

Yes, that works for me.

Tom Petch

Thanks, Lada