Subject: [netconf] Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities)

From: Qin Wu <[email-masked]>
Date: Wed, 4 Aug 2021 08:17:19 +0000

Hi, Mahesh:

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.

2.       Compression mode is not header compression defined by HTTP2.

3.       Right now, we haven't seen any standard documenting compression mode. Efficient XML Interchange Capability for NETCONF has been proposed before

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.

Hope this clarify your comment.

-Qin (On behalf of authors)

---

From: Robert Varga <[email-masked]>
Date: Thu, 12 Aug 2021 00:48:30 +0200

> 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)
> 
> 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.
> 

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).

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

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