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

[Andy Bierman <[e-mail]>]

On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
[e-mail]> wrote:

> 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.
>
>
OK, but this would require new type names.
You cannot simply change some standard type to be a union with a binary
type.
This forces all implementations of that type to support the binary variant.
That breaks old clients that worked with the version before the binary
variant.

The ripple effect on the models changing types would be non-trivial.
Using this union-type approach forces every protocol to support the binary
encoding,
yet base64 in a union with strings is very error-prone.


/js
>

Andy



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