Two further comments for discussion:
*1) Unclarity, or hierarchy issues, in SID lists?*
In Section 7.4 and 8.3, the SID values list, it looks like we are
listing for each SID some sort of YANG path pointing to the element.
We should clarify here what the intended path type is, e.g. is it a data
node identifier or a schema node identifier?
Formal .sid files require schema node identifier per RFC 9595.
Developers just wanting to create or parse vouchers with their own code
would prefer to see data node identifiers which are much more intuitive.
Because the "choice" elements are absent from the listed paths, I assume
that data node identifier is intended.
In that case, we have the issue that there are extra levels of hierarchy
that shouldn't be there.
For example, in 7.4 I would expect the below for example:
2451 data /ietf-voucher:voucher
2452 data /ietf-voucher:voucher/assertion
2453 data /ietf-voucher:voucher/created-on
<...>
So SID 2450 is the module itself, 2451 is the container 'voucher' in the
module, and 2452 and onwards are the leafs.
This is clear for developers not deep into YANG.
This also matches intuitively very nicely 1:1 to the JSON examples we give.
That is, each listed path is also the XPath expression that gives access
to the specific data node that has the SID allocated.
E.g. if I do XPath /ietf-voucher:voucher/created-on I should get the
"created-on" data from the below example voucher.
{
"ietf-voucher:voucher": {
"created-on": "2016-10-07T19:31:42Z",
"assertion": "logged",
"serial-number": "JADA123456789",
"idevid-issuer": "base64encodedvalue==",
"pinned-domain-cert": "base64encodedvalue==",
"nonce": "base64encodedvalue=="
}
}
*2) Do we need the 'choice' elements in YANG?
*In RFC 8366 we did not define any 'choice' elements in YANG. Just
mandatory and optional elements.
While adding 'choice' can represent some semantics and validity checking
of vouchers, it also adds complexity in the YANG model itself and the
resulting SID allocation.
Using choice elements also leads to larger differences between the data
node identifiers and the schema node identifiers. Which makes things
harder to understand for readers I think.
See item 1) above for example; if we would use schema node identifiers
in the SID list (which I think we don't currently) then we get very long
path strings.
Related discussion in CoRE is here:
https://mailarchive.ietf.org/arch/msg/core/TaJcKNLdkDI_EKtDGeW7hyk_kKs/
Esko
On 24-11-2025 13:07, Esko Dijk wrote:
I've now started to review the version -17. I would say it's not ready
yet to leave the WG.
Here some initial questions:
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.
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?
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?
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.)
Esko
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list [email protected]
To unsubscribe send an email [email protected]
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
