Re: [netmod] [core] js review of draft-ietf-core-yang-cbor-12

Andy Bierman <andy@yumaworks.com> Wed, 08 April 2020 16:07 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623053A0F2D for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2020 09:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 58v9_vw4Xtlh for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2020 09:07:35 -0700 (PDT)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 BBA8A3A0F2A for <netmod@ietf.org>; Wed, 8 Apr 2020 09:07:35 -0700 (PDT)
Received: by mail-yb1-xb2f.google.com with SMTP id c13so4005961ybp.9 for <netmod@ietf.org>; Wed, 08 Apr 2020 09:07:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XV6ySZwjt7D3IoeQrKeC1Qk5KSzmaJBewKqrNrT+oiY=; b=q6tBdOjRGkxYelnTuTiFj9WDcy2nPscpll89I6H1vZLqnuAgwRb94SMxJtPPbpzX85 Av2DHlV5VYG3mlXUItFA1c14dlIQZMBoI953ElS/fAr5Rfh0tv8a5j0mHf6NjUJ5FNY9 Wb/mAJ14JTF40pUDw4FXgUSQNlb02jBPiutydC87zpJ3K/irgipNQLQlxWq52Tav+V9/ ZbPrq/FATpXrd9mp1ax+InX4VWTm/BqmOrU8l37FtOFU7zXwOATNErKzDuCyYoxz4bNa gDmFpR8lRPxssxloG3vtM5q+KRoZh/Q6Rum9obtCw5NsVNT+yYQ0pdubemuV+dcW/eRF GqrA==
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; bh=XV6ySZwjt7D3IoeQrKeC1Qk5KSzmaJBewKqrNrT+oiY=; b=gvJ9OQZ9lP6FVYLML1hR+PMRBA3GYrNrqkj9gai/QBqtvwg2OyT/a1HogBegwaQK9E w5LHYLvqAHB8iwluqgAgBGeRIKKPhOtOVCMMzIYA439D4nA7ffi/yqHCP747kPckk1iu UU6n97/BETUXBglQ0jjifYcsOlSu4/DP5Bmr1oLRmqX+sy8AJSucU8DyS3KKdyZSTfNJ qc/EfegYDkiciElI6pg2k2aq4aMhvU8eO9bJen8DR6RnAqIufgckJEdTx0zjQdkn6R4T MHDf8QG0jR6Zime4Nnw7dBZxD0EUDb1zIB5UmBwKs5GmpJNlQEjMBAhhsNmEHEBc7O6V JkVg==
X-Gm-Message-State: AGi0PuZVK6/8zh38mAyXmS7FqzW7chQJ5LNodHTdStFaVflb8tkPxr3T BWJdJ9QUXEOMcI9Ga854muWzClUu8+N8BhLUygCPtg==
X-Google-Smtp-Source: APiQypI7PE9T/IxAQIriT050TlwQgGbOEzw9dyg7Pv+IItSU/lnfOeLvWbXYyw3wSj6pdHmGjF2kdLRru6z2+wqTes0=
X-Received: by 2002:a25:602:: with SMTP id 2mr13371699ybg.359.1586362054237; Wed, 08 Apr 2020 09:07:34 -0700 (PDT)
MIME-Version: 1.0
References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> <CAJFkdRwhxa2T-LVoYfwbMcjjo-dWhwonf_q4B6vGGLuWy5K+BA@mail.gmail.com> <20200407194758.luxnndxxsuixhzfo@anna.jacobs.jacobs-university.de> <16670AE8-DE0D-4444-9F64-ED6C67654886@tzi.org> <20200408065738.l7jnht536vxzacse@anna.jacobs.jacobs-university.de> <0817C3C8-420A-4994-89D4-2CDA150F682B@tzi.org> <D6EC7C7E-F078-4AAD-9F23-97EE5F225E39@tzi.org> <20200408115029.sfcm2p4gebai3y74@anna.jacobs.jacobs-university.de> <0CBA1A2B-E7D0-4A9E-92C0-13F87974F971@tzi.org> <20200408144021.airva4ksdn7xh7bw@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200408144021.airva4ksdn7xh7bw@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 8 Apr 2020 09:07:23 -0700
Message-ID: <CABCOCHRM-PtdC00HQ6vP1YGdNft3j9RC_DUjTJk-8MHzwA2cGg@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Carsten Bormann <cabo@tzi.org>, core <core@ietf.org>, NetMod WG <netmod@ietf.org>, Ivaylo Petrov <ivaylo@ackl.io>
Content-Type: multipart/alternative; boundary="000000000000ba764a05a2c9b2f9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/KNypxR-pSBVwZVPxbm7xB1DVvQE>
Subject: Re: [netmod] [core] js review of draft-ietf-core-yang-cbor-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2020 16:07:38 -0000

On Wed, Apr 8, 2020 at 7:41 AM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Apr 08, 2020 at 01:55:47PM +0200, Carsten Bormann wrote:
> > >> Ha.
> > >>
> > >> Let’s create a registry in yang-cbor for id= values (initially filled
> with id=name).
> > >> -sid can then register id=sid in that.
> > >
> > > He? yang-cbor defines how to use sids as ids so I see no reason to not
> > > also register the id=sid in yang-cbor. I thought we settled on
> > > yang-cbor defines what sids are and the sid id details how they are
> > > assigned and how the number space is managed. This way, yang-cbor is
> > > the base document and the sid document has a normative reference to
> > > yang-cbor and comi has a normative reference to yang-cbor. Is there
> > > a reason that speaks against this?
> >
> > Hi,
> >
> > The media type could simply say “uses the concept of SIDs” or it could
> say “uses SIDs as allocated in -sid”.
> > I’m not sure the media type needs to say anything at all about this, but
> if it does, for completeness I think it would need to do the latter (so we
> can have other media types that get their SIDs elsewhere).
> > That would mean a normative reference from yang-cbor to -sid.
> > The registry trick turns that around.
> >
>
> I want a bit that tells me how instance naming is done, using names or
> SIDs. I want to use this to send a query and tell the server that I
> want to get CBOR encoded data with SIDS
>
>       GET /restconf/yang-library-version HTTP/1.1
>       Host: example.com
>       Accept: application/yang-data+cbor;id=sid
>
> or with names are keys
>
>       GET /restconf/yang-library-version HTTP/1.1
>       Host: example.com
>       Accept: application/yang-data+cbor;id=name
>
> This bit should be defined in YANG-CBOR since this document goes into
> quite some detail defining both options to name data.
>
>

It would be up to the server vendor whether the protocol supported
multiple variants of CBOR encoding.  The intent for CoMI is that
a server without name string support could be implemented.


The question whether alternate schemes can exist to allocate SIDs is
> less important for me. I hope multiple schemes to assign SIDs will not
> be needed - or only needed in case the scheme defined in the SID
> document turns out to be broken up to the point that it can only be
> replaced.
>
> That said: A real complication may be the YANG versioning work. Once
> publishedd YANG definitions are allowed to change arbitrarily, the
> allocation and management of SIDs may get really interesting.
>
>
The SID assignments cannot change once an RFC is published.
Any NBC changes to published modules would require new SID assignments.

Or is the idea that once we conclude the current SID allocation scheme
> to be broken, we go define a SIDplus allocation scheme and then we
> still use SIDs in YANG-CBOR but the meaning of the numbers is entirely
> different, i.e., we use
>
>       GET /restconf/yang-library-version HTTP/1.1
>       Host: example.com
>       Accept: application/yang-data+cbor;id=sidplus
>
> to make it clear that the SID numbers now mean something different?
>


I do not understand why the SID allocation scheme is broken but if future
requirements make it deficient then a replacement (e.g. sid2, sidplus) could
be introduced.



> This may make sense and then it may make sense to define
>
>     application/yang-data+cbor;id=name
>
> in YANG-CBOR and to define
>
>     application/yang-data+cbor;id=sid
>
> in the SID document - which means you can't use SIDs with just
> YANG-CBOR but only in the context of another document detailing how
> SIDs are allocated and managed. Perhaps this is what you have in mind?
>
> Whatever we conclude, it would be nice to get things properly
> documented so that we recall the grand plan in N years from now.



>
>
/js
>
>
Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>