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

[Andy Bierman <[e-mail]>]

On Thu, Feb 5, 2026 at 8:50 AM Laurent Toutain <
[e-mail]> wrote:

> 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 SID path identifies the node in the schema tree.
When data is sent, the choice and case nodes are not in the hierarchy.

I think the encoding would be:

{101: {3: A, 5: 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
>
>
Andy


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