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

[Ladislav Lhotka <[e-mail]>]

> On 26 Feb 2016, at 12:39, tom p. <[e-mail]> wrote:
> 
> <focussing on datastores>
> 
> ----- Original Message -----
> From: "Ladislav Lhotka" <[e-mail]>
> To: "tom p." <[e-mail]>
> Sent: Thursday, February 25, 2016 1:26 PM
> 
> Tom,
> 
>> On 25 Feb 2016, at 13:42, tom p. <[e-mail]> 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