Thanks! Ok to take 'choice' out, for me. This makes the attributes more straightforward to understand for readers of various backgrounds. You can now understand it as a "dictionary" of keys/values, some of which are optional. However the new text in -18 that's now trying to explain the issues with 'choice' / 'case' is not representing things correctly. See below: During development of this merged YANG module, advice was given to better organize mutually exclusive attributes such as pinned-domain-cert vs pinned-domain-pubk, or expires-on vs nonce. Unfortunately, [CORESID] does not explain how and why choice statements are assigned SID values, and the tooling as of the end of 2025 is inconsistent with both the document, and the intuitive notions as to how this should work. [CORESID] RFC 9595 in my view does specify clearly enough the any 'choice' and 'case' nodes are not assigned any SID values. See Section 1, "The following items are identified using SIDs", which includes data nodes in the list but not schema nodes (in general). So per RFC 7950 terminology, the 'choice' and 'case' fall outside the scope of SID allocation. Also I haven't seen the tooling (pyang) assign SIDs to 'choice' or 'case' ! And all this is compatible with my intuitive view - choice/case nodes don't need SIDs because these SIDs will be never used even if they would be allocated. Maybe the tooling gets confused by choice/case, however in Andy's mail in the CoRE WG he mentioned that pyang 2.7.1 does an incorrect ordering of items if the flag --sid-update-file is used. So not sure if that's influenced by use of choice/case. Esko
On Tue, Nov 25, 2025 at 17:19, Michael Richardson <[email protected]> wrote: Thank you for looking; it's hard to see some of these things while in the middle. TL;DR> **I propose to take the choice stuff out of the YANG** Esko Dijk <[email protected] (mailto:[email protected])> wrote: In Section 7.1, the last 3 elements fall outside of the structure "voucher". Why is this the case? Can we correct/unify this or is there a reason (in which case we'd need to explain). For me personally, the less unneeded hierarchy the better; but the prime goal should be consistency - i.e. leafs at the same level in the hierarchy - where possible. It took me a bit to understand the issue. I see now. Wow. Oops. The copy on my laptop does not have that problem. I must have fixed something. I'll do -18 with the fix. Or maybe the tree diagram generation was broken due to the sid issues.... YES. We've figured out that this is the result of the introduction of the "choice", which the YANG doctor told us to do. To me, it's become a disaster. **I propose to take the choice stuff out** In Section 8.1, similar question. In Section 8.3, "expires-on" is present twice. This is not the case in 8.1, so it looks like 8.1/8.3 are not in sync? This is the SID problems that we've been fighting. I see other duplicates as well. Sigh. Would it better if the routine that truncates the long SID names just always kept just the last component? We use RFC 6125 as reference, though it's not very important I think. This RFC has been obsoleted. I think we should remove or change this reference. Not sure which reference is good? Yes, RFC6125's DNS-ID got replaced by RFC9525. The problem is that 9525 does not define the CN-ID check, which is part of what we reference. I've split that reference up into two pieces. I'm preparing a few editorial fixes in a single PR. One thing I found is that "Voucher Artifact" and "Voucher" and "Artifact" are all equal by the definitions in the Terminology section. It all refers to the Voucher Data plus the signature applied to it. Is that correct? (If so I'll add a cross-reference in the terms so it's easier for a reader to understand this.) Thank you for the editorial PR. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] (mailto:[email protected]) http://www.sandelman.ca/ (http://www.sandelman.ca/) | ruby on rails [ -- Michael Richardson <[email protected] (mailto:[email protected])> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list -- [email protected] (mailto:[email protected]) To unsubscribe send an email to [email protected] (mailto:[email protected])
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
