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