Re: [netmod] yang next issue #46 binary encoding support

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> [e-mail]> wrote:
> 
> > Hi,
> >
> > this is issue is closed but I wonder whether this is correct. I have
> > several questions looking at the issue on github:
> >
> > - Why is this not a YANG issue?
> > - Which workaround is better?
> > - Why is this tagged as a NETCONF issue?
> >
> >
> Did you mean this should be NETCONF issue?
> It is more of a protocol problem then a modeling problem.
> The goal is to use the model unaltered.
 
I think it would be valuable if say the definition of ipv4-address
could state that a canonical binary representation is of type binary {
length 4; }. Doing this is only meaningful for some types but it would
allow to add more binary representations over time.
 
> > If we want to support binary encodings, we need to allow modelers to
> > define which types map to a canonical binary representation in
> > addition to the canonical string representation. As stated in the
> > issue description, hard-wiring some types in the encoding
> > specifications is very limited.
> >
> > In terms of backwards compatibility, this issue should IMHO be tagged
> > high (adding binary encoding for some types does not cause any
> > backwards compatibility problem since so far we have only strings).
> >
> >
> Not so sure.
> The base64 encoding could look like a valid string.
> The receiver must know a binary type is being sent (XML and JSON both fail
> here, but not CBOR).

I am talking about CBOR, not about XML or JSON. I want to provide
hints to CBOR (or similar binary encodings) that values can be
represented in a different format. I do not expect these hints to be
used by XML or JSON. If you need binary encoding efficiency, use CBOR
instead of JSON.

> > While I do not have a solution proposal, I think this issue is worth
> > to look at and we should not close it right now.
> >
> >
> I have a solution proposal, but I have not implemented it yet, so it it not
> detailed...
> 
> Both sender and receiver need to agree on the binary encoding and how the
> data is tagged as binary.
> 
> This expired draft should address that problem:
> https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> 
> For every type T that they agree on, there are standard T.b2y() and T.y2b()
> conversion functions.
> There are also some extensions to define conversion templates so vendors
> can add their own types.
>
> The YANG modules do not need to actually be altered.  The peers will
> negotiate the
> set of types that will be sent as binary when the session starts.
> The receiver knows T and the SID for each object, and will accept either
> the YANG or binary encoding.

Sounds complex for me to negotiate this. I rather say once that a
binary encoding can ship an IPv6 address as type binary { length 16; }
and then CBOR will simply do the right thing.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>