Re: [core] removing names from yang-cbor rules
Andy Bierman <andy@yumaworks.com> Thu, 23 September 2021 14:17 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 D4D8E3A05A7 for <core@ietfa.amsl.com>; Thu, 23 Sep 2021 07:17:16 -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 1x4-citYtTIE for <core@ietfa.amsl.com>; Thu, 23 Sep 2021 07:17:11 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D2F743A059F for <core@ietf.org>; Thu, 23 Sep 2021 07:17:10 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id b15so26618718lfe.7 for <core@ietf.org>; Thu, 23 Sep 2021 07:17:10 -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=NgGmKLjgPZyKCMubr3YNXTgnmKwbVvU/4OOAsbI7HE0=; b=vVVQADF5Z766MsKbuWsBMXxziR08bK9OtnQgHUK/92Uwb+lEiz3a25v7Yhsirbm9LZ 3p5gP/NtKMbwDWXfD42WnhNHKxpTP7zlnCGccTb9XqKDcKoFRRxOZCtto/vQZEW4N1HA lHQOoDeFTIjKWcDsS4Tc2l8egynWUBueGJy7oec/31oYLhdVc+C04NrunAp1LRP+tEpW sfnG4wMc92mbIsoZm+UM8c45P2DJLpptVHH3IZ6nrFQK85Sri/I4W5ahPSWTVjRZHGK8 id/n8WgkXYp21JGdnsyvTonelkOHaM6N/gYIXJQr8tQ+iNg+ESa+pfBClbiK+M2Tvmo1 Kzyg==
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=NgGmKLjgPZyKCMubr3YNXTgnmKwbVvU/4OOAsbI7HE0=; b=pxGeRaBRT3IvnKkz2QvbYj/2Yt32uGFJbZzUwVdLh/4arGbswHSHWBK+c/KDCRqVBe kdpfeHtuvsYttgLLtl+8kGgqocWktRmIavFq3apNcHyf6TtDja17Ki9xDv5Bb2gA0Fqo MTg5FJMDQpP7dVRURO2XqvMUvQb0wqdF827wFjNCfVL0mbq4IFNZUCPK76tNDuk4VEej Zrw6HgDuZK/E5Yyu9NwwMjvjlasHo8c855BaAoXfPRwkRXnPKE7caxtDfTo6u0l9u0uY A1trJhUiXGQ98oh629698VrUJVcyzhLY7DsRCpH0bbwq6HSjNfwpvTU6TLLtBMuLsT4l kKpg==
X-Gm-Message-State: AOAM531hckS1HtJzRkBEiTElYYHlJrCZcmFdzW2MNaYKtVyqD2vTq+vV +W0m+gkHJv1xe8WUaYVOA57T29BCeJ5Fkz9TliSkRw==
X-Google-Smtp-Source: ABdhPJyB6/CrhPP8crWfOpoRQC+LknrG+xE4//jkVeuwVB4OqoBND7RJ/+/eHOwxgSqz89ERmdUvXCJR019HAH0gEMs=
X-Received: by 2002:a2e:804c:: with SMTP id p12mr5547195ljg.344.1632406621743; Thu, 23 Sep 2021 07:17:01 -0700 (PDT)
MIME-Version: 1.0
References: <CABCOCHQUYSq05gFhJ=48pZu=kuRmXDOcaHMVecFia1UFKSxNnA@mail.gmail.com> <B8EE08AB-A3EA-44EF-A885-08F81D8947A4@tzi.org>
In-Reply-To: <B8EE08AB-A3EA-44EF-A885-08F81D8947A4@tzi.org>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 23 Sep 2021 07:16:50 -0700
Message-ID: <CABCOCHRJRDopozQ+3NcHvK3u4oOoGMSZFAQFos_JtZmRM59Ldw@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="000000000000d17d1305ccaa484a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/YaoNFJRn-byThjJNxf-qe4_vaz8>
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 14:17:17 -0000
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