IETF Logo Mail Archive

Re: [Netconf] netconf-binary-encoding comments

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 06 July 2018 15:59 UTC

Return-Path: <evoit@cisco.com>
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 E61F0130E92 for <netconf@ietfa.amsl.com>; Fri, 6 Jul 2018 08:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 6_ECj5twCfrB for <netconf@ietfa.amsl.com>; Fri, 6 Jul 2018 08:59:01 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF30130DED for <netconf@ietf.org>; Fri, 6 Jul 2018 08:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17208; q=dns/txt; s=iport; t=1530892741; x=1532102341; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=znYD8aFRWBFz7YgGrAfwQbS1WrWh/MFZSOjuwscuNkA=; b=Lk41vMM1mis8yQCJiJBOoA1KH9CoRgr4EOTLxabnaRainIAdCQHdMcON 4WYimmVpo3IFnzQBqMizukkwxGQa7NEOExoggRIZku/sWyu7c6+mslE/Q hIFweAMGeumIgf7sby1cnY4o6SWBBcyUMxmHjwCWf8BdTAPFsDwGr1C9d s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DEAADM+T5b/4cNJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYJTdmJ/KAqDcIgEjDWCB5AihQ4UgWYLGAEMhAFGAheCFiE0GAECAQECAQECbRwMhTYBAQEBAwEBIQpBBAcQAgEIFSoDAgICJQsUEQIEAQ0FCIMZgRtkD6kVghwfiDCBNQWIbYFWP4EPgw+DGAEBA4EqARIBCSQJH4JLglUCkWqHZQkChgSCZIYwgUiEDIgMijWHLwIREwGBJB04JjtxcBU7gmmCJBeIWYU+bwGNGIEfgRoBAQ
X-IronPort-AV: E=Sophos;i="5.51,316,1526342400"; d="scan'208,217";a="139488503"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2018 15:59:00 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w66FwxMP009035 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jul 2018 15:59:00 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 6 Jul 2018 11:58:59 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Fri, 6 Jul 2018 11:58:59 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org>, Andy Bierman <andy@yumaworks.com>, Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] netconf-binary-encoding comments
Thread-Index: AQHUFQpFGmG2z4NKtECrmCRZREooWKSCWV3g
Date: Fri, 06 Jul 2018 15:58:59 +0000
Message-ID: <d294d42a2c8c4e8186f49ac5429da06b@XCH-RTP-013.cisco.com>
References: <14395e68-eb71-7766-d4d2-4de0ea67681f@ericsson.com> <CABCOCHRJM5vTgTXcNircjcn6DCqK5fzW3E2rjMM6sb3A3Edz_g@mail.gmail.com> <79d3af9b-dd0c-833b-491f-a25a54a38559@cisco.com>
In-Reply-To: <79d3af9b-dd0c-833b-491f-a25a54a38559@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_d294d42a2c8c4e8186f49ac5429da06bXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ZkZtjc0Cn1sSHdp0mW6IyC-YOss>
Subject: Re: [Netconf] netconf-binary-encoding comments
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 06 Jul 2018 15:59:05 -0000

Over in the Core WG, there is a new draft which intersects CBOR, YANG Push in the context of CoAP:

https://tools.ietf.org/html/draft-birkholz-yang-core-telemetry-00.txt

So as other groups are looking at this space, a position by the WG would seem timely.

Eric

From: Robert Wilton, July 6, 2018 5:18 AM

On 05/07/2018 17:07, Andy Bierman wrote:
Hi,

I think the first-order issue is for the WG to decide if there is a problem to be
solved by this WG, and if so, what is the problem scope.
+1.

I actually wonder whether extending RESTCONF wouldn't be a more efficient path here.  Adding support for CBOR to RESTCONF looks like it would be much easier than adding it to NETCONF.

But then, it is unclear to me what the long term relationship between NETCONF and RESTCONF is meant to be.

Thanks,
Rob




Details like the SID assignments for rpc, rpc-reply, etc do not really impact that decision.

When I brought up this issue 5 years ago there was zero interest in improving the
efficiency of NETCONF. Maybe YANG Push will change that POV.

https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-00

I think this draft should focus on the protocol mechanisms and not define
any media types. Definitions of GPB and other formats are not trivial and need
their own RFCs.


Andy


On Thu, Jul 5, 2018 at 8:07 AM, Balazs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>> wrote:
Hello,
Is this applicable for Restconf? Would a Restconf binary encoding be interesting?

Chapter 2)

- A more detailed explanation of which parts are encoded would be good. What is the top XML element that will be encoded? <rpc>, <RPC-reply>, <RPC-error>, <notification> ? Just referencing a figure in another draft is not enough.

- SHOULD, SHALL or SHALL NOT a client server declare support for the XML encoding? Is that always implicit? State it.

4.2) Shouldn't we also have a JSON encoding here?

I would think that all encodings need some official reference, defining how they are used with YANG: RFC, web link

Is the Thrift and gpb encoding trivial or is it described somewhere or do we need an RFC about it? Please state whichever is the case.

regards Balazs





--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs..Lengyel@ericsson.com<mailto:Balazs.Lengyel@ericsson.com>

_______________________________________________
Netconf mailing list
Netconf@ietf.org<mailto:Netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf





_______________________________________________

Netconf mailing list

Netconf@ietf.org<mailto:Netconf@ietf.org>

https://www.ietf.org/mailman/listinfo/netconf

v2.23.0 | Report a Bug | By Email