Subject: [core] map (5), ordering vs YANG SID in ietf-core-yang-cbor

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2017 23:03:36 -0400

Hi. I was trying to generate some code to implement a YANG model in
CBOR using:
  https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2

which quite clearly says that I'm to use a CBOR map type (5).  Except that
my understanding of SIDs is that they are deltas for the key part.
(My other problem is that I don't have a SID until the SID document
progresses, but I can use the experimental range for now)

In many languages for which there are easy to use CBOR bindings, ruby,
python, perl, js, java, the CBOR map translates to a hash or directionary.
So I wondered how I could do deltas on keys in such an unordered structure...

My reading of:
  https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2
about type 5, and then I read:
  https://tools.ietf.org/html/rfc7049#section-3.7

which says:
   The CBOR data model for maps does not allow ascribing semantics to
   the order of the key/value pairs in the map representation.

so, it seems that the SID concept as described in ietf-core-yang-cbor can not
work using the map type!!!
At first I thought it was just a language binding issue; that I needed
ordered sets of some kind, but no... It violates the above property.

Solutions that I can imagine:
1) use an array of 2-element arrays (requires an extra byte for each inner
   array!)
2) use an array 2x the size, and let the application reconstruct things as a
   hash after taking in account the SID delta.
3) use one of the discussed point/multi-dimensional-array/etc. structures
   that I believe were presented at IETF99... I think draft-jroatch-cbor-tags
   was the document.

I think that I favour (2), as being the most expedient and easiest to implement.

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Aug 2017 07:48:20 +0200

Hi Michael,

SID deltas in maps are parent-referenced (and not sibling-referenced) for this reason.
Do you see anything that makes you think they are sibling-referenced?
That would indeed not work in maps.

(We discussed using one or more of your solutions for introducing “ordered maps”, but then it seemed parent-referenced was good enough.)

Grüße, Carsten

> On Aug 17, 2017, at 05:03, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Aug 2017 08:54:30 +0200

Carsten,

if I search for 'delta' or 'reference SID', I do not find text that
says what the reference SID is. Where do I have to look at to
understand that delta SIDs are parent-referenced?

/js

PS: Why do we have this, I mean, why is there a $ for some of these?

           pattern 'Module|Submodule|feature|' +
	           'identity$|node$|notification$|rpc$|action$';

    Why is this not an enum in the first place? And why are the
    first two capitalized?

PS: Why do you not import yang-identifier from ietf-yang-types?

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Aug 2017 09:04:07 +0200

> understand that delta SIDs are parent-referenced?

4.2.1 (of yang-cbor) says:

   o  The delta value is equal to the SID of the current schema node
      minus the SID of the parent schema node.  When no parent exists in

But maybe there is indeed potential for editorial improvement here.
Clearly phrasing this always in terms of the reference SID, and then saying where that reference SID comes from (e.g., zero at the root of the tree), might help.
This probably also should be buttressed some more by examples.

>    Why is this not an enum in the first place? And why are the

(Now you are in core-sid, I think.)
Good questions; I’d defer to the YANG specialists here.

> PS: Why do you not import yang-identifier from ietf-yang-types?

Ditto.

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Aug 2017 09:29:03 +0200

Carsten,

I looked into core-sid to understand how sids work, I did not expect
that the definition how delta sids work is in core-cbor...

/js

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Aug 2017 09:33:47 +0200

> On Aug 17, 2017, at 09:29, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Carsten,
> 
> I looked into core-sid to understand how sids work,

That document tells you how to get SIDs.

> I did not expect
> that the definition how delta sids work is in core-cbor…

That document tells you how to encode the SIDs you have into deltas in the CBOR serialization of YANG models.

I think that is a quite reasonable division of work, but maybe again there is potential for explaining this better editorially.

One problem in the past has been that people have been referring to the deltas as SIDs — they aren’t, and we need to root any remnant of that usage out of the documents.

Grüße, Carsten

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Aug 2017 10:41:45 +0200

> That document tells you how to encode the SIDs you have into deltas in the CBOR serialization of YANG models.

Ehem, you referred to core-cbor in order to explain how deltas work,
i.e. what the reference SID actually are that core-sid introduces.
It is not just encoding as far as I can tell.

> One problem in the past has been that people have been referring to the deltas as SIDs — they aren’t, and we need to root any remnant of that usage out of the documents.

I would appreciate if delta SIDs are defined in core-sid and core-cbor
would only talk about how that delta number is encoded but not how
that delta number is determined.

/js

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Aug 2017 10:02:51 -0400

Carsten Bormann <[email-masked]> wrote:
    cb> SID deltas in maps are parent-referenced (and not sibling-referenced)
    cb> for this reason.

Okay.  I don't think I understand the resulting structure then.

    cb> Do you see anything that makes you think they are sibling-referenced?

draft>    When no parent exists in
draft>    the context of use of this container, the delta is set to the SID
draft>    of the current schema node (i.e., a parent with SID equal to zero
draft>    is assumed).

This was the text that made me think the the "parent" was the previous entry
in the dictionary.  If we want to encode:

      20: fruit
      24: bats
      28: snow

that we would do this with:
      20: fruit
      +4: bats
      +4: snow

I re-read the example and it's clearer now, but I was reading the rules.

My appologies for the confusion.