Subject: [netmod] instence-identifier in JSON

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Nov 2014 16:45:54 +0100

Hi,

I would like to verify consensus regarding my proposal to simplify the
JSON encoding of instance-identifier values. The idea is to use the same
rule for namespaces as in the data tree: indicate namespace at the
beginning and then also whenever it changes.

For example, instead of prepending each node name with the namespace ID
(module name)

/ietf-interfaces:interfaces/ietf-interfaces:interface[
    ietf-interfaces:name='eth0']/ietf-ip:ipv4/ietf-ip:ip

we would have

/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip

Kent pointed out after the session that the same rule is also used in
RESTCONF Request URIs.

If anybody is opposed to this change, please speak up.

Thanks, Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Nov 2014 07:54:35 -0800

Hi,

I strongly oppose changing instance-identifier encoding.
It is not compatible with YANG 1.0 and supporting a system
with 2 versions of a fundamental type like instance-identifier
is too complicated.

I fail to see what problem this solves.  It seems to just
create confusion and unwarranted complexity.

Andy

On Tue, Nov 18, 2014 at 7:45 AM, Ladislav Lhotka <[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Nov 2014 17:08:21 +0100

> with 2 versions of a fundamental type like instance-identifier

Well, the current encoding of instance identifiers (namespace ID everywhere) is not compatible with YANG 1.0 either, right?

> create confusion and unwarranted complexity.

The problems it solves are

1. consistency: rules for namespace encoding are identical in the data tree and in instance-identifier.

2. simplification: instance-identifiers in the proposed from are certainly more readable for humans, and only slightly more difficult to parse for machines.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Nov 2014 08:40:49 -0800

> Well, the current encoding of instance identifiers (namespace ID everywhere) is not compatible with YANG 1.0 either, right?

It is encoded in XML with QNames. They use prefixes.
It works just fine and it is valid and correct XPath for the specified instance.

> 1. consistency: rules for namespace encoding are identical in the data tree and in instance-identifier.

It creates inconsistency because YANG 1.0 works differently.

> 2. simplification: instance-identifiers in the proposed from are certainly more readable for humans, and only slightly more difficult to parse for machines.

It creates complexity because 2 forms of instance identifiers would be in use.
Your proposal is not the correct XPath to specify one instance.
It is a YANG-only 1-off creation that no tools support right now.

Andy

---

From: Robert Varga <[email-masked]>
Date: Tue, 18 Nov 2014 17:56:33 +0100

+1. This would be a huge boon to clarity and addresses one major pain 
point OpenDaylight users have been complaining about.

Regarding not being compatible with XML encoding of QNames -- that is a 
fair observation, but given that JSON is an encoding of its own it 
should be possible to define instance identifier encoding which makes 
sense in JSON, without regard what other encodings do.

Thanks,
Robert

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Nov 2014 09:42:38 -0800

Hi,

I was confused because I missed the Friday meeting.
This proposal is not to change the XML encoding in YANG 1.1,
just to add a JSON encoding of i-i. So I do not object.

I prefer the data-resource-identifier encoding in RESTCONF,
since it could be cut-and-pasted as a target resource URI.

NEW:
>> /ietf-interfaces:interfaces/interface=eth0/ietf-ip:ipv4/ip

(encoding used in error-urlpath)

Andy

On Tue, Nov 18, 2014 at 8:56 AM, Robert Varga <[email-masked]> wrote:
> +1. This would be a huge boon to clarity and addresses one major pain point
> OpenDaylight users have been complaining about.
>
> Regarding not being compatible with XML encoding of QNames -- that is a fair
> observation, but given that JSON is an encoding of its own it should be
> possible to define instance identifier encoding which makes sense in JSON,
> without regard what other encodings do.
>
> Thanks,
> Robert
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Nov 2014 21:28:05 +0100

As technical contributor, I am concerned about this design. RFC 6020
section 9.13.3. defines how instance-identifier values are represented
and I think we walk on very thin ice if we allow 'encodings' to come
up with their own (textual) representations of values of core data
types.

I know that 9.13.3 refers to XML namespaces and this does not apply to
JSON and I understand that Lada favors to use a different namespace
identifier in general for JSON.

Every little extra conversion adds complexity.

/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: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Nov 2014 21:59:18 +0100 (CET)

> Every little extra conversion adds complexity.

Do you have an alternative?

I agree with this, and in hindsight we should have picked a different
encoding for i-i (and identityrefs) in YANG.

But here we are and we need to do something for JSON to work.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Nov 2014 13:45:40 -0800

> But here we are and we need to do something for JSON to work.

How is a client going to use i-i in RESTCONF?
We send the 'error-urlpath' in all "errors" responses.
When is i-i really used in data models?

Actually, no tool knows what to do with "modname:foo"
unless it implements draft-ietf-netmod-yang-json.
As long as the underlying syntax is valid JSON,
no matter what is added will have the same impact
on implementations.

We should try to get it right the first time.
IMO the format returned should be easily mapped
to a data resource URI in RESTCONF, so
the data-resource-identifier format should be used,
and generalized if needed.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 18 Nov 2014 20:27:37 -0500

+1

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 08:52:04 +0100

> just to add a JSON encoding of i-i. So I do not object.

That's why the subject was "... in JSON". :-)

> since it could be cut-and-pasted as a target resource URI.

But this would mean departing from i-i definition even further.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 09:08:03 +0100

> encoding for i-i (and identityrefs) in YANG.

Right. The particular form of i-i as defined in RFC 6020 probably follows
from two factors:

- encoding of namespaces in XML - however, the URI/prefix duality was
  identified as one of serious problems of XML [1].

- in XPath 1.0, all QNames have to have explicit prefixes - this problem
  was fixed in XPath 2.0.
  
> But here we are and we need to do something for JSON to work.

... and we needn't necessarily repeat XML mistakes.

Lada

[1] http://blog.jclark.com/2010/01/xml-namespaces.html

(This is a really interesting text written by one of XML gurus that
shows how a sequence of absolutely logical steps can lead to a wrong
solution.)

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 09:18:04 +0100

Hi Robert,

thank you. I think your feedback is valuable because your implementation
is written from ground up for JSON. I suspect the discussions about JSON
encoding (and mandatory encoding for RESTCONF, for that matter) are often
biased by the fact that some implementations already use XML as their
original/primary encoding.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Nov 2014 10:19:35 +0100

> ... and we needn't necessarily repeat XML mistakes.

Lets keep things straight. The XML serialization of YANG defined data
works. I hope we can all agree to that.

If we create additional _encodings_, I think we have to make them work
in terms of interoperability and coverage. RFC 6020 makes assumptions
in several places that the encoding is XML or it is using XML's notion
of namespaces. If we want to support multiple encodings, I think we
need to define the interface of YANG to the encoding systems so that
we can preserve consistency and we know how conversions can be carried
out.

A YANG XML instance identifier that is different form a YANG JSON
instance identifier that is different from a YANG CBOR instance
identifier can't really be the direction to go for. Add to this
RESTCONF resource identifiers and CORECONF resource identifiers that
are again different and confusion will be there. Lets also keep in
mind that data models like ietf-netconf-acm.yang assume that a
node-instance-identifier is a subset of yang:xpath1.0.

Years ago, I worked on SMIng and trying to support different naming
systems led to major problems. We are on a slippery slope to get there
again. As technical conributor, I believe YANG should have a single
naming system and not allow encodings to create their own naming
systems.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Nov 2014 10:23:37 +0100 (CET)

> naming system and not allow encodings to create their own naming

So what is your proposal?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 10:34:10 +0100

> works. I hope we can all agree to that.

It is too soon to agree on that. I wouldn’t be surprised to see implementations relying on, e.g., the “inet” prefix to be always bound to the ietf-inet-types, as it has been commonplace in other XML code.

> we can preserve consistency and we know how conversions can be carried

I think it wouldn’t be too difficult to define YANG infoset independently of any encoding and then add specific rules for each supported encoding. The XML infoset was also defined ex post.

> node-instance-identifier is a subset of yang:xpath1.0.

Instance-identifiers are mostly used as pointers in error messages and such. I think it would be in fact seriously confusing to have a data tree encoded using JSON conventions and I-Is as XPath 1.0.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Nov 2014 10:37:32 +0100

> So what is your proposal?

Here is a proposal: We add a new issue to YANG 1.1 to define the
interface between YANG and YANG encodings. This interface needs to
define how the YANG type system interacts with type systems used by
(typed) encodings. It also needs to define what the YANG naming system
is. And then encodings have to stick to this interface.

Yes, this is primarily a procedural answer. I do not have a detailed
proposal for the various technical questions involved. That said, I
strongly prefer a single YANG naming systems and a consistent way
types are handled across encodings.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 15:14:04 +0100

> is. And then encodings have to stick to this interface.

This sounds like a good plan to me.

> types are handled across encodings.

It is important to be able to convert data between different encodings
but stipulating a complete uniformity would most likely mean giving up
advantages of individual encodings (except one, which has to be XML:-).

Lada