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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 21 March 2018 08:25 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F5C12D958; Wed, 21 Mar 2018 01:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq7dOX9i7iot; Wed, 21 Mar 2018 01:25:56 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF6F126CC4; Wed, 21 Mar 2018 01:25:49 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8E080FE9; Wed, 21 Mar 2018 09:25:47 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id AAtVT318pwZG; Wed, 21 Mar 2018 09:25:46 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Mar 2018 09:25:47 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 639C820CF5; Wed, 21 Mar 2018 09:25:47 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IxPjK1JM0z8Z; Wed, 21 Mar 2018 09:25:46 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3CCC20CF3; Wed, 21 Mar 2018 09:25:46 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8A0C74278C3F; Wed, 21 Mar 2018 09:25:46 +0100 (CET)
Date: Wed, 21 Mar 2018 09:25:46 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Netconf <netconf@ietf.org>, draft-mahesh-netconf-binary-encoding@ietf.org
Message-ID: <20180321082546.pbsja53shgwlu6gv@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>, draft-mahesh-netconf-binary-encoding@ietf.org
References: <48161AFC-484C-4803-AFFF-4E9C0369A008@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48161AFC-484C-4803-AFFF-4E9C0369A008@gmail.com>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Ol-i66BAQsZl4iQCuPWZWT9ZasY>
Subject: Re: [Netconf] Issue #2 for binary encoding: Should the new encoding include the Message layer?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2018 08:25:59 -0000

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/>