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