----- Original Message -----
From: "Ladislav Lhotka" <lhotka(_at_)nic(_dot_)cz>
To: "tom p." <daedulus(_at_)btconnect(_dot_)com>
Sent: Friday, February 26, 2016 1:07 PM
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?
<tp>
Yes, that works for me.
Tom Petch
Thanks, Lada
Tom Petch
<snip>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C