Subject: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 02 Sep 2014 12:23:37 +0200

On 26/08/14 22:49, Andy Bierman wrote:
>
> Perhaps the co-chairs should decide how to proceed somehow.

Dear NETCONF WG participants, do you have an opinion?

So far I have seen only a few people express their opinion.

Please speak up so that we (WG chairs) have better data to judge if we
do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014.

Please speak your mind about these options:

a) XML is mandatory
b) JSON is mandatory
c) XML and JSON are both mandatory
d) Both XML and JSON mandatory on client,
    server can implement whatever it chooses.
    Not clear yet how the client would find out, but that would of course
    be something to be worked out if we choose this option

Bert

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 2 Sep 2014 12:54:10 +0200

>   server can implement whatever it chooses.

I vote for d), but obviously the server has to choose at least one of XML or JSON.

>   be something to be worked out if we choose this option

Yes.

Lada

> 
> Bert
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

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

---

From: David Bannister <[email-masked]>
Date: Tue, 2 Sep 2014 06:59:56 -0400

D, need both with the option to choose as stated below.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Sep 2014 13:18:45 +0200 (CEST)

>    be something to be worked out if we choose this option

I prefer (a).

I prefer (a) over (b) for the technical reasons already mentioned.

(c) is not good for constrained environments.

(d) means we raise the bar for implementing clients.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 2 Sep 2014 14:32:19 +0000

I prefer (d), but am OK with (a)

Neither (b) nor (c) are viable options IMO.

K.

---

From: Radek Krejčí <[email-masked]>
Date: Tue, 02 Sep 2014 16:32:42 +0200

Hi,

I prefer (a), but I'm ok with (d)

Radek

-- 
Radek Krejci
mobile  : +420 732 212 714
office  : +420 234 680 256
e-mail  : [email-masked]
LinkedIn: http://www.linkedin.com/in/radekkrejci

CESNET
Association of Legal Entities
160 00 Praha 6, Zikova 4
Czech Republic

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 2 Sep 2014 07:39:50 -0700

(d)

---

From: Andy Bierman <[email-masked]>
Date: Tue, 2 Sep 2014 07:46:24 -0700

Hi,

1st choice: d
2nd choice: a

Andy

---

From: Xiang Li <[email-masked]>
Date: Tue, 02 Sep 2014 11:07:46 -0500

I prefer a) , and then d).

--Xiang

-- 
--
Xiang Li,
Seguesoft, Champaign, IL
(217) 721-5341

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Tue, 2 Sep 2014 16:57:17 +0000

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 2 Sep 2014 17:00:36 +0000

Option (d) seems preferable to me.
--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Bert Wijnen (IETF)
Sent: Tuesday, September 02, 2014 3:24 AM
To: Netconf
Subject: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity

Please speak up so that we (WG chairs) have better data to judge if we do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014.

a) XML is mandatory
b) JSON is mandatory

Bert

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 2 Sep 2014 13:58:28 -0400

I prefer a) - the idea is to standardize for interoperability, and XML is
already the standard for netconf.
b) changes the whole Netconf direction, and might justify having
restconf+json be a separate WG from Netconf, subject to IETSG/IETF approval
of yet another protocol for the same purpose.
c) is too heavy weight for servers.
d) creates complexity, and a potential for non-interoperability.

I have a question about d), motivated by my background in NMS development.
What are the potential problems for the NMS of having to collect the
information model using different data models, to manage a heterogeneous
network?
The data models are obviously different; are the Information Models
guaranteed to be exactly the same?
If a client talks to two implementations of the same information model, one
server supports XML and the other supports JSON, and the client compares the
configurations and operational state; all else being equal, will the two
variations report exactly the same information (in all cases), and support
configuration using the same IM knobs (in all cases), or will these actually
be two slightly different information models? 
You could also ask this question for one server supporting both XML and
JSON; if the client accesses the data using XML and also using JSON, will
the data be exactly the same information model, or will there be differences
due to data modeling constraints? (We already face this with the MIB/YANG
modeling variations; do we need more close-but-not-quite-the-same
information models?)
Can a client talking to two implementations, one that supports XML and
another that supports JSON, use information validation, such as ranges and
datatypes, that would be identical across the two interfaces? I am thinking
of an NMS that collects data using these interfaces; it validates the XML or
JSON formatting/structure, then puts the values into a database, where it
then uses data-model-independent code to perform validation of the
information model, independent of the format used to transport the data, (OR
it imports one or the other data model to perform  validation of
**information value/range/datatype/etc.** based on having imported, say, the
XML version of the information model). 

David Harrington
[email-masked]
+1-603-828-1401
> Sent: Tuesday, September 02, 2014 6:24 AM
> To: Netconf
> Subject: [Netconf] WG Last Call (expires Sept 18 2014): express your
opinion
> on RESTCONF modularity

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Sep 2014 22:19:04 +0200

David,

I am not sure you understand the details of the technical
background. The YANG data model is the same in both encodings. There
might be technical issues because of the way the JSON mapping is
defined right now but hopefully the next revision will have those
fixed. Since the data model is the same, the information model is
going to be the same as well. I do not understand your concerns.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Sep 2014 22:24:01 +0200

>    be something to be worked out if we choose this option

I have neither implemented a server nor a client. That said, I think I
prefer a) because having less options improves interoperability (I am
old school on this). I also note that the JSON encoding is not final
yet and depending on how some of the details are resolved, I may be OK
with d) or not. The question is how much complexity is added to a
client for supporting both XML and JSON. If the JSON mappings requires
that all clients are able to dynamically parse and interpret YANG
models, I am going to be strictly against d).

Sorry for a complicated answer.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 2 Sep 2014 13:59:53 -0700

> models, I am going to be strictly against d).
I do not understand your last sentence.
We expect a compliant server to implement the entry points and monitoring
data
defined in the draft.  The client MUST understand at least the static API
data,
such as /restconf/modules.  The client could also put its preferred encoding
in the Accept header for a GET request and see if the server responds with
406 Not Acceptable.
This does not require any YANG parsing.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Sep 2014 23:12:39 +0200

On Tue, Sep 02, 2014 at 01:59:53PM -0700, Andy Bierman wrote:
> I do not understand your last sentence.  We expect a compliant
> server to implement the entry points and monitoring data defined in
> the draft.  The client MUST understand at least the static API data,
> such as /restconf/modules.  The client could also put its preferred
> encoding in the Accept header for a GET request and see if the
> server responds with 406 Not Acceptable.  This does not require any
> YANG parsing.

Option d) says that client has to be able to try both JSON and
XML. This means the client must be able to 'transform' the two
encoding into a common internal representation. If, for example, one
encoding uses URIs to identify namespaces while the other encoding
uses module names or one encoding requires type information to be
available while the other does not, then I _expect_ this adds
significant complexity. The current JSON I-D (as far as I understand
it) does not allow a simple 'stateless' (means data model agnostic)
transformation between the two encodings.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 2 Sep 2014 14:31:10 -0700

> transformation between the two encodings.
But using the reply message from the server is an implementation detail
no matter what encoding is used.  An XML or JSON document in RESTCONF is a
serialized
encoding of some data structures.  If the client wants the data to be
hierarchical,
then it has to be converted to something else.

There are issues with the JSON draft that need to be addressed, but that is
a different topic.
IMO it is OK to restrict RESTCONF XML to the same printable characters as
JSON.
That's what NETCONF does wrt/ mixed mode XML. (No rewrite to XML needed).

/js

Andy

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 2 Sep 2014 15:11:39 -0700

Agreed. I've coded a client and do not use the data from the server "as 
is". Internally I use other data structures and therefore transform the 
data into something else.

On 9/2/14 2:31 PM, Andy Bierman wrote:
>
>
>
> On Tue, Sep 2, 2014 at 2:12 PM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > [email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
> no matter what encoding is used.  An XML or JSON document in RESTCONF 
> is a serialized
> There are issues with the JSON draft that need to be addressed, but 
> that is a different topic.
> IMO it is OK to restrict RESTCONF XML to the same printable characters 
> as JSON.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 2 Sep 2014 20:11:02 -0700

Hi,

I added the issue in the issue tracker.
We do not plan to use the tracker for discussion.
It will capture significant events for each issue.
The WG will be added as an email recipient soon so manual notices
like this one will not be needed.

https://github.com/netconf-wg/restconf/issues/7

Andy

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 2 Sep 2014 22:11:06 -0700

Prefer a).

Mahesh Jethanandani
[email-masked]

> On Sep 2, 2014, at 3:23 AM, "Bert Wijnen (IETF)" <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Sep 2014 08:10:16 +0200

On Tue, Sep 02, 2014 at 02:31:10PM -0700, Andy Bierman wrote:
> But using the reply message from the server is an implementation
> detail no matter what encoding is used.  An XML or JSON document in
> RESTCONF is a serialized encoding of some data structures.  If the
> client wants the data to be hierarchical, then it has to be
> converted to something else.

As of today, I can't translate XML encoding to JSON encoding and vice
versa without having access to some information defined in YANG
modules. I believe this raises the bar for certain implementations.

If my client API (e.g. ncclient) exposes values as untyped strings
(the way things are encoded in NETCONF, which uses XML) to higher
layers, then adding support for JSON encoding adds complexity since
now I need at least access to some type information and I need to be
able to map different namespace identifiers (URIs and module
names). Yes, this is an implementation detail but I would not want to
add this complexity to something like ncclient.

Anyway, I provided an answer plus a reasoning. There is no need to
agree on it.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 03 Sep 2014 12:45:10 +0200

Hi Dave,

> guaranteed to be exactly the same?

I am not sure it is correct to talk about different data models if the
difference is only in encoding. The data model, expressed in YANG, is
the same.

> be two slightly different information models?

The ietf-netmod-yang-json draft tries hard to make sure it is the
case. And it should be, except a few corner cases, such as ambiguous
unions, that are currently being discussed in the NETMOD mailing list.
 
> XML version of the information model).

Currently the only validation I can do is using DSDL schemas. For JSON
encoding, I first translate JSON to XML using pyang's jtox plugin and
then perform the validation. I have tried it with a number of data models
and example instance documents, and it seems to work fine.

Lada

---

From: [email-masked]
Date: Wed, 03 Sep 2014 07:00:39 -0400

Nope. Or at least my judgment was for d). Let's talk.

From my thumb or too.

From: Mahesh Jethanandani

Sent: Wednesday, September 3, 2014 01:11

To: Bert Wijnen (IETF)

Cc: Netconf

Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity

Prefer a).

Mahesh Jethanandani
[email-masked]

a) XML is mandatory
b) JSON is mandatory

Bert

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 03 Sep 2014 13:07:51 +0200

> modules. I believe this raises the bar for certain implementations.

That's a feature, not bug. :-)

But what's much more important, and a source of some confusion, is that
the yang-json draft is NOT primarily about translating XML to JSON and
back! Its main point is to define JSON encoding for YANG-modelled data,
and it does so by means of the XML-JSON mapping, simply because it's
easier given that the XML encoding is precisely defined in RFC 6020.

Imagine there ain't no XML and 6020 explicitly defines only JSON
encoding. Do you think the JSON encoding for

leaf foo {
  type uint16;
}

should then be

"foo": "42"

In my view, it could happen that JSON becomes prevalent, and in this
case option a) wouldn't make much sense.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Sep 2014 14:01:49 +0200

> case option a) wouldn't make much sense.

You argue that (a) using two different ways to identify namespaces
(URIs vs module names) and (b) using two different encodings where one
is carrying everything as a string while the other carries _some_ type
information is a feature.

I pointed out that (a) falls flat for anyxml encoding - you argue that
does not matter since anyxml can be treated as the implementor likes
anyway, which I find problematic. Others pointed out that (b) may lead
to issues with unions so we already need to install an expection for
unions (and large numbers we need as strings as well). I argue that
the requirement to have type information available and module name to
URI mapping information available to support both encoding adds
complexity.

So is it a feature or a bug? Since there is RFC 6020 and NETCONF is
using XML, answering a hypothetical question does not help us much
to resolve our different views on this.

/js

---

From: ian duncan <[email-masked]>
Date: Wed, 3 Sep 2014 08:07:05 -0400

Hello ---

Apologies to Mahesh & the entire list.

My intended as private message but defeated by fumbled finger on a bad
phone UI and inadequate caffeination.

Best .. Ian

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 03 Sep 2014 21:21:18 +0200

thanks Andy.

Bert

On 03/09/14 05:11, Andy Bierman wrote:
> On Tue, Sep 2, 2014 at 3:23 AM, Bert Wijnen (IETF) <[email-masked] <mailto:[email-masked]>> wrote:
>
>     _________________________________________________
>     Netconf mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Sep 2014 09:02:41 +0200

> information is a feature.

It's simpler - I argue that draft-ietf-netmod-yang-json provides quite a
natural JSON encoding for instances of YANG data nodes. It was not my
goal to develop an "XML compatibility" profile for JSON. Having some
data type information already in the encoding can hardly be seen as a
drawback.

A module name is a way better namespace identifier than an URI, and we
are lucky to have it. I don't think it could pose any problems because
module names and corresponding URIs mostly appear together - in modules,
hellos, IANA registry.

> does not matter since anyxml can be treated as the implementor likes

It seems the purpose of anyxml/anydata needs to be reconsidered on a
more general level. We can then return to its XML/JSON encoding.

> unions (and large numbers we need as strings as well). I argue that

I don't agree that values of the union type should always be encoded as
strings in JSON, we just have to find a solution for some corner cases.

As for large numbers, the proposal to encode them as strings is only an
ugly workaround for inferior JSON parsers. Another option would be to
recommend implementors to avoid such parsers.

> to resolve our different views on this.

This discussion focuses too much on the situation where both XML and
JSON clients are supposed to work with the same server. Whilst it is
important to make this possible, it's not the only criterion - and in
Bert's scenarios (a), (b) and (d), servers even needn't support
it. What's IMO equally important is to offer first-class APIs for XML
and JSON separately.

Lada

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 4 Sep 2014 07:26:44 -0400

Hi Lada,

> From: Netconf [mailto:[email-masked]] On Behalf Of Ladislav
> Lhotka
[...]
> it. What's IMO equally important is to offer first-class APIs for XML

Do you make that assessment as an NMS developer, an agent developer, a
toolkit developer, or a user (or a JSON promoter)?
I'm not sure what your perspective is based on.

My background is primarily as an NMS developer and user of the information.
As an NMS user, when I ask a server for some data, I want to know whether
asking that data to be encoded using XML or using JSON might give me
different results. 
I would assume the 90/10 rule applies - 90% of the time, they will be
identical.
But I need to know whether the specific data I want to get falls within that
90%, or within  the exceptional 10%. 
Even if we get to 97/3 or 98/2, I still want to know where those exceptions
are, because getting misleading information is a bad thing, and issues like
datatype conversions can cause data to be interpreted incorrectly, and be
hard to detect that a faulty conversion has corrupted the information (think
casts in C, for example).

If I have a single client managing a heterogeneous network, where half my
Netconf servers support XML and the other half support JSON, will both
interfaces give me data that is truly equivalent - to the point that I can
reliably compare data from one type of server with those of the other type
of server?
>From an NMS/user perspective I need to know I can correlate the data from
multiple servers reliably.
So the focus on whether both XML and JSON clients are supposed to work
**interoperably** with the same server is rather important.

I strongly support the desire for first-class APIs.
But for an industry standard from an SDO focused on vendor-neutral
interoperability, having ONE mandatory-to-implement first-class API that
ensures interoperability should trump having TWO (optional or MTI)
first-class APIs, if we cannot ensure interoperability across the two
standards-compliant implementations.

David Harrington
[email-masked]
+1-603-828-1401

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 4 Sep 2014 16:26:14 +0200

> I'm not sure what your perspective is based on.

None of the above, I am an amateur in all these areas.

But I certainly don’t want to blindly promote JSON over XML. I invested much effort in learning XML and XSLT is one of my favourite programming languages, which I truly miss in JSON.

> casts in C, for example).

As I said, our aim to achieve 100 % for data that are subject to data modelling (anyxml in its current form is not). And it doesn’t seem really that difficult.

> **interoperably** with the same server is rather important.

Yes, it is important, and I don’t want any ambiguity. My point was that it would be useless to achieve this  goal by extending and bending JSON so that everything will work exactly as in XML.  

> standards-compliant implementations.

Selecting one for all classes of devices is difficult.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 6 Sep 2014 08:24:01 +0200

> module names and corresponding URIs mostly appear together - in modules,

I disagree that a module name is "way better" and I strongly believe
that using different identifiers to identify the same namespace in
different encodings adds operational complexity that can and should be
avoided. I do not think it makes sense to further iterate this point
between us since we go in circles.

> strings in JSON, we just have to find a solution for some corner cases.

The only solution presented so far has been to encode unions as
strings. Unless someone presents an alternative, I assume this is what
we have to do.
 
> recommend implementors to avoid such parsers.

The world is as it is. What is the value of defining a JSON encoding
where I can't use many off the shelf JSON libraries? The encoding must
be robust, we can accept to loose precision. Again, we go in circles
here.

> it. What's IMO equally important is to offer first-class APIs for XML

Network management systems tend to talk to many devices. If we do not
define a single mandatory to implement encoding, clients and servers
will have to support both in the real world. And now we are getting
back to the subject of this thread at least. ;-)

/js

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Sep 2014 09:26:01 -0400

>    be something to be worked out if we choose this option

I prefer a first and then d second.

While I'm not currently a netconf developer, I have prior experience in both
xml and json in development at a prior employer.  While I dislike the heavy
weight of xml, I vastly prefer its flexibility.

-- Jeff

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 09 Sep 2014 11:25:02 +0200

I'd like to remind everyone that this WG last call ends on Sept 18.
Several people have already expressed their opinion. If you want to be heard, pls
speak up asap, certainly before Sept 18th. The WG chairs need your input and
opinions to try and determine WG (rough) consensus on this topic.

Bert

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 9 Sep 2014 09:46:11 -0700

Is there room to change ones opinion :-) ?

I had voted for a) but was reminded that there are existing solutions with JSON that will not accept a strict XML solution. d) provides the maximum flexibility in that regard, leaving the server to implement what it prefers.

Mahesh Jethanandani
[email-masked]

---

From: t.petch <[email-masked]>
Date: Wed, 17 Sep 2014 17:29:28 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Tuesday, September 02, 2014 9:24 PM
> Sorry for a complicated answer.

It's a complicated question!

I go for a), less options, less complexity, better understood at this
point in time, warts and all.

I am not involved in implementing it.

Tom Petch