Subject: [Netconf] Suggestion for RESTCONF section 5.3

From: Rodney Cummings <[email-masked]>
Date: Fri, 5 Jun 2015 14:39:17 -0500

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: (512) 683-8544
Fax: (512) 683-8661
Email: [email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Fri, 5 Jun 2015 22:04:05 +0000

Hi Robert,

Please see this thread:

https://www.ietf.org/mail-archive/web/netconf/current/msg09218.html

Thanks,
Kent

From: Rodney Cummings <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 5, 2015 at 3:39 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Netconf] Suggestion for RESTCONF section 5.3

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."

"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:

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.

----------------------------
Rodney Cummings
Principal Software Architect, Industrial/Embedded Networks
National Instruments
Tel: (512) 683-8544
Fax: (512) 683-8661
Email: [email-masked]<mailto:[email-masked]>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 5 Jun 2015 22:41:29 +0000

s/Robert/Rodney/  - mea culpa!

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 5, 2015 at 6:04 PM
To: Rodney Cummings <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3

Hi Robert,

Please see this thread:

Thanks,
Kent

Hello,

Suggestion
--

Rationale
--

---

From: Andy Bierman <[email-masked]>
Date: Sun, 7 Jun 2015 18:31:39 -0700

Hi,

Only choice (1) is published in an RFC.
Options (2) - (4) are work-in-progress.
It is difficult to estimate how long an IETF RFC will take,
or how much it will change from the current draft to RFC.

IMO IoT should use (4), but wait for the RFC.
Participate in the CoMI work and it might get done faster.

Andy

On Fri, Jun 5, 2015 at 12:39 PM, Rodney Cummings <[email-masked]> wrote:
> 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 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."
>
> as a conformant implementation. The client has a presumed burden to support
> a server that is XML-only or JSON-only.
>
> Rationale
> --
>
> forward it will be well-aligned with analogous IETF efforts, including CoRE,
> 6TiSCH, and DetNet (upcoming BoF in July).
>
> 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.
>
> 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).
>
> 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
> 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.
>
> familiar with REST already, this is an easy sell. The I-D itself seems to be
> relatively mature.
>
> 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.
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Rodney Cummings <[email-masked]>
Date: Tue, 9 Jun 2015 11:50:01 -0500

Thanks Andy,

I should have been clear on this point. For the applications that I am 
targeting, the relevant IEEE 802.1 TSN standards are currently in draft 
stage (not published), so even the hardware components are a 
work-in-progress. Therefore, the recommendation that I am attempting to 
make for the management protocol occurs with an understanding of the risks 
of using pre-publication IEEE / IETF standards. Although there are 
definitely folks in TSN who are eager to start with implementations, we 
understand that a draft can change in major ways, and therefore the 
implementation can change in major ways.

I'm looking at the problem as "A few years in the future, when options 1, 
2, 3, and 4 are in RFC form, which is the best fit for IoT applications?"

In my opinion, the answer will vary depending on the requirements of each 
IoT application.

To help explain, let's refer back to the previous thread on this topic 
that Kent referenced:
        
https://www.ietf.org/mail-archive/web/netconf/current/msg09218.html
My suggestion is effectively a new option e)
        e) Specify RESTCONF-XML and RESTCONF-JSON as distinct conformance 
categories (i.e. RESTCONF-JSON client interoperates with a RESTCONF-JSON 
server).
I realize that for a typical NMS client, this is effectively the same as 
option d), because the NMS must interoperate with all possible servers.

Speaking as someone who will implement both client and server, I am 
comfortable with option d). I can't speak for all clients, but my client 
is not constrained, but the servers are very constrained. In addition, the 
servers in my space are very opinionated as to what is "heavy" and what is 
"constrained" for their market space.

Some of the comments in the thread debated the which-is-best angle... XML 
or JSON. In my opinion this is not relevant. The relevant question is:
        Are there implementers out there who feel strongly that JSON is 
preferable to XML?
Whether I agree with the implementers or not, the answer is clearly Yes.

One or two comments in the thread argued that implementation complexity 
does not matter. That may be a reasonable argument, but if you feel that 
way, I would suggest that you oppose RESTCONF as a whole. If 
implementation complexity does not matter, the best course of action is to 
mandate full-featured NETCONF, and abort RESTCONF and CoMI. I assume that 
the benefit of applying RESTful methodology to the YANG data model is that 
it provides implementation flexibility that is a better fit to some use 
cases and applications.

I'll use a few IoT applications as examples.

Smart Grid: A network of synchrophasors can span an entire nation, which 
inherently implies the class of router that is used for Internet 
applications. This router can accommodate a full NETCONF implementation, 
and RESTCONF-XML provides another way to access the same XML information 
model. For this IoT application, the option a) fits just fine.

Field-level control on an industrial factory floor: Historically, these 
networks were non-Ethernet busses, with simple binary data for network 
configuration. Over the past decade or so, the devices in these networks 
typically use Ethernet and IP, and they often implement a web server for 
configuration, using REST, JSON, TLS, and so on. Nevertheless, these 
devices are still sceptical of technologies that are viewed as 
heavy-weight, so I am concerned that XML-on-the-wire won't be universally 
accepted. If RESTCONF mandates option a) for this IoT application, this 
effectively boils down to a statement like:
        I know you love apples, and you hate oranges, but oranges are good 
for you, so you must eat an orange first, and then you can eat an apple.
This sort of argument is likely to be rejected, because I can go elsewhere 
and buy an apple. It would be very helpful if RESTCONF would allow servers 
in this network to use RESTCONF-JSON. The client could mandate option d), 
but for this localized  IoT application, option e) would also work. I 
appreciate Andy's suggestion that this application could use CoMI, but 
given that this IoT application already implements REST-with-JSON, I'm 
sure you'll agree that CoMI is a strange recommendation. That is 
effectively saying that RESTCONF does not support JSON at all.

Control network inside a car: Today, these networks are non-Ethernet 
busses with binary configuration. They are currently in the process of 
slowly integrating Ethernet. The processor in each controller typically 
runs "bare metal", with no operating system at all. Given these 
constraints, the network for this IoT application is typically 
"preconfigured" (stored in NV memory when the car rolls out of the 
factory). Nevertheless, looking forward, there is discussion of using 
management, IP protocols, and so on. Given the lack of operating system 
infrastructure, CoMI will clearly be the best fit for this IoT 
application.

My point is that we want to bring IETF technologies to these applications, 
and that includes YANG-based management. If we insist on a 
one-size-fits-all approach, the IoT initiatives will succeed for some 
applications, and fail for others. I genuinely feel that YANG-based 
management is a great fit for all IoT applications, and I think that 
option d) or e) is the best way to go.

Nevertheless, I realize that the WG has already made a decision on this, 
and a single voice of opposition certainly does not justify revisiting it. 
I'll try to encourage others in the IoT initiatives to voice opinion on 
this, but failing that, I'm happy to let the issue REST (no pun intended).

Rodney

From:   Andy Bierman <[email-masked]>
To:     Rodney Cummings <[email-masked]>, 
Cc:     Netconf <[email-masked]>
Date:   06/07/2015 08:31 PM
Subject:        Re: [Netconf] Suggestion for RESTCONF section 5.3

Hi,

Andy

> Nevertheless, this issue is a genuine problem for deployment of RESTCONF 
for
> understand the rationale.
XML
> encoding and MAY support JSON encoding."
>
at
> support all specified encodings.  A server MUST support at least one of 
the
> as a conformant implementation. The client has a presumed burden to 
support
> a server that is XML-only or JSON-only.
CoRE,
> from the device, using the switch to enable topologies like daisy-chain 
and
> Among others, I've been tasked to help answer this question for TSN and 
its
> manufacturer will use one and only one server implementation. Since the 
goal
> Also, NETCONF's basis on XML raises a perception (if not reality) of 
complex
> CoMI looks promising, since it is based on relatively mature RFCs like 
CoAP
> seems like it will require more prototyping before it is truly nailed 
down.
> implement XML for conformance, then the addition of JSON doesn't offer 
much
> If we could allow RESTCONF server implementation using JSON-only, that 
would

---

From: Douglas Hubler <[email-masked]>
Date: Tue, 09 Jun 2015 17:10:44 +0000

The possibility of an entire segment of the tech industry: namely IoT could
embrace RESTCONF if we just create two categories RESTCONF-XML and
RESTCONF-JSON, then is seems like a great opportunity to gain momentum
behind RFC.  It's unlikely to affect any implementations today as I'd bet
money they all support JSON.

On Tue, Jun 9, 2015 at 12:50 PM Rodney Cummings <[email-masked]>
wrote:

> *https://www.ietf.org/mail-archive/web/netconf/current/msg09218.html*
> <https://www.ietf.org/mail-archive/web/netconf/current/msg09218.html>
> comfortable with option d). I can't speak for all clients, but my client is
> not constrained, but the servers are very constrained. In addition, the
> way, I would suggest that you oppose RESTCONF as a whole. If implementation
> complexity does not matter, the best course of action is to mandate
> full-featured NETCONF, and abort RESTCONF and CoMI. I assume that the
> benefit of applying RESTful methodology to the YANG data model is that it
> provides implementation flexibility that is a better fit to some use cases
> and applications.
>
> given that this IoT application already implements REST-with-JSON, I'm sure
> you'll agree that CoMI is a strange recommendation. That is effectively
> saying that RESTCONF does not support JSON at all.
>
> infrastructure, CoMI will clearly be the best fit for this IoT application.
>
> management is a great fit for all IoT applications, and I think that option
> d) or e) is the best way to go.
>
> ------------------------------
>
>
>
> Hi,
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jun 2015 13:03:18 +0200

Hi Rodney,

if you read all of that juicy thread, it should come as no surprise that
I fully agree with you. In fact, I already advocated your option (e)
back then:

https://www.ietf.org/mail-archive/web/netconf/current/msg09245.html

Lada

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