Subject: [Netconf] Issue #2 for binary encoding: Should the new encoding include the Message layer?

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 21 Mar 2018 08:02:11 +0000

Added another issue to GitHub here - https://github.com/netconf-wg/binary-encoding/issues/2 <https://github.com/netconf-wg/binary-encoding/issues/2> that reads:

The -00 version of the draft is silent about which layer the alternate form of encoding impacts. After some discussion, the authors clarified on the mailing list, that the draft was going to propose that encoding of alternate forms of encoding will impact layers above the Message layer per Figure 1 of RFC 6241.

An alternate proposal is for the Message layer to be binary encoded also. That means that whatever form of encoding is agreed upon has to provide a way to encode Message layer RPCs, such as <rpc>, <rpc-reply>, <rpc-error> and <ok>.

The pro of not encoding the Message layer is that alternate form of encoding does not have to define encoding for that layer. For example, CBOR defines a way to encode YANG. It does not define how to encode RPCs, at least currently. BTW, that draft is in LC, if not past it.

The con is that one would lose 25% efficiency in doing a base64 encoding, not to include the fact that one would have to deal with two forms of encoding.

If we do agree that the Messaging layer should be binary encoded, (a separate) draft would have to define a way to encode the Message layer. And, this would have to be done for each form of encoding.

Question for the WG, should the new encoding include the Message layer?

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Mar 2018 09:25:46 +0100

There is encoding of YANG defined data and there is the encoding of
protocol messages. Lets not confuse the two.

- RESTCONF: Protocol encoding is handled by HTTP. HTTP/1.1 uses a
  textual format, HTTP/2 uses a binary format. HTTP was designed to
  handle arbitrary content formats. Hence, using RESTCONF with XML,
  JSON, CBOR, ... just works (but note that the HTTP protocol layer
  does not use XML, nor JSON nor CBOR encoding).

- NETCONF: NETCONF does not have the capability to support different
  content formats. We can (a) retrofit this onto the existing protocol
  format (allowing other content encoding on top of the XML encoded
  protocol format) or (b) we create a new protocol encoding that can
  handle different content formats more efficiently than (a) would do.
  But this largely boils down to a new protocol version, stripped down
  to the messaging layer.

  I do not think it is desirable to have N different message layer
  encodings for N different content layer encodings since you need at
  least something common to negotiate the encodings. That said, one
  could define the messaging layer using the yang-data extension and
  then the rpc message formats translate to XML, JSON, CBOR, ... but
  we would still have to have something common that initially
  negatiates the encodings.

Anyway, to do all this properly, we would have to open up RFC 6241 and
to split it into pieces, separating the messaging layer cleanly from
the well-known NETCONF operations and their semantics.

This of course raises the question whether this work is useful to
entertain given that we already have RESTCONF that happily supports
different content encoding formats and which can be used with both a
textual encoding and a binary encoding of the messaging layer. (And
outside the IETF we have protocols that use entirely different RPC
layers.) Perhaps the simpler answer is that if you really need
something more efficient than NETCONF, use RESTCONF. Available today.

/js

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Mar 2018 16:30:49 -0700

> protocol messages. Lets not confuse the two.

good point.
We have usually left out YANG for protocol messages, but now we have YANG
Data Extensions so the complete message can be defined in YANG (sort of)

I have concerns about encoding of metadata.
This is critical for real-world NM tools.
IMO XML designers really got this right.
JSON and everything else - not so much.

The practice of stuffing JSON objects into XML string nodes seems like
the worst of both worlds.  NETCONF relies on metadata in the content
layer, so encoding <rpc> in XML does not even help a little.
Switching parsers from XML to something else in mid-message is a
non-starter.

>   does not use XML, nor JSON nor CBOR encoding).

We should use IANA media types and the Accept header, as designed,
to add support for new message formats.

>   negatiates the encodings.

I prefer the switch-over after the <hello> exchange.
This would be NETCONF's version of the Accept header.

> the well-known NETCONF operations and their semantics.
Properly for documentation and standards track purposes,
but not really for interoperability.

> something more efficient than NETCONF, use RESTCONF. Available today.

It is true that NMDA RESTCONF exposes many details that were intentionally
left
of RFC 8040.  IMO we should support both protocols for the foreseeable
future.

My wishlist for NETCONF binary data:
  - keep NETCONF 1.1 message framing
  - define protocol mapping to use CBOR + SID message encoding
  - define extension to encode metadata in CBOR + SID using the
annotation-stmt in RFC 7952
  - define some binary data types for IP addresses etc. so they are not
encoded as CBOR strings

/js

Andy

> > Added another issue to GitHub here - https://github.com/netconf-wg/
> binary-encoding/issues/2 <https://github.com/netconf-
> wg/binary-encoding/issues/2> that reads:
> >
> > The -00 version of the draft is silent about which layer the alternate
> form of encoding impacts. After some discussion, the authors clarified on
> the mailing list, that the draft was going to propose that encoding of
> alternate forms of encoding will impact layers above the Message layer per
> Figure 1 of RFC 6241.
> >
> > An alternate proposal is for the Message layer to be binary encoded
> also. That means that whatever form of encoding is agreed upon has to
> provide a way to encode Message layer RPCs, such as <rpc>, <rpc-reply>,
> <rpc-error> and <ok>.
> >
> > The pro of not encoding the Message layer is that alternate form of
> encoding does not have to define encoding for that layer. For example, CBOR
> defines a way to encode YANG. It does not define how to encode RPCs, at
> least currently. BTW, that draft is in LC, if not past it.
> >
> > The con is that one would lose 25% efficiency in doing a base64
> encoding, not to include the fact that one would have to deal with two
> forms of encoding.
> >
> > If we do agree that the Messaging layer should be binary encoded, (a
> separate) draft would have to define a way to encode the Message layer.
> And, this would have to be done for each form of encoding.
> >