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

From: Michael Richardson <[email-masked]>
Date: Sun, 19 Sep 2021 16:53:16 -0400

Hi, in Murray's review, he asks about why we have two ways to encode keys for
YANG-CBOR.  This review comment is captured at:

https://github.com/core-wg/yang-cbor/issues/54

   A generic comment about the operational issue of supporting TWO ways to
   encode a data node: either normal string or the SID. This means that
   either there is a 2-way negotiation mechanism or that all CORE nodes must
   support both encoding and have agreed on a common SID mappings. Section 7
   only briefly touches this issue with "Content-Type" but not with
   "Accept".

   -- Section 4.2.1 & 4.4.1 --
   BTW, I like the idea of encoding a container with sequential SID and the delta CBOR encoding ;-)

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:

  4.1.2.  Using names in keys
     CBOR diagnostic notation:
     {
       "ietf-system:hostname" : "myhost.example.com"
     }

     CBOR encoding:
     A1                                         # map(1)
       74                                      # text(20)
          696574662D73797374656D3A686F73746E616D65
       72                                      # text(18)
          6D79686F73742E6578616D706C652E636F6D

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 19 Sep 2021 23:10:01 -0700

I'm happy to take credit for a keen observation such as this, but this was
actually Eric Vyncke.

-MSK

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Sep 2021 17:53:44 -0400

Murray S. Kucherawy <[email-masked]> 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.
    >>

There are also other parts of the document which refer to names as well.
I have no use for names.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Sep 2021 16:01:32 -0700

> There are also other parts of the document which refer to names as well.
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.

Andy

>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Sep 2021 06:35:41 +0200

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. 

Sent from mobile, sorry for terse

> On 23. Sep 2021, at 01:02, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> 
>> On Wed, Sep 22, 2021 at 2:54 PM Michael Richardson <[email-masked]> wrote:
>> 
> 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
> The client will have to be hard-wired with the SIDs or capable of consuming SID files in JSON format.
> 
> 
>> 
>> --

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Sep 2021 07:16:50 -0700

On Wed, Sep 22, 2021 at 9:35 PM Carsten Bormann <[email-masked]> wrote:

> 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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Sep 2021 10:38:52 -0400

> Clearly, SIDs are the major innovation here and they are the normal way

Agreed.

    > I don’t agree the string variant should be removed. This takes
    > Yang-cbor out of the game for “big-web” applications.

okay.  But, a lot of the document is about how to make up these names from
the YANG content, and it seems that there are a lot of bugs in those sections.

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

In ietf-anima-constrained-voucher, we are adding text to say that SIDs rule.
(Actually, we consider this morning if we can get to the point where yang-sid
can be an informative reference only)

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Sep 2021 17:25:13 +0200

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

> On 23. Sep 2021, at 16:17, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> 
> 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
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Sep 2021 11:43:25 -0400

{I was wrong to CC Murray, let's remove him from the CC}

    > Strings would not be used with constrained devices.

I think that we all agree with this.

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

okay, so does it need to be in the same document?
It seems more complex, and it (the document) would benefit from having active
implementers using it.  While I agree with your goals of not using text-based
encodings, it does not to me feel like we filling an actual market need.

That is, we have no running code.
If we were taking this document to IS, then we'd wind up removing all the
name-based stuff, since it has not gotten any interop testing.

Maybe we should just split the document now?

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Sep 2021 08:50:12 -0700

On Thu, Sep 23, 2021 at 8:25 AM Carsten Bormann <[email-masked]> wrote:

> reason to use text-based encodings (XML, JSON) with yang.

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Sep 2021 11:07:09 -0700

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