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

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

On Wed, Mar 21, 2018 at 08:02:11AM +0000, Mahesh Jethanandani wrote:
> 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
> mjethanandani@gmail.com
> 

> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> 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/>