Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-00.txt

From: [email-masked]
Date: Tue, 22 Apr 2014 00:01:45 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : JSON Encoding of Data Modeled with YANG
        Author          : Ladislav Lhotka
	Filename        : draft-ietf-netmod-yang-json-00.txt
	Pages           : 20
	Date            : 2014-04-21

Abstract:
   This document defines rules for representing configuration and state
   data defined using YANG as JSON text.  It does so by specifying a
   procedure for translating the subset of YANG-compatible XML documents
   to JSON text, and vice versa.  A JSON encoding of XML attributes is
   also defined so as to allow for including metadata in JSON documents.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Apr 2014 10:05:02 +0200

Hi,

I made the YANG-JSON draft into a WG item. The most significant change in the contents is sec. 4 that attempts to define an encoding for attributes.

Lada

Begin forwarded message:

> From: [email-masked]
> Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-00.txt
> Date: 22 Apr 2014 09:01:45 GMT+2
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Apr 2014 10:20:22 +0200 (CEST)

Hi,

Ladislav Lhotka <[email-masked]> wrote:
> Hi,
> 
> I made the YANG-JSON draft into a WG item. The most significant change
> in the contents is sec. 4 that attempts to define an encoding for
> attributes.

Thank you; I think this new section makes this encoding much more
useful.

One nit:  s/nil/null/ in section 4.

One question:

  In section 4 you write:

   The encoding of attributes as specified above has the following two
   limitations:

   o  Mapping of namespaces of XML attributes is undefined.

   o  Attribute values can only be strings, other data types are not
      supported.

Is the last bullet really a limitation?  XML attributes are always
encoded as "strings", and this JSON encoding just mimics that.

Or put differently, are there any XML attributes that cannot be
mapped, because of this?

Maybe we should also note that xmlns attributes are NOT mapped?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Apr 2014 11:15:42 +0200

> One nit:  s/nil/null/ in section 4.

Oh yes. Lisp is closer to my heart than JavaScript. :-)

> encoded as "strings", and this JSON encoding just mimics that.

So is element content. Schema languages allow to define other types for attributes, and if we add the ‘attribute’ statement in YANG 1.1 (see issue Y33), I can imagine it would also define a type, and this could be reflected in JSON. 

> Maybe we should also note that xmlns attributes are NOT mapped?

Maybe, although it probably cannot cause any harm if they are mapped.

Thanks, Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 22 Apr 2014 12:02:27 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> So is element content. Schema languages allow to define other types
> for attributes, and if we add the ‘attribute’ statement in YANG 1.1
> (see issue Y33), I can imagine it would also define a type, and this
> could be reflected in JSON.

Right.  But then the limitation is that attribute values are always
encoded as strings, regardless of the underlying type.  I.e., they
_are_ supported, but encoded as strings.

> Maybe, although it probably cannot cause any harm if they are mapped.

True; but it would be noise.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 22 Apr 2014 14:32:53 +0200

> _are_ supported, but encoded as strings.

Yes.

> True; but it would be noise.

OK, I’d suggest to put an appropriate “SHOULD NOT” to the text.

Lada