Re: [netconf] Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities)
Robert Varga <nite@hq.sk> Wed, 11 August 2021 22:48 UTC
Return-Path: <nite@hq.sk>
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 0DB073A2813 for <netconf@ietfa.amsl.com>; Wed, 11 Aug 2021 15:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 kTpbgdabu4eQ for <netconf@ietfa.amsl.com>; Wed, 11 Aug 2021 15:48:36 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8633A280D for <netconf@ietf.org>; Wed, 11 Aug 2021 15:48:34 -0700 (PDT)
Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 5B9E6243A55; Thu, 12 Aug 2021 00:48:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1628722111; bh=4aPz5S+HCCE/YqbQp1Q/AJ7rD4ePPoy1XrbpCijXeAc=; h=To:References:From:Subject:Date:In-Reply-To; b=RtHkakuHBzrAfEZzlbsrLXnDqVH/UfW/HAtYmId1i2uP2xx9wNTx9Be7XlFy04CX6 vV75hGalu/V94cLyxctOgqAz9yw0iqq5pi+Ggdx2WG6NnW4JX9wZGQN+H1qircFqZA mjy6TCQsE/PJEgUoWTRJj71ko2yAzZhh2mf48U+M=
To: Qin Wu <bill.wu@huawei.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <b56baf2d47ca4be3a3da983850d5f0f3@huawei.com>
From: Robert Varga <nite@hq.sk>
Message-ID: <c84878a1-5f22-361a-9755-3f80bcb417e7@hq.sk>
Date: Thu, 12 Aug 2021 00:48:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <b56baf2d47ca4be3a3da983850d5f0f3@huawei.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="aYxeEfJf2WhiaQFCU1SXL3t0R5Ffp82d5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/rSgYR1-hEh96Ksv-wJ929E2p_DQ>
Subject: Re: [netconf] Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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, 11 Aug 2021 22:48:42 -0000
On 04/08/2021 10:17, Qin Wu wrote: > Hi, Mahesh: Hello everyone, > One of comments you raised in the meeting on > draft-tao-netconf-data-export-capabilities-05 > (https://datatracker.ietf.org/doc/html/draft-tao-netconf-data-export-capabilities-05.txt) > > is the relation between compression mode and Encoding format. > > Here is a few clarifications: > > 1. Compression mode is not encoding format > > Compression mode indicates that the server support data compression or > deflate or gzip compression supported by NETCONF. The deflate or gzip > compression will be applied to xml file. > > It is independent from what encoding (e.g., JSON, XML, binary) is chosen > for exported data. Perhaps we should be using different names? I think the modeling intent is really to reference various media types: dec:xml and dec:json correspond to https://datatracker.ietf.org/doc/html/rfc8040#section-11.3 dec:cbor corresponds to https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-16.html#name-media-types-registry dec:gpb corresponds to ??? Converting between encodings routinely requires understanding of the YANG model (for example instance-identifiers in JSON vs XML). > 2. Compression mode is not header compression defined by HTTP2. > > 3. Right now, we haven’t seen any standard documenting compression > mode. Right, but compression (in the bit stream sense) is probably best left to the transport protocol -- SSH/HTTP can routinely handle that. This is more akin to HTTP's Transfer-Encoding, I think. Efficient XML Interchange Capability for NETCONF has been proposed > before > > https://datatracker.ietf.org/doc/html/draft-varga-netconf-exi-capability-01 > <https://datatracker.ietf.org/doc/html/draft-varga-netconf-exi-capability-01> > > but it doesn’t reach any agreement. The idea is very close to what we > propose in draft-tao-netconf-data-export-capabilities-05. But still > different. Right, and then the exi-capability draft would define an identity derived from dec:binary (and probably a media type as well). Not that I plan to pick it up again anytime soon :) Regards, Robert > > Hope this clarify your comment. > > > > -Qin (On behalf of authors) > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >