Re: [netconf] [core] YANG encoding in CBOR

ivaylo petrov <ivaylo@ackl.io> Mon, 25 March 2019 06:53 UTC

Return-Path: <ivaylo@ackl.io>
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 C0E0D120364 for <netconf@ietfa.amsl.com>; Sun, 24 Mar 2019 23:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com
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 cuHlmLFZrQ5a for <netconf@ietfa.amsl.com>; Sun, 24 Mar 2019 23:53:16 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8307F12025C for <netconf@ietf.org>; Sun, 24 Mar 2019 23:53:16 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id f3so7623543wmj.4 for <netconf@ietf.org>; Sun, 24 Mar 2019 23:53:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6EMXkItCK0kpVrtZFSfnBdseXv0IoyzlCNFV9Uoc6Cg=; b=pTHtEd+lvTFdjvSH5N5XqRhTMEM/KVNAhBSvwc48SJJwx3GicVu0V4wcSBTePmY7iW sM2WEvzwjAR1szLEX0x055M4ooel3u0AeI0qBZ+Ulo9/07o/SqtaY6s7k1wrqNXDAgl4 06VaYsXNl6631FUiSq4RSEuk+SxmPi+Fuk7o+45xCz2kVf/RUqpdHilkkoqzqqo0gFXv OX+ELoz2e6xP57kPKhobnIS0J2WD7a5sziyldNXxhrbZq12O4Q0ovTYUJala3TSk51CT diYVzDX6qQOKCvvHH+54JsWkZDfX5BgvdUdEke5rhElQcmJWONKPUUVC3iFCLYEi1e3l Z8uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6EMXkItCK0kpVrtZFSfnBdseXv0IoyzlCNFV9Uoc6Cg=; b=J90ZJk6vAaWDbR1Cs+RdEnFHRc4qw1N2nm1EQycxu9BX04OGNdz9ez7VE2c7/xjFI+ ZDSjGNUlfoFOWsx7FczXmLE8Us6LZs9f1M4Xq/6WNGv3DL/Tpoh+dvRsEXG/R+TWwT/w n5Nu/mtcqeeqxAzfThvELgO9DnvGbxSswje1s+WhZ5RCVBdEFZs9oWN6krsyixWdwFMX 2jFnylJeSxVGmjGCQ7zWAUc9fZRPO749PS0vQYfuyQ8R6pZWy1z/sSKAkqUGfsTVVFLf mngMbkJfl6DxcM90XTAqh+HtjBfYCVbdwc5dyRSfYGQ/6D5RPK+XpJ/SB+FXgSAaZzNJ 43dA==
X-Gm-Message-State: APjAAAUP/722i2+5dJq5bE2RJOd3ByY0K03jf+7WwTWqpsOL8zQu+OzR 2aewZUghxt7ENRCh110sLqp9RHXP0qtAkgajV43IH8gkh30=
X-Google-Smtp-Source: APXvYqyKqaozDkTQNmsPN1bMjWMucG7NQz1/PLpk/fDj/uryl40yjeXrsDu+uDVKKtovtJ56nPA/12JjWslMDCtDe40=
X-Received: by 2002:a1c:7008:: with SMTP id l8mr9927014wmc.63.1553496794858; Sun, 24 Mar 2019 23:53:14 -0700 (PDT)
MIME-Version: 1.0
References: <6235c6683ff14848a661f8b8cec94280@XCH-RCD-007.cisco.com> <BL0PR06MB5042823429DB7CDA0F33408B9A430@BL0PR06MB5042.namprd06.prod.outlook.com> <588401AB-483E-40F5-95BB-20A066E56DAC@tzi.org> <15fbaf84b20343a1b83f40b571149a14@XCH-RCD-007.cisco.com> <1ADF8201-ABB4-44FD-A515-F3F8E0DBF5FC@tzi.org> <20190323101003.gp3zvsvqqwc26jip@anna.jacobs.jacobs-university.de> <6BAAAC0E-F91B-411B-8768-F628C57FF2E0@tzi.org> <20190323133519.nv6sw72upxchr7p3@anna.jacobs.jacobs-university.de> <3D7C33C9-CB86-4965-899D-93C4B7343DF7@tzi.org> <CABCOCHRcEPUB=Yf2Vdf6ZpN-SxjYeMPL_54-EKMYSpUO9b-RwA@mail.gmail.com> <640708E8-F80E-49EE-9AEF-DA8DAEE3AA57@tzi.org> <CABCOCHTNWz=VWZP3BzYxdBXTFytYyJjge2gX6fihz1B1Xf5bOQ@mail.gmail.com> <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org>
In-Reply-To: <5D0AEDAC-4AD2-4DFD-BF19-EA210773EF66@tzi.org>
From: ivaylo petrov <ivaylo@ackl.io>
Date: Mon, 25 Mar 2019 07:52:47 +0100
Message-ID: <CAJFkdRwUwLPhA=NsTZa6cd1hOdq8aDYp6-kkkh1S+UaB1ViVeQ@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Andy Bierman <andy@yumaworks.com>, "netconf@ietf.org" <netconf@ietf.org>, "core@ietf.org" <core@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009e17290584e5a821"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/8ALUEeP3JvhbM0DUA_6ufgYrh-Q>
Subject: Re: [netconf] [core] YANG encoding in CBOR
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: Mon, 25 Mar 2019 06:53:20 -0000

Hello,

On Mon, Mar 25, 2019 at 7:23 AM Carsten Bormann <cabo@tzi.org>; wrote:

> Hi Andy,
>
> > On Sun, Mar 24, 2019 at 3:24 PM Carsten Bormann <cabo@tzi.org>; wrote:
> > On Mar 24, 2019, at 12:29, Andy Bierman <andy@yumaworks.com>; wrote:
> > >
> > > The answer seems to be simple but inefficient:
> > > Always encode bits or enumeration as a string, if this is within a
> union type.
> >
> > For enum values within unions (which are already handled specially by
> giving them a CBOR tag) we could simply use a SID (that we then would have
> to generate for each enum value) instead of a string.  We could also extend
> this to enums outside unions; but here the recurrence to the (outside
> unions unambiguous) value sounds better to me.
> >
> > Bits.  Oh.  Same procedure, I’d say.
>
>
> > On Mar 24, 2019, at 23:52, Andy Bierman <andy@yumaworks.com>; wrote:
> >
> > This seems like it would make the SID file very complicated.
>
> Not necessarily:
>
> > Not sure it would work since leaf/leaf-list can define their own types.
> > Plus, all the enum typedefs would have to be numbered this way.
>
> Right!
> It would amount to defining an identifier scheme for all the so far
> anonymous enums (and bits defs, I gather).
>
> > Maybe the SID authors can comment on how this would be done.
>
> Well, such an identifier scheme would benefit the whole YANG ecosystem, so
> you can have a transition from “first match wins” to proper name
> equivalence.  So we would need to do it in a way that over time it can
> become part of the core YANG definition.
>
> We can maybe cheat:  Use strings for enums inside unions for now, and
> values only outside.
> But it would be good if the SID files generated (and registered) for a
> YANG module already had those enum/bits type identifiers so we only have to
> do the SID generation once, so I’m not sure if I like cheating; doing the
> SIDs for those identifiers right from the outset would win so much more.
>
>
[IP]: Carsten, your idea for the good solution would be to keep the way
enum values are sent now outside of unions and only send the SIDs inside
unions, is that correct? If so, this sounds as a very good solution to me.
It might add a bit of complexity in the SID generation, but I would expect
it to be rather small.


> So does anyone have an idea how such an identifier scheme might look like?
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


Best regards,
Ivaylo Petrov