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

[Michael Richardson]

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 <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-

[Carsten Bormann]

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

Post by Michael Richardson
Hi. I was trying to generate some code to implement a YANG model in
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...
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2
https://tools.ietf.org/html/rfc7049#section-3.7
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.
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.
--
-= IPv6 IoT consulting =-
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Juergen Schoenwaelder]

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?

Post by Carsten Bormann
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

Post by Michael Richardson
Hi. I was trying to generate some code to implement a YANG model in
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...
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05#section-4.2
https://tools.ietf.org/html/rfc7049#section-3.7
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.
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.
--
-= IPv6 IoT consulting =-
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Carsten Bormann]

Post by Juergen Schoenwaelder
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?

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.

Post by Juergen Schoenwaelder
/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?

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

Post by Juergen Schoenwaelder
PS: Why do you not import yang-identifier from ietf-yang-types?

Ditto.

Grüße, Carsten

[Juergen Schoenwaelder]

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

Post by Carsten Bormann

Post by Juergen Schoenwaelder
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?

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.

Post by Juergen Schoenwaelder
/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?

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

Post by Juergen Schoenwaelder
PS: Why do you not import yang-identifier from ietf-yang-types?

Ditto.
Grüße, Carsten

[Carsten Bormann]

Post by Juergen Schoenwaelder
Carsten,
I looked into core-sid to understand how sids work,

That document tells you how to get SIDs.

Post by Juergen Schoenwaelder
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

Post by Juergen Schoenwaelder
/js

Post by Carsten Bormann

Post by Juergen Schoenwaelder
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?

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.

Post by Juergen Schoenwaelder
/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?

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

Post by Juergen Schoenwaelder
PS: Why do you not import yang-identifier from ietf-yang-types?

Ditto.
Grüße, Carsten

--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: [phone] Campus Ring 1 | 28759 Bremen | Germany
Fax: [phone] <http://www.jacobs-university.de/>
_______________________________________________
CBOR mailing list
https://www.ietf.org/mailman/listinfo/cbor

[Juergen Schoenwaelder]

Post by Carsten Bormann

Post by Juergen Schoenwaelder
Carsten,
I looked into core-sid to understand how sids work,

That document tells you how to get SIDs.

Post by Juergen Schoenwaelder
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.

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.

Post by Carsten Bormann
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.

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

[Michael Richardson]

Carsten Bormann <***@tzi.org> 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.

--
Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-