Subject: [Netconf] RESTCONF modularilty

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Aug 2014 17:01:40 +0000

The RESTCONF authors recently discussed adding support for filtering, sorting, and paging collections (i.e. lists).  One comment was that it was complex and better defined in another draft.   I agree, but more importantly, RESTCONF should be fully modular, providing an ability for implementations to selectively advertise support for various things.    This is exactly the approach we used for the NETCONF Light draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-01), but RESTCONF being a new protocol, there is no reason to not do it from the get go.   This strategy was discussed in Toronto, but we felt we should take it to the list before restructuring the document...

Recapping the NETCONF Light strategy, the YANG module defined the follow features:

     feature get-config {
       description
        "This feature indicates that the server supports the
         <get-config> protocol operation, albeit without subtree
         filtering.   The server must additionally advertize
         the \"subtree-filtering\" feature to enable subtree
         filtering.  Alternatively, if the server only wants
         to support XPath filtering, it may just advertize
         the :xpath capability.";
     }

     feature subtree-filtering {
       description
        "This feature indicates that the server supports subtree
         filtering for the <get-config> operation.  This
         feature is only meaningful if the "get-config" feature
         is advertized; if "get-config" is not also advertized,
         this feature MUST be ignored.";
     }

     feature edit-config {
       description
        "This feature indicates that the server supports the
         <edit-config> protocol operation.  If the server is
         unable to support all the <edit-config> attributes
         (merge, replace, create, delete, remove), then it
         should advertize the \"copy-config\" feature instead.";
     }

     feature copy-config {
       description
        "This feature indicates that the server supports the
         <copy-config> protocol operation.";
     }

     feature delete-config {
       description
        "This feature indicates that the server supports the
         <delete-config> protocol operation.";
     }

     feature locking {
       description
        "This feature indicates that the server supports the
         <lock> and <unlock> protocol operations.";
     }

     feature get {
       description
        "This feature indicates that the server supports the
         <get> protocol operation.";
     }

     feature close-session {
       description
        "This feature indicates that the server supports the
         <close-session> protocol operation.  When this feature
         is not advertized, clients are expected to close the
         underlying transport directly.";
     }

     feature kill-session {
       description
        "This feature indicates that the server supports the
         <kill-session> protocol operation.";
     }

The corollary to RESTCONF might be:

    Base Support
          - the ability to GET and PUT on the top-level node using XML only

    Optional Support:
          - the ability to do PATCH  (this is already optional)
          - the ability to use JSON encoding
          - the ability to POST/GET/PUT/DELETE subtrees   (PATCH too, is support for it is advertised)
          - the ability to use "select" with GET operations
          - the ability to use "filter" with GET on collection resources (i.e. lists) and event streams
          - the ability to do pagination with GET on collection resources (i.e. lists)
          - the ability to do sorting with GET on collection resources (i.e. lists)

Thoughts?

Thanks,
Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Aug 2014 16:26:11 +0200

Hi,

Kent Watsen <[email-masked]> writes:

> The RESTCONF authors recently discussed adding support for filtering,
> sorting, and paging collections (i.e. lists).  One comment was that it
> was complex and better defined in another draft.  I agree, but more
> importantly, RESTCONF should be fully modular, providing an ability
> for implementations to selectively advertise support for various
> things.  This is exactly the approach we used for the NETCONF Light
> draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-01), but
> RESTCONF being a new protocol, there is no reason to not do it from
> the get go.  This strategy was discussed in Toronto, but we felt we
> should take it to the list before restructuring the document...

I fully agree with this strategy. Support for individual capabilities
will be indicated somehow under the "restconf" resource?

...

>           - the ability to use JSON encoding

I think XML and JSON should be given equal footing, i.e. the server
could support either or both. Perhaps the "Accept" header on the client
side and 406/415 status codes on the server side could be enough?

Lada

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

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2014 08:12:08 -0700

> will be indicated somehow under the "restconf" resource?
I support this strategy as well. We made all 9 groups of RMON optional
and let the market decide how to best deploy RMON-MIB.  Turned out
that "RMON-Lite" was very useful.

 Option 1:  custom lists:

   container restconf {
        container modules {  ... currently in tree ... }
        container capabilities  { ... new ... format TBD }
        container query-parameters { new ... format TBD }
   }

Option 2: back to simple list of URIs

     container restconf {
        container capabilities  {
            leaf-list capability { same as in ietf-netconf-monitoring }
        }
     }

Option 3: Require implementation of the ietf-netconf-monitoring
'capability' node

     /restconf/data/netconf-state/capabilities/capability
     ** This probably requires a 6022bis to make the
         monitoring stats support NETCONF and RESTCONF

 ** 2 & 3 require URI definitions for each query parameter and official
protocol capability

...
> side and 406/415 status codes on the server side could be enough?

This approach doesn't work if each person picks their pet options to
be mandatory.  Everything is optional, even XML. One might want
to support only JSON and not implement XML.

I would make read-only vs read-write vs read-create/delete 3 separate
capabilities (server MUST support 1 of them)

  read-only: GET
  read-write: GET, PUT
  read-create: GET, POST, PUT, DELETE

I think this aligns better with capabilities of constrained devices.

> >           - the ability to do sorting with GET on collection resources

Some of these are traditionally client-side tasks.  They should be optional.
HTTP already makes PATCH optional. All query parameters should be optional.

> > Kent

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Aug 2014 17:36:45 +0200

>         container query-parameters { new ... format TBD }

If the set of capabilities is open-ended then I would go for this option as it is the most flexible. Capability descriptions could then have more structure than a simple URI.

> Option 3: Require implementation of the ietf-netconf-monitoring 'capability' node
> 
>  ** 2 & 3 require URI definitions for each query parameter and official protocol capability
> 
> 
> ...
> 
> >

This is what I am saying.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2014 09:06:31 -0700

On Thu, Aug 21, 2014 at 8:36 AM, Ladislav Lhotka <[email-masked]> wrote:

> If the set of capabilities is open-ended then I would go for this option
> as it is the most flexible. Capability descriptions could then have more
> structure than a simple URI.
>
>

This is not very flexible because the YANG structure needs to be defined at
the start.
I think the URI is better because it is flexible.  Also much less overhead
on-the-wire than
a YANG data structure (that would match it in flexibility).

Andy

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 21 Aug 2014 19:30:16 +0200

> side and 406/415 status codes on the server side could be enough?

+1 re XML and JSON on equal footing.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 22 Aug 2014 17:37:59 +0000

I also agree XML/JSON should be on equal footing.   I like Andy's idea of having them both optional to implement.  I can easily imagine cases where an implementation only want to support a single encoding, perhaps one NETCONF supports in the future.

From: Wojciech Dec <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 21, 2014 at 1:30 PM
To: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
Cc: Kent Watsen <[email-masked]<mailto:[email-masked]>>, NetConf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] RESTCONF modularilty

On 21 August 2014 16:26, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

...

Lada

> [email-masked]<mailto:[email-masked]>

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Aug 2014 10:44:11 -0700

On Fri, Aug 22, 2014 at 10:37 AM, Kent Watsen <[email-masked]> wrote:

>
>  I also agree XML/JSON should be on equal footing.   I like Andy's idea
> of having them both optional to implement.  I can easily imagine cases
> where an implementation only want to support a single encoding, perhaps one
> NETCONF supports in the future.
>
>
NETCONF is problematic because of backward compatibility.
That is why the NETCONF-EX "encoding" capability is part of the
<hello> message.  The first message needs to be XML encoding
using base:1.0 message framing. Framing and encoding switch after
the <hello> message.

Andy

>   From: Wojciech Dec <[email-masked]>
> To: Ladislav Lhotka <[email-masked]>
> Cc: Kent Watsen <[email-masked]>, NetConf <[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Aug 2014 20:20:27 +0200

> I also agree XML/JSON should be on equal footing.   I like Andy's idea of having them both optional to implement.  I can easily imagine cases where an implementation only want to support a single e…

Two compliant implementations that do not interoperate sounds like a
bad idea to me. I think the WG needs to pick one encoding and make it
mandatory to implement.

/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: Phil Shafer <[email-masked]>
Date: Fri, 22 Aug 2014 14:27:07 -0400

Kent Watsen writes:
>I also agree XML/JSON should be on equal footing.   I like Andy's idea of h=
>aving them both optional to implement.  I can easily imagine cases where an=
> implementation only want to support a single encoding, perhaps one NETCONF=
> supports in the future.

Making them both optional-to-implement really means that any client
that wants interoperability needs both, since it never knows which
it will need, and any server that wants interoperability needs both,
since it never knows which it will need.  "Either" translates into
"both" in the real world, making life harder, not easier.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Aug 2014 11:42:09 -0700

> "both" in the real world, making life harder, not easier.

I agree the client will end up implementing both, but a constrained server
might not
implement both. "equal footing" means both are mandatory or both are
optional.
Currently both are mandatory and XML is the default.

Making one encoding mandatory would be more efficient for constrained
devices,
but that assumes we can pick 1.  I would pick XML over JSON as mandatory,
since it handles attributes and an inline (streaming) implementation is
much easier.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 22 Aug 2014 20:12:29 +0000

> I agree the client will end up implementing both, but a constrained server might not
> implement both. "equal footing" means both are mandatory or both are optional.

"both optional" does mean that clients have to support both.   The servers reap the benefit in needing to implement support only one, which is important for constrained devices.  Do we think "both mandatory" is OK for all servers?

K.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Aug 2014 14:28:52 -0700

On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen <[email-masked]> wrote:

>  "both optional" does mean that clients have to support both.   The
> servers reap the benefit in needing to implement support only one, which is
> important for constrained devices.  Do we think "both mandatory" is OK for
> all servers?
>
>
What are the alternatives?
mandatory for the client to implement both?
mandatory for the server to implement at least one?
This means the client has to retrieve the server capabilities
before sending any requests with a message body?
(Or just try 1 format and if it fails, assume the other will work?)

Another option:
   server SHOULD implement both; MAY implement one if resource constrained

 K.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Sun, 24 Aug 2014 21:18:43 +0000

>   server SHOULD implement both; MAY implement one if resource constrained

+1    - and the server MUST advertise which encoding(s) it supports, at least one.

Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Aug 2014 08:51:22 +0200

> +1    - and the server MUST advertise which encoding(s) it supports,

+1, and the client SHOULD implement both.

The strategy "everything is optional" leads to a similar situation in
other cases, too, for example YANG Patch versus JSON Patch (or perhaps
even versus things like XQuery Update).

We are potentially addressing a huge range of devices, so finding any common
denominator on the server side might be impossible.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Aug 2014 20:50:54 +0200 (CEST)

>    server SHOULD implement both; MAY implement one if resource constrained

The goal is still interoperability.  So why not simply:

  server MUST implement XML and SHOULD implement JSON.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Aug 2014 12:25:42 -0700

>   server MUST implement XML and SHOULD implement JSON.
MUST implement XML, SHOULD implement JSON does not put XML and JSON on
"equal footing" as Lada requested -- but I could agree to this -- if we
have to
pick a mandatory-to-implement, I would pick XML over JSON.

I agree there is operations impact because the client has to figure out
what the
server supports before it can send it any data. But supporting multiple
formats is heavyweight.

We don't seem to have any real justification for using 2 encoding formats.
It is quite an implementation burden for the server to provide equivalent
functionality
in both JSON and XML format. (Consider distributed servers that stream the
reply
and do not build a static "document" in memory that can be translated on
output).
The justification seems to be that we do not want to pick between XML and
JSON so
they are both mandatory.

/martin

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Aug 2014 21:50:06 +0200

>  server MUST implement XML and SHOULD implement JSON.

It would probably make more sense the other way around as for constrained devices JSON is generally much easier to deal with than XML.

Lada

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 25 Aug 2014 16:34:09 -0700

Hi,

I would also support JSON being at least equal footing with XML. Ideally 
being MTI.

thanks,

Reinaldo

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Aug 2014 17:32:53 -0700

> I would also support JSON being at least equal footing with XML. Ideally
IMO 2 mandatory encoding formats is overkill.
RESTCONF is supposed to be lightweight compared to NETCONF,
and NETCONF does not require more than 1 encoding format.

XML is a mature standard.  It supports namespaces and attributes.
The YANG-to-JSON standard is still an work-in-progress with no
full implementations.

I don't see why the server SHOULD or MUST implement multiple formats.
Seems like that is moving the complexity from the client to the server.
Since there are many more servers (and they may be constrained)
this seems like the wrong place to dump complexity for the sake of client
flexibility.

I think a constrained server should only need 1 encoding format, and I could
see how the vendor could choose JSON over XML.  But implementation details
are usually left out of standards. That is why my first choice
is not to pick a mandatory between XML and JSON.

thanks,
Andy

>>>>  I agree the client will end up implementing both, but a constrained
>>>>>>
>>>>> server might not
>>>>>
>> It would probably make more sense the other way around as for constrained
>> devices JSON is generally much easier to deal with than XML.
>>
>> Lada
>>
>>
>>> /martin
>>>

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 25 Aug 2014 18:00:58 -0700

On 8/25/14 5:32 PM, Andy Bierman wrote:
>
>
>
> On Mon, Aug 25, 2014 at 4:34 PM, Reinaldo Penno <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     I would also support JSON being at least equal footing with XML.
>     Ideally being MTI.
>
>

[RP] Then JSON is the perfect choice.

> this seems like the wrong place to dump complexity for the sake of 
> client flexibility.
>
>         On 25 Aug 2014, at 20:50, Martin Bjorklund <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Andy Bierman <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>         It would probably make more sense the other way around as for
>         constrained devices JSON is generally much easier to deal with
>         than XML.
>
>         Lada
>
>
>             /martin
>
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Aug 2014 11:31:21 +0200

On 26 Aug 2014, at 02:32, Andy Bierman <[email-masked]> wrote:

> I would also support JSON being at least equal footing with XML. Ideally being MTI.
> 
> 
> this seems like the wrong place to dump complexity for the sake of client flexibility.
> 

I’d support this, too. I don’t think this breaks interoperability.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Aug 2014 12:06:39 +0200

> I’d support this, too. I don’t think this breaks interoperability.

I find it surprising to consider the mandatory to implement encoding
format an implementation detail. Usually a standard gives clear
guidance about data encoding for the sake of interoperability. So far,
I only see these three options:

a) XML is mandatory
b) JSON is mandatory
c) XML and JSON are both mandatory

I expect that the fourth option put on the table, namely

d) implementors can decide whether they implement JSON or XML

leads eventually to c), after a certain period of frustration when
things do not interoperate. Hence, I believe the decision needs to be
made between a) and b) and c). If people argue about constrained
implementations, it would help if they can provide more details what
they mean with the term 'constrained' and if they can put numbers on
the table concerning resource usage of the two alternatives.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Aug 2014 12:17:02 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> made between a) and b) and c).

I agree.

> If people argue about constrained

Right.  And for the other end of the spectrum, devices dealing with
large data sets, JSON is inferior since parsers need to buffer
everything (b/c object members are unordered).  Maybe this is also an
issue for constrained devices.

I am also not convinced that RESTCONF is the right solution for at
least some of these constrained devices.  Maybe a better architecture
is to use a special-purpose control protocol from a "controller" to
these devices, and let the "controller" expose YANG models over
NETCONF (and/or RESTCONF).

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Aug 2014 12:38:41 +0200

> NETCONF (and/or RESTCONF).

Exactly my point - the word 'constrained' is not sufficiently clear
enough. If we talk about constrained devices considered by the IoT
work in the IETF, then you like want to have a proxy that translates
RESTCONF to COAP and part of the translation might even be a change of
the data encoding to something like CBOR. There are many open
questions in this space though, e.g. to what extend such a gateway
needs to be able to understand the underlying YANG data models or how
to encode URLs efficiently into something short and compact.

But I have a certain feeling that people use 'constrained
implementations' here in a somewhat different sense, e.g. targeting
boxes capable to run an embedded Linux but where you like to avoid too
many library dependencies. I am guessing though because people are not
very clear what their concerns are.

/js

PS: The streaming issue is actually important for constrained devices
    as well. Having to buffer data is really hard if your RAM is only
    a few KB. It is likely less an issue for embedded Linux systems
    where the data size likely matches more easily the available RAM.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Aug 2014 13:07:45 +0200

> things do not interoperate. Hence, I believe the decision needs to be

c) on the client and d) on the server (+ a method how the client can find out what media type(s) the server supports) is interoperable.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Aug 2014 07:07:46 -0700

On Tue, Aug 26, 2014 at 3:06 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > I'd support this, too. I don't think this breaks interoperability.
> >
>

I meant the selection of JSON or XML seems to be based on implementation
details, which is why we can't pick a clear winner.

> d) implementors can decide whether they implement JSON or XML
This is a strawman -- nobody is proposing this option.
The discussion is over server requirements:

  A) XML and JSON are both MTI  [current]
  B) XML is mandatory and JSON is optional
  C) JSON is mandatory and XML is optional
  D) server MUST support XML or JSON (vendor picks 1)

> the table concerning resource usage of the two alternatives.

+1  JSON is about 40% smaller on-the-wire
+1 JSON should require less code space than XML to implement
-1 JSON is horrible for streaming (too much state to know and keep)
-1 JSON does not currently support YANG module namespaces
-1 JSON does not currently support meta-data (like XML attributes)
-1 JSON does not support 64 bit numbers

(So JSON loses to XML 4 - 2 ?  :-)

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Aug 2014 16:22:35 +0200

> -1 JSON is horrible for streaming (too much state to know and keep)

We should consider draft-ietf-json-text-sequence-06.

> -1 JSON does not currently support YANG module namespaces

Why not? I don’t understand.

> -1 JSON does not currently support meta-data (like XML attributes)

That’s what we are discussing in the parallel thread.

> -1 JSON does not support 64 bit numbers

Not true. The issue only appears in I-JSON because presumably some (most?) existing decoders read JSON numbers into double precision floats.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Aug 2014 08:13:28 -0700

> We should consider draft-ietf-json-text-sequence-06.
More brand new code to write?

> Why not? I don't understand.
>

XML is a deployed standard with lots of implementations and free tools.
The YANG-to-JSON standard is still a work-in-progress with minimal
deployment
and tools.

> That's what we are discussing in the parallel thread.
>

XML has a deployed solution

> Not true. The issue only appears in I-JSON because presumably some (most?)
> existing decoders read JSON numbers into double precision floats.
>
>
OK.

Andy

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 26 Aug 2014 08:20:23 -0700

Let's be fair and compare apples to apples.

"XML is a deployed standard with lots of implementations and free tools."

[RP] And JSON is also a deployed standards with lots of implementation 
and free tools. And, if anything, JSON is overtaking XML in tools, 
deployment and programming language support.

"The YANG-to-JSON standard is still a work-in-progress with minimal 
deployment
and tools."

[RP] RESTConf is also a work-in-progress. And I see this as an 
opportunity to make sure our standards embrace the JSON and not a 
standard that is in decline.

On 8/26/14 8:13 AM, Andy Bierman wrote:
>
>
>
> On Tue, Aug 26, 2014 at 7:22 AM, Ladislav Lhotka <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     On 26 Aug 2014, at 16:07, Andy Bierman <[email-masked]

>     Not true. The issue only appears in I-JSON because presumably some
>     (most?) existing decoders read JSON numbers into double precision
>     floats.
>
>
> OK.
>
>
>     Lada
>
>
> Andy
>
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Aug 2014 08:39:19 -0700

Hi,

So maybe we are confirming that we don't have consensus to pick
1 mandatory encoding format.

Nobody has complained that the client needs to support both,
so the issue seems to be what to require for the server.
Since the client MUST support both, then it really doesn't matter at all
which of the 2 formats the server supports. It is trivial to discover the
supported formats from the server.

I still have not heard any justification for 2 mandatory formats for the
server.
IMO, if we can't pick 1 mandatory, then let the vendor pick, rather than
requiring both.

Andy

On Tue, Aug 26, 2014 at 8:20 AM, Reinaldo Penno <[email-masked]> wrote:

> [RP] And JSON is also a deployed standards with lots of implementation and
> free tools. And, if anything, JSON is overtaking XML in tools, deployment
> and programming language support.
>
> [RP] RESTConf is also a work-in-progress. And I see this as an opportunity
> to make sure our standards embrace the JSON and not a standard that is in
> decline.
>
>> (most?) existing decoders read JSON numbers into double precision floats.
>>
>>
>  OK.
>
>
>
>
>> Lada
>>
>>
>  Andy
>
>
>
> Netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Aug 2014 18:05:59 +0200

On 26 Aug 2014, at 17:13, Andy Bierman <[email-masked]> wrote:

> The YANG-to-JSON standard is still a work-in-progress with minimal deployment
> and tools.

This is true for RESTCONF and YANG in the first place. Objectively, JSON is a far better fit for YANG data than XML - you just have to work out a few things. In XML, on the other hand, you have to carry along all the baggage that’s not needed.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Aug 2014 18:44:22 +0200

> Not true. The issue only appears in I-JSON because presumably some (most?) existing decoders read JSON numbers into double precision floats.

I disagree with both statements.

a) The JSON specification [RFC7159] says:

     This specification allows implementations to set limits on the range
     and precision of numbers accepted.  Since software that implements
     IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
     generally available and widely used, good interoperability can be
     achieved by implementations that expect no more precision or range
     than these provide, in the sense that implementations will
     approximate JSON numbers within the expected precision.  A JSON
     number such as 1E400 or 3.141592653589793238462643383279 may indicate
     potential interoperability problems, since it suggests that the
     software that created it expects receiving software to have greater
     capabilities for numeric magnitude and precision than is widely
     available.

     Note that when such software is used, numbers that are integers and
     are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
     sense that implementations will agree exactly on their numeric
     values.

   So this is not an I-JSON issue.

b) 64-bit numbers can of course be encoded in JSON by encoding them as
   strings. (This is not worse than encoding them as strings in XML.)

Note that this may also affect YANG's decimal64 type. The YANG to JSON
I-D simply needs to say the right thing.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Aug 2014 22:29:25 +0200 (CEST)

> More brand new code to write?

Also it is not clear how this works with the hierarchical data models
we have.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Aug 2014 22:34:23 +0200 (CEST)

> so the issue seems to be what to require for the server.

I disagree.  If it is ok to say that the client MUST support both, it
is obvious that it would be ok for the server to pick any format, and
we'll still get interoperability.  If everybody agreed with this, we
wouldn't have this argument.

> IMO, if we can't pick 1 mandatory, then let the vendor pick, rather than

I still think we should pick 1 mandatory for both sides.  I don't want
to require all clients (or servers) to implement both encodings.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Aug 2014 13:49:59 -0700

> to require all clients (or servers) to implement both encodings.

I don't much care which one we choose as mandatory.
Both have pros and cons that makes each one imperfect.
I've implemented both of them already (except JSON attributes).
I don't like the current text which says both are mandatory.

I know in our server the custom JSON code is much smaller and faster than
libxml2,
but somebody could have a small and fast XML library, so
IMO implementation details are not a good way to decide.

Perhaps the co-chairs should decide how to proceed somehow.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Aug 2014 09:03:05 +0200

>    So this is not an I-JSON issue.

JSON as "a text format for the serialization of structured data" impose
no restrictions whatsoever on the size of a number. The text you mention
says that *some implementations* may set restrictions. It is certainly
not the case for all implementations:

$ python
Python 2.7.8 (default, Jul  2 2014, 10:14:46) 
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> json.loads('{"pi40": 1415926535897932384626433832795028841971}')
{u'pi40': 1415926535897932384626433832795028841971L} 

The aeson decoder in Haskell also provides integers of unbounded size
when asked to do so.

I-JSON is a restricted profile of JSON that tries to ensure
interoperability, no matter what JSON decoder is used. So it says:

"I-JSON messages SHOULD NOT include numbers which express greater
magnitude or precision than an IEEE 754 double precision number
provides, ..."

>    strings. (This is not worse than encoding them as strings in XML.)

How is this related to the question whether JSON or I-JSON support 64-bit numbers? 

> I-D simply needs to say the right thing.

Yes, we can use this as a workaround for ensuring maximum interoperability.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Aug 2014 09:12:58 +0200

> magnitude or precision than an IEEE 754 double precision number

The IETF work is about interoperability. It is great if Python or
Haskell implementations do not suffer from this problem but the fact
that some implementations do not map numbers to IEEE doubles does not
change the fact that other popular implementations make this
assumption. And the reason is that IEEE doubles are JavaScript numbers
and remember that JSON has its roots in JavaScript.

Since the IETF is about interoperability, I think we really should try
hard to follow I-JSON.

> How is this related to the question whether JSON or I-JSON support 64-bit numbers? 

Since I believe JSON does not support 64-bit numbers in an
interoperable way if they are encoded as numbers, we need to find
workarounds. If you know a better one, tell us.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Aug 2014 09:34:21 +0200

> and remember that JSON has its roots in JavaScript.

This is all fine, but Andy listed “lack of support for 64-bit numbers” as a minus point for JSON and I objected against that.

> Since the IETF is about interoperability, I think we really should try

That’s the question that is important for yang-json. I plan to open it in another thread.

> workarounds. If you know a better one, tell us.

Again, JSON is a text format that supports numbers of any size. Interoperability is a concern for those who want to use JSON for encoding protocol messages. And yes, that’s us.

Lada