[yang-tooling] Re: SID file issues / .sid file differences in pyang and core-wg/pyang

[Laurent Toutain <[e-mail]>]

Hi,

I was away from my mail for a few days, and I missed a lot of interesting
discussions.

I would like to present my vision of what I’m expecting from CORECONF, to
see if it is in line with the usage we plan to do, for instance in SCHC to
exchange compression rules.

We are dealing with very limited devices which don’t have the capacity of
directly manipulating a YANG file, and our goal is also to limit the
traffic because we may also be very constrained in bandwidth, for instance,
we are investigating some underwater communications with few kilobits/s.

What I like with YANG and CORECONF, is that the strict formalism both from
YANG and CBOR leads to a small code footprint to manipulate any CORECONF
representation. The size of exchange messages also makes this
representation competitive with other protocols. In this paper (
https://ieeexplore.ieee.org/abstract/document/11073610) we compare
CORECONF and EDHOC in a SDN scenario and the results are quite close.

So, one of my concerns is to have something small and flexible to represent
data coming from a constrained device. The alphabetical order used by pyang
may not provide the best result. For instance, in the SCHC YANG module, the
rule-id-value leaf is more than 23 SID away from the start, we spend 2
bytes instead of one due to the CBOR coding of integers.

May be thuis scheme can merge the actual CORECONF representation and the
need to introduce choice:

With the SID for the example box model, we have:

SID        Assigned to
---------  --------------------------------------------------
100       module example-box
101       data /example-box:box
102       data /example-box:box/a
103       data /example-box:box/b

To represent the 2 vlaues, the CBOR structure wille be {101: {1: A, 2: B}}

If you introduce the choice hierarchy:
SID        Assigned to
---------  --------------------------------------------------
100        module example-box
101        data /example-box:box
102        data /example-box:box/a_choice
103        data /example-box:box/a_choice/case_a
104        data /example-box:box/a_choice/case_a/a
105        data /example-box:box/a_choice/case_b
106        data /example-box:box/a_choice/case_b/b

The CBOR structure is {101: {1: {1: {1: A}, 3:{1:B}}}}


The strict hierarchy coding introduces 6 extra bytes. But in fact we don’t
care that much, because what is important is the absolute SID value, not
the delta encoding introduced for compactness. A structure like {101: {2:
A, 5:B}} will carry the same information, the main difference is that the
deltas are increasing faster so their CBOR representation may be larger too.

We can imagine a SID allocation like that:
SID        Assigned to
---------  --------------------------------------------------
100        module example-box
101        data /example-box:box
104        data /example-box:box/a_choice
103        data /example-box:box/a_choice/case_a
102        data /example-box:box/a_choice/case_a/a
105        data /example-box:box/a_choice/case_b
103        data /example-box:box/a_choice/case_b/b

We can still have a compact representation {101:{1: A, 2: B}} and the
introduction of the choice hierarchy, preserving the compact coding of the
information and allowing choice to be taken into consideration. A compact
node will use the 100-103 SID and the other are used to allow full
compatibility with the YANG module. This make the numbering a bit more
complex.

My 2 cents

Laurent




On Thu, Feb 5, 2026 at 5:13 PM Andy Bierman <[e-mail]> wrote:

>
>
> On Thu, Feb 5, 2026 at 8:07 AM Carsten Bormann <[e-mail]> wrote:
>
>> On Feb 5, 2026, at 16:59, Andy Bierman <[e-mail]> wrote:
>> ...
>> > If the sender uses id-sid and sends a name, is the receiver supposed to
>> reject the message as not valid?
>>
>> We don’t require that.
>> An implementation that is SIDs only (which will be typical for servers in
>> the constrained space) will simply not be able to process a name.
>> Whether any other implementation (one that has the names) should react
>> negatively to a name in a representation declared as id=sid is up to its
>> stance on RFC9413…
>> (I’d log a diagnostic.)
>>
>>
> OK. Makes sense.  In NETCONF, any unparseable message causes the session
> to be dropped.
>
>
>> Grüße, Carsten
>>
>>
> Andy
>
> _______________________________________________
> yang-tooling mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>