ietf
[Top] [All Lists]

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

2016-02-26 07:07:13

On 26 Feb 2016, at 12:39, tom p. <daedulus(_at_)btconnect(_dot_)com> wrote:

<focussing on datastores>

----- Original Message -----
From: "Ladislav Lhotka" <lhotka(_at_)nic(_dot_)cz>
To: "tom p." <daedulus(_at_)btconnect(_dot_)com>
Sent: Thursday, February 25, 2016 1:26 PM

Tom,

On 25 Feb 2016, at 13:42, tom p. <daedulus(_at_)btconnect(_dot_)com> wrote:

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:-)

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.

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


Tom Petch


<snip>

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