Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Sep 2015 10:46:10 +0200

Hi,

this revision introduces no changes to the encoding rules. The text was modified, and hopefully improved, in quite a few places, mainly due to Juergen’s review of -04, thanks Juergen.

Lada 

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-ietf-netmod-yang-json-05.txt
> Date: 10 Sep 2015 10:40:21 CEST
> To: "Ladislav Lhotka" <[email-masked]>, "Ladislav Lhotka" <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-netmod-yang-json-05.txt
> has been successfully submitted by Ladislav Lhotka and posted to the
> IETF repository.
> 
> Name:		draft-ietf-netmod-yang-json
> Revision:	05
> Title:		JSON Encoding of Data Modeled with YANG
> Document date:	2015-09-10
> Group:		netmod
> Pages:		20
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-json-05.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-netmod-yang-json-05
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-json-05
> 
> Abstract:
>   This document defines encoding rules for representing configuration,
>   state data, RPC operation or action input and output parameters, and
>   notifications defined using YANG as JavaScript Object Notation (JSON)
>   text.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Sep 2015 08:41:48 +0200

> this revision introduces no changes to the encoding rules. The text was modified, and hopefully improved, in quite a few places, mainly due to Juergen’s review of -04, thanks Juergen.

Lada, a suggestion and a question concerning anydata. The text
currently says:

   Anydata data node is a new feature in YANG 1.1.  It serves as a
   container for an unknown set of nodes that however appear as normal
   YANG-modeled data.  A data model for anydata content may or may not
   exist at run time.  In the latter case, no universal mapping between
   JSON- and XML-encoded instances is available.

The suggestion is to rewrite the text to be more inline with the YANG
1.1 definition of anydata (and I do not think it matters to highlight
that anydata is a YANG 1.1 thing, the document also mentions actions
without saying this is a YANG 1.1 feature).

   An anydata data node can contain an unknown set of nodes that
   can be modelled by YANG. A data model for anydata content may or may not
   exist at run time.  In the latter case, no universal mapping between
   JSON- and XML-encoded instances is available.

My question is why the text is silent about the case where the data
model is present. Should it not say that if the data model is present,
the data encoded inside the anydata node must follow the rules of this
document? Perhaps this is the implicit assumption but I think it will
be useful to say this explicitly (if we agree on this).

If the data model is not present, then I think an implementation is
still expected to produce an encoding that follows the rules of this
document as much as possible except that things that requires data
model knowledge may be encoded differently (e.g., numbers appearing as
strings or namespace names being different). I am thinking along the
lines of this proposed new text:

   An anydata data node can contain an unknown set of nodes that can
   be modelled by YANG. A data model for anydata content may or may
   not exist at run time.  If the data model for anydata content is
   available, then the anydata content MUST be encoded according to
   the rules of this specification. If the data model for anydata
   content is not available, the encoding MUST follow the rules of
   this specification except for rules that require data model
   knowledge (and as a consequence, numbers may appear as strings or
   namespace qualifiers may not match module names).

/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: Tue, 15 Sep 2015 09:31:58 +0200

> be useful to say this explicitly (if we agree on this).

If we do agree on this, then IMO 6020bis is the right place to state it
because this rule should hold for any encoding. 

> document as much as possible except that things that requires data

I tried to specify these rules in the four bullets in sec. 5.5. Do you
think something else is needed?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Sep 2015 17:26:04 +0200

> because this rule should hold for any encoding. 

Perhaps 6020bis should state this but for the sake of completeness I
think it is desirable that encoding specifications are clear about
this as well.

> think something else is needed?

I think the text in 5.5 allows more than the rest of the YANG encoding
in JSON specification. I think content should carry modules names etc.
and not just be I-JSON with some additional rules. For example, the
bullets do not require me to encode module names. I think this is not
good.

/js