[Netconf] Suggestion for RESTCONF section 5.3

[Rodney Cummings <[e-mail]>]

Hello,

Although I am new to the NETCONF WG and mailing list, I have a suggestion 
for the RESTCONF I-D that I'd like to discuss. I realize that I may be 
bringing up a topic that has already been thoroughly discussed. 
Nevertheless, this issue is a genuine problem for deployment of RESTCONF 
for my applications, so if my suggestion is rejected, it will be helpful 
for me understand the rationale.

Suggestion
--

Section 5.3 of the current I-D (
https://tools.ietf.org/html/draft-ietf-netconf-restconf-04) states:

"Content is encoded in either JSON or XML format.  A server MUST support 
XML encoding and MAY support JSON encoding."

My suggestion is to change section 5.3 to state:

"Content is encoded in either JSON or XML format.  A client MUST support 
at least one of the specified encodings (XML or JSON), and a client SHOULD 
support all specified encodings.  A server MUST support at least one of 
the specified encodings (XML or JSON), and a server MAY support multiple 
encodings."

In other words, if a server wants to focus on JSON exclusively, allow that 
as a conformant implementation. The client has a presumed burden to 
support a server that is XML-only or JSON-only.

Rationale
--

As part of a roadmap for supporting industrial IoT devices, the 802.1 
Time-Sensitive Networking standards (TSN) are focusing on YANG modules for 
configuration of the low-level queuing behavior in 802.1 switches (e.g. 
schedule for traffic egress on each port). The assumption is that an 
SDN-style controller will use these YANG modules to write configuration to 
each switch in the network in an automated manner. Ideally, as TSN moves 
forward it will be well-aligned with analogous IETF efforts, including 
CoRE, 6TiSCH, and DetNet (upcoming BoF in July).

One near-term focus for the TSN effort is to support an IoT device (e.g. 
industrial motor, smart grid IED) that supports Ethernet today, but that 
wants to embed an 802.1 switch. The goal is to expose two external ports 
from the device, using the switch to enable topologies like daisy-chain 
and ring. This is commonly done today using proprietary Ethernet 
extensions, but we want to transition industrial applications to 802/IETF 
standards (much like the 6TiSCH effort for wireless). The challenge is 
that although this IoT device is technically a switch/router, it is very 
"Operational Technology" (OT). A YANG-based management protocol is 
required to configure the switch, but the switch supports a subset of what 
a standalone managed switch/router supports, and the switch will always be 
configured in-band from an OT controller, never from an IT-style NMS.

>From the perspective of one of these IoT device manufacturers, the primary 
question for management is:
        What YANG-based management protocol do I implement in my device?
Among others, I've been tasked to help answer this question for TSN and 
its related groups (e.g. AVnu.org/industrial). The assumption is that the 
manufacturer will use one and only one server implementation. Since the 
goal is not to support a traditional NMS, implementation of multiple 
servers is not a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so 
on).

Based on this, I've been trying to choose among the following 
implementations in order to make a recommendation:
1. NETCONF with XML encoding
2. RESTCONF with XML encoding
3. RESTCONF with JSON encoding
4. CoMI with CBOR encoding

For the industrial application space that I am evaluating, the devices are 
"constrained" as CoRE describes. Nevertheless, over the last few years it 
has become common for these devices to implement an HTTP web server for 
configuration. These web servers are often designed as RESTful. Given the 
constrained nature of the devices, they tend to use JSON, due to the 
perception  that XML parsing is less efficient. 

Based on these assumptions, I tend to exclude NETCONF. NETCONF is 
full-featured, but most of those features are relevant to NMS concerns. 
Also, NETCONF's basis on XML raises a perception (if not reality) of 
complex implementation.

CoMI looks promising, since it is based on relatively mature RFCs like 
CoAP and CBOR. Nevertheless, the CoMI I-D itself looks like it is 
not-quite-ready-for-prime-time. There are many TODOs, and the YANG hash 
seems like it will require more prototyping before it is truly nailed 
down. Given that, I can't really recommend that direction just yet, but 
ideally it will be useful in the future.

That leaves RESTCONF. Since the industrial device manufacturers tend to be 
familiar with REST already, this is an easy sell. The I-D itself seems to 
be relatively mature.

Ideally, I could recommend option 3, RESTCONF with JSON. That is the 
cleanest fit to what industrial devices do today.

Given the limitations of section 5.3 in v04 of the I-D, I would be forced 
to recommend option 2, RESTCONF with XML. If the IoT device is forced to 
implement XML for conformance, then the addition of JSON doesn't offer 
much value, since the goal is automated configuration.

If we could allow RESTCONF server implementation using JSON-only, that 
would be very helpful. What's more, that sort of conformance might leave 
the door open to add CoMI as a formal RESTCONF encoding in the future.

Feedback is much appreciated. Thanks.

----------------------------
Rodney Cummings
Principal Software Architect, Industrial/Embedded Networks
National Instruments
Tel: [phone]
Fax: [phone]
Email: [e-mail]