Re: [core] removing names from yang-cbor rules

Andy Bierman <andy@yumaworks.com> Thu, 23 September 2021 15:50 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 824583A0FBF for <core@ietfa.amsl.com>; Thu, 23 Sep 2021 08:50:33 -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 IsTzxzXwvqlZ for <core@ietfa.amsl.com>; Thu, 23 Sep 2021 08:50:27 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 3D8023A0FBA for <core@ietf.org>; Thu, 23 Sep 2021 08:50:27 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id u1so136674lje.12 for <core@ietf.org>; Thu, 23 Sep 2021 08:50:27 -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=loTMhviya6AcsfOOjMl4S8CqNkC5yDwbojS/nDOmTq0=; b=wsKw25mD2l9gJbnJxurdoLE/kUbiUSpHof9YnIaDT2EGjKU0SXnPaPm7FLVjFj6EMH Htu79B/a8yAzJGzreWOY8nlOnsqC4muuxzZfFKk7ZYbZzH0lZ6JFTEejDYWEPbcaf6/L eq+5GlHD0NVJa4vWyPJowLelqwrllHw+xWtYzffCWFpPkQ0pSeJIuAlIkENTp7zZiti8 RLNs2KjGocAq/Sy8wIih+ewzOoNh5Bdd98VQsTNZtTxoS2lGZtHp7YXo/yydgHTw9oAV bsxl5oUfgfLyvki6OFfoZYUNDtDk0krL6OPirtElvCjm44tt4wlmstkpYlV7WGSMlOGk 5i/w==
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=loTMhviya6AcsfOOjMl4S8CqNkC5yDwbojS/nDOmTq0=; b=K0cnVcvgzUxS4AmxFs/mwoB0uY/T74HhQAfBZO8bbAA5UUBdiqqPevX6TS/cOSouJh ZZemGu8b0V6BaZegqTMAxJuDxRE7ZGsJamqrvBbAQXHVVLs0DR0XXGjFmi4ItSNChe/V YQbgzQMgwG6j9zVKZC13YkKJiLcWj8t6ICuwWI+8JmobfpeaLsF1UAKBUArFM3DU43yQ Tc6Gs9rD80b9hsMPd7bHrcFFeuz/uURzTrSvw4c+VVmml0jpr5xTaFcUdouldxDSHov8 FehalAfFxqikrqjLjan+qC9UA9hEC1m0nd8g3zvIZBLbO3YZ2JqA8Cdhd9K2KndC2UwO CNLg==
X-Gm-Message-State: AOAM5301Av5/HsPnqjDaD6mYqJRFpsyyv1RJpxQBhJnk9GgN/CWlwPRT RC6l+NdozOsBs22vjb8+wzSoKwxNd3iwFnDeNErU9Q==
X-Google-Smtp-Source: ABdhPJzYACg7La12+A806cFYO8u6WEAaaY5dd1Zq1Rqw1SjwAsXLeJcxZ1pTxCVSnW7Pk7+vX0dhUIscuHBBWY7Lw2k=
X-Received: by 2002:a05:651c:a12:: with SMTP id k18mr5974650ljq.207.1632412223237; Thu, 23 Sep 2021 08:50:23 -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 08:50:12 -0700
Message-ID: <CABCOCHQBqmHm0sYABU3PZf3xRT5Z1os7ayZKLbkRBuGXn0=bCg@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="000000000000b1839805ccab96ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/4sN2gg31gjlOJsmR-zcJ3mlf6og>
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 15:50:34 -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.)
>
>

OK, but YANG has qualified names (e.g. RFC 7951 must be used, not plain
JSON).
I don't see much value for YANG data by using CBOR w/ names vs. JSON.

The name to SID compression will be about 15:1 to 30:1 with delta-SID, while
the number compression (CBOR over JSON) will barely reach 3:1 compression.

If it is optional-to-implement, optional-to-use then that is fine.
At least the Accept header forces the entire response to use
the same encoding so there can never be SIDs and names in the same message.
(I hope).


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