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

Andy Bierman <> Fri, 29 March 2019 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC57E12001B for <>; Fri, 29 Mar 2019 09:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hPkgnKGwIvoT for <>; Fri, 29 Mar 2019 09:07:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7EF8120013 for <>; Fri, 29 Mar 2019 09:07:31 -0700 (PDT)
Received: by with SMTP id r25so1792806lfn.13 for <>; Fri, 29 Mar 2019 09:07:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Xfii+whgIOP+oBIci/yx8aFW8612MAYzhpH6WuTS4iQ=; b=cWABf5HnLY1zKT2FGJYXhJ5gLEu/Xl6hK1mIePLeWKpifRQ20femKTWB2mWhIIqI/X cagTLj5xKE11uJLKHpYZgCJcm/v7asFJUY2UlyFhd589YHTLAO5KPwYUDvtd/dVrcN2z Oyy8OGbAjJSqf+vUjSvspQS5hPK7pQ/WkyfTy2u8mvenPOPqU3WvQ2QYMsaB7tBiW8md CheFFVg/lhVnXC0UxtMZf8m3XV0aUPFt+lY/Dtin1WRI6fvqvzD6Lt9qQWHU0FCn0B7m cMjv+Eyk/4BV8llu72nDqAfNRCa50WiE2eKiH+tchF9Vq3HgU0a/0y+ZwavaB37fDb3R MjCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Xfii+whgIOP+oBIci/yx8aFW8612MAYzhpH6WuTS4iQ=; b=XnzDZxy35kXELsDs6v6XtRCk6VMUACqQIk61YN2m4+LqXxon+gns9ohD3cCfJzNcuG rL9ljTeFvoF7NogAZqXPwPkIz3g9TXvKaqe4/jXE19sTccz2v88aiWGxRg65QM8eP5bb nD4K1uflAXRf+uPCxoBfaRV6Uf6OqeJauCd5VJ9Q5EjdVSrpyMuUgUB02KgD7URPS1uw pes+aspi2/QFKOfAoRtB4FmCKR5xT8E4FsMIOuDsyhv+PXgEvzF0FYoaeCbOvyXrIQRT uVT7/lUXUasiPn2ct4cPUtO6sfFfHEN9fKb2he5pTy6rkRfPmmtjlmh9h1jbzPfc5dfS Uuxw==
X-Gm-Message-State: APjAAAXxrYRZb3T3DDifgwkjTg/mLmhHzjslMsUEuoqpmjrIkBEMCr24 6OONQi5g3q9+Sbz1zIyaKfqBD9T+Ddj10SK1ppqprA==
X-Google-Smtp-Source: APXvYqxcdH+uZQDh8kgBSUKH0OZm+QfqIbSqlVx5eImGjHLZD727auTHSN0wsril2KkIPPwbZAm/gwLMwWsDqXfPrSo=
X-Received: by 2002:ac2:489a:: with SMTP id x26mr8700849lfc.49.1553875650026; Fri, 29 Mar 2019 09:07:30 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Fri, 29 Mar 2019 09:07:18 -0700
Message-ID: <>
To: Juergen Schoenwaelder <>, NetMod WG <>
Content-Type: multipart/alternative; boundary="00000000000025342d05853ddedf"
Archived-At: <>
Subject: Re: [netmod] yang next issue #46 binary encoding support
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Mar 2019 16:07:35 -0000

On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <> 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.

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

> 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

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:

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.

> /js

> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <>
> _______________________________________________
> netmod mailing list