Re: [core] Review of draft-ietf-core-yang-cbor-15

Ivaylo Petrov <> Mon, 14 June 2021 06:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A70BE3A147F for <>; Sun, 13 Jun 2021 23:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VcACzTjXfoDH for <>; Sun, 13 Jun 2021 23:05:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 568DD3A147C for <>; Sun, 13 Jun 2021 23:05:05 -0700 (PDT)
Received: by with SMTP id y13-20020a1c4b0d0000b02901c20173e165so4133414wma.0 for <>; Sun, 13 Jun 2021 23:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tP0NfDXCt0DITZ9c0dz7JZ3vGp+N+OjNomPKgXwHpB0=; b=NzLvDqDhHCz9WD2pzW97QUk6HILbyPrnx+qIug7Xz4PL710LiP3m9R77Kf/lOWAAY3 94pPDYfP2CR5w+uv4iQ9Mq0zkgLp/RPjKQ0kcsL9K+pe2XMKBEaebW2s+uATowkkP9kK EviAOB9fauDUQlpv3sgeWp3r2az7dJhXVSIp8SOPUE1DEKlHjY7rBx6HGiKdlpk1uHVq v4OhNPJx4c5bgMTInHlVuQTzlqViYstFkmMPeiJ0F1c60Tfgdw5w/TwlLz41wR90j+4S q2Hsj1V5krXq4scNkqFTAVqtFqdq2PEY28BzoG65axY1b005Tv/fAv9SSKr2E4J63uoB j+UA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tP0NfDXCt0DITZ9c0dz7JZ3vGp+N+OjNomPKgXwHpB0=; b=G5M7S6cSEHh+2XBVwhSLVZyE6T1j1OfbFXPWdvheTYrPtm8uRhypdDqLzf1yH5JH2g ayO60odV6+5szuJlzMi3XAVSImsNTfsSUTtyDM+uL1hCM2cE+q9cR38wDGutvzuK1vKs JpvZ2Tv7eWdWRtdZ88YZOJI/Qc1dr4CvaBK1U42agb0SS9P5XWQnSThfWoAnE5ls36/l rT8JJw29bH69CLl0xjZHDniTknIR8H8i+nLQQv7HJD5oiqFzLo5iFKXi1edEgugeFeCP GDjE+yoKDX3EQproo3g2jWzJXcL7j3UZH3wul84wFZJrGlYX/TsASc6R5+vOkK+cxs5X HRrQ==
X-Gm-Message-State: AOAM532QQaPRrVocOEtsQST23J9iLtid/vnUCLYrHT992AeC/egGCem1 H4FalY+fNe5iZoR+g2dw3w84gQWnLBYZLxuukx8Gzg==
X-Google-Smtp-Source: ABdhPJzNr5uGmFyywYwcw673Dt9VN7+/BfPpwmZ6yTkAfp39Uch/KSksRotMT4NtTP38baFdc+Rh9YptVNt3mRhnfDM=
X-Received: by 2002:a1c:c256:: with SMTP id s83mr14386120wmf.86.1623650703659; Sun, 13 Jun 2021 23:05:03 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ivaylo Petrov <>
Date: Mon, 14 Jun 2021 08:04:37 +0200
Message-ID: <>
To: Francesca Palombini <>
Cc: "" <>, "" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [core] Review of draft-ietf-core-yang-cbor-15
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Jun 2021 06:05:12 -0000

Hello Francesca,

Thank you for your review and apologies for the delay! Please find our
answers to your questions below. The diff with -15 is available here
[1]. The updated version is available as txt [2] and as html [3].



On Wed, Feb 24, 2021 at 1:41 PM Francesca Palombini
<> wrote:
>  Thanks for the work on this document. I have reviewed it and have some comments. Please handle these comments together with the Last Call comments.
> Chairs: I believe it would make sense to request a review from YANG Doctors for this document. Let me know if you need help setting that up.
> Thanks,
> Francesca
> ==
> 4.4.  The 'list' and 'list' instance(s) - should this second 'list' be "subset of 'list'"

[IP]: There were places where instances were used as instantiations of
schema nodes and places where instances were used instead of entries.
I tried to clear this out.

> ==
> Section 4.6:
> anyxml value MAY
>    contain CBOR data items tagged with one of the tags listed in
>    Section 9.3, these tags shall be supported.
> Why not BCP 14 SHALL?

[IP]: For certain types of data we can know from the CBOR type what is
inside the anyxml (true/false/null, etc). For others, that is not the
case and that's where we need the tags.

> ==
> * General question: about the SID values used throughout the document: as far as I can tell these are not allocated right now (and they will take some time to get registered as defined in core-sid document) It might be good to add a sentence about where the SID values from the examples come from.

[IP]: I believe most/all of those values can be considered fictional
and provided only as examples, hence the need to provide the element
being encoded each time. I believe this makes reading the text also
easier as you are not expected to remember information for too long. I
will ask my co-authors if there is specific reasoning behind the
values and add that sentence.

> ==
> Section 6.6 (and other sections that use tags defined by this document):
> There is a new CBOR tag appearing in this section's example, tag 44. This is quite surprising without any text. Although the registration follows the template from RFC8949, I would have expected to see some descriptive text about the tag (and not only appearing in the sentence "The encoding MUST be enclosed by the enumeration CBOR tag as specified in Section 9.3." - note that section 9.3 does not specify how to use the tags).
> This is valid for the following sections specifying new CBOR tags as well.

[IP]: I am not certain what kind of additional text would be useful
for the reader. Is the fact that inside tag 44 there needs to be an
encoding of an enum not clear or is it rather why is that tag
necessary. Or maybe something else?

> ==
> Section 6.7:
> I find it hard to understand the example, without any indication on which bits are set.

[IP]: Modified

    The following example shows the encoding of an 'alarm-state' leaf
instance with
    the 'critical', 'warning' and 'indeterminate' flags set.


    The following example shows the encoding of an 'alarm-state' leaf
instance with
    the 'critical' (position 3), 'warning' (position 8) and
'indeterminate' (position 128) flags set.

> ==
> Nits
> - expand acronyms on first use ( e.g. NETCONF, RPC, see )

[IP]: Done for acronyms that I noticed.

> - move YANG SID terminology description before delta description.

[IP]: Done.

> Section 4.5
>    module event-log {
>      ...
>      anydata last-event;                # SID 60123
> Please close the parenthesis of this example

[IP]: Done.

> _______________________________________________
> core mailing list