Re: [core] removing names from yang-cbor rules
Andy Bierman <andy@yumaworks.com> Thu, 23 September 2021 18:07 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9163A1622 for <core@ietfa.amsl.com>; Thu, 23 Sep 2021 11:07:29 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20210112.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 i19jglfxoHfV for <core@ietfa.amsl.com>; Thu, 23 Sep 2021 11:07:23 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 2C3653A161C for <core@ietf.org>; Thu, 23 Sep 2021 11:07:22 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id i4so29416565lfv.4 for <core@ietf.org>; Thu, 23 Sep 2021 11:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0x7pNwzNOc+PMkKM056FVx3c3UXUTWQsxFVfSAUpkOc=; b=ngufvjuBhenqhGks1hil1iY8uS45ABqTdUDqOtT+q9RT7m3OikJnjoJJstHqrD40iM rJNOdyYedHQ/zvkfkjVJu61jtJHRZwOa9zrtnfO70kV4I1NBpLwf3jn4q+gHaNO5VWXX xESNeCka4RxSJ5tRdvpZsVreprPNXb/3BG2LzQzJRD+YzQYlYyo2ZmxUk3wXxgSaC8WP Ttwn2QXmktCIZHViOFaOOX1nJh5VlFipAzWODV7DNSxnxroufYRNWkYHZkkMvr/TxTB4 NNXMVOoA4NdWlgVvqZqgEFOX0VowHghtCD1Y+b6NGpdEAjOUJL9fhZMo31mzV1tooxwR /6cQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0x7pNwzNOc+PMkKM056FVx3c3UXUTWQsxFVfSAUpkOc=; b=0gLtXZq0JI0y9GCtGpLWTPB635lw2h/aEDMeYxA7LSl9wQ3TJQV8gBOkjtf1eDZKUC SJPICmDvvWiRt0LNIhiwcpoRfcSnU/DWH9wVMDGj0f0AOm6vmcVzKw3amu9HzMu2aDGv vnpEPYHNaXbNtUyuEzeUp5ErfF44uvhrusEPy4fz3rvJhooYlCiG1YWaLaKxlYUaNBNH Xvaj14UNww6E1yIGBbcMdcdSE5aeJbPH/jZRsLU2XSTj/Bi2vunAYrqN9N/Is99xy496 L2b7LoE2Ef0Q1I//1qEf5Qge0bcrtQrJGfGSL8elCOUtIHo564WaNzT68lNZIZ6MyvxQ 3SXg==
X-Gm-Message-State: AOAM533ZzxfMh5ZLXykbukZVhAe+kWNTGVEmV9tY/VmOycveKTfwORTG KPq4YOM7poDLRzjykPtvvCtP0yk/d5QpBd0Q3iic8g==
X-Google-Smtp-Source: ABdhPJz3s95a0h8Cf7byW3jrQkat/J2BfB1fvTtCEIE5R46bK8DLejdMlg+W3NBFSYKszRwJp96A/85GxxUhDkoH18A=
X-Received: by 2002:a2e:131a:: with SMTP id 26mr6603793ljt.1.1632420440698; Thu, 23 Sep 2021 11:07:20 -0700 (PDT)
MIME-Version: 1.0
References: <CABCOCHRJRDopozQ+3NcHvK3u4oOoGMSZFAQFos_JtZmRM59Ldw@mail.gmail.com> <9A230719-4BA3-4033-A80B-48862446C45E@tzi.org>
In-Reply-To: <9A230719-4BA3-4033-A80B-48862446C45E@tzi.org>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 23 Sep 2021 11:07:09 -0700
Message-ID: <CABCOCHR=u8ZQRGrYAC3yonpYWCr12z=zQf0P=PuviRRFKLWQsg@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "Murray S. Kucherawy" <superuser@gmail.com>, Core <core@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007e0edf05ccad8099"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/tbfP1jOZOnRzQdsLkhAXR0uKgKE>
Subject: Re: [core] removing names from yang-cbor rules
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Sep 2021 18:07:30 -0000
On Thu, Sep 23, 2021 at 8:25 AM Carsten Bormann <cabo@tzi.org> wrote: > Strings would not be used with constrained devices. > > The point of the string-based names is to ensure that there never is a > reason to use text-based encodings (XML, JSON) with yang. > It is a completely separate choice. > (Supported by Accept: in http.) > This text in sec 3 implies that text and SID names can be mixed in ad-hoc fashion. This specification supports two types of CBOR keys; YANG Schema Item iDentifier (YANG SID) as defined in Section 3.2 <https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor#section-3.2> and names as defined in Section 3.3 <https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor#section-3.3>. Each of these key types is encoded using a specific CBOR type which allows their interpretation during the deserialization process. Protocols or mechanisms implementing this specification can mandate the use of a specific key type. IMO this section should clearly identify the requirements in terms of the Content-Types defined. https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor#section-9.1 How about text that says YANG SID keys MUST only be used with application/yang-data+cbor; id=sid and name keys MUST only be used with application/yang-data+cbor; id=name. Andy > Sent from mobile, sorry for terse > > On 23. Sep 2021, at 16:17, Andy Bierman <andy@yumaworks.com> wrote: > > > > > On Wed, Sep 22, 2021 at 9:35 PM Carsten Bormann <cabo@tzi.org> wrote: > >> Clearly, SIDs are the major innovation here and they are the normal way >> to use Yang-cbor. >> >> I don’t agree the string variant should be removed. This takes Yang-cbor >> out of the game for “big-web” applications. >> >> Instead, we should make sure to explain that strings are a special option >> that you chose wholesale when you need it, not something you switch to from >> SIDs randomly. >> >> > The problem with this approach (no negotiation, either peer sends SID or > string at any time) > is that it forces complexity on a constrained device that a giant NETCONF > router is not > even expected to support. It also forces a constrained device to store the > string names. > > > Andy > > Sent from mobile, sorry for terse >> >> On 23. Sep 2021, at 01:02, Andy Bierman <andy@yumaworks.com> wrote: >> >> >> >> >> On Wed, Sep 22, 2021 at 2:54 PM Michael Richardson <mcr+ietf@sandelman.ca> >> wrote: >> >>> >>> Murray S. Kucherawy <superuser@gmail.com> wrote: >>> > I'm happy to take credit for a keen observation such as this, but >>> this >>> > was actually Eric Vyncke. >>> >>> sorry, if I screwed that attribution up when creating the issues. >>> >>> >> I also wonder about this. I think that the SID concept is >>> advanced >>> >> enough that we can just rely upon it. Murray's comment is that >>> if we >>> >> support two things, then an encoder needs to pick one, and it's >>> likely >>> >> wrong. Since this is often data at rest, there is no possible >>> >> negotiation either. >>> >> >>> >> I propose to remove section 4.1.2: >>> >>> There are also other parts of the document which refer to names as well. >>> I have no use for names. >>> >>> >> I agree it is better to remove the string name variant and only support >> SIDs as names. >> It will be important for the client to be able to obtain the SID File URL >> list >> representing all SIDs used by the server. This is needed before the >> client can >> use any data from the server (including the CORECONF YANG library). >> >> The client will have to be hard-wired with the SIDs or capable of >> consuming SID files in JSON format. >> >> >> >>> -- >>> Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT >>> consulting ) >>> Sandelman Software Works Inc, Ottawa and Worldwide >>> >>> >>> >> >> Andy >> >> >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >>
- [core] removing names from yang-cbor rules Michael Richardson
- Re: [core] removing names from yang-cbor rules Murray S. Kucherawy
- Re: [core] removing names from yang-cbor rules Michael Richardson
- Re: [core] removing names from yang-cbor rules Andy Bierman
- Re: [core] removing names from yang-cbor rules Carsten Bormann
- Re: [core] removing names from yang-cbor rules Michael Richardson
- Re: [core] removing names from yang-cbor rules Andy Bierman
- Re: [core] removing names from yang-cbor rules Michael Richardson
- Re: [core] removing names from yang-cbor rules Carsten Bormann
- Re: [core] removing names from yang-cbor rules Andy Bierman
- Re: [core] removing names from yang-cbor rules Andy Bierman