During the hackathon we might take a closer look into the YANG and
8366bis details?
For me the "make" didn't work immediately due to a missing semicolon -
created https://github.com/anima-wg/voucher/pull/87 for this.
Also my (latest) pyang 2.7.1 doesn't support the "--generate-sid-file"
option, but it needs to be "--sid-generate-file".
Doing custom PRs/patches for pyang is also an option at the hackathon.
But in this case the build process would only work for those people
who've installed these patches.
When I try SID generation on my machine, the file and the paths look
really different: for example the "choice nonceless" and "choice
pinning" elements also gets a name assigned in the overall
path/identifier. And a SID value also.
Overall it looks completely different from our draft - maybe I've used
the wrong parameters?
pyang --verbose --sid-generate-file 2450:50 ietf-voucher-test.yang
This doesn't preserve the previously defined SID values in our draft,
however.
One way to possibly get rid of some issues would be removing all
"choice" elements from the YANG. This avoids SID values being allocated
for the choice elements themselves.
(To be continued...)
Esko
On the PYANG tool related issues:
On 21-10-2025 00:26, Michael Richardson wrote:
Esko Dijk<[email protected]> wrote:
> I've reviewed draft-ietf-anima-rfc8366bis-14 as part of the WGLC; with
> issues/questions listed below and some editorial updates proposed in a
PR.
> (See:https://github.com/anima-wg/voucher/pull/85)
Thank you.
I've been fighting PYANG things for a few hours (DAYS?!), and I've run out of
time now. So I'm posting -16 with updates that I have. More details later.
> *** Section 7.4
> Some items have 2 SIDs assigned: additional-configuration-url,
est-domain,
> expires-on.
Yes, this is the thing I'm fighting.
> *** Section 7.5
> "In JSON serialization, these extensions require a unique name, and this
MUST
> be allocated by IANA. The name MUST be the same as the YANG module name.
"
-> this is unclear to me. If every extension has the same name, it's not
> unique and not useful.
> *** Section 8.1
> Again like in 7.1, why are some items/leaves outside of the "voucher"
> element?
Yes. ARGH.
> In the YANG, the name of RFC XXXX differs from the actual name - same
thing
> as in 7.3.
The RPC will s/XXXX/1234/ when they assign the number.
I got as far as:
> The boilerplate BCP text is included twice in the same field:
Sorry.
--
Michael Richardson<[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
