[Anima] Re: removing choice code from RFC8366bis -- Re: Review of draft-ietf-anima-rfc8366bis-17

[Toerless Eckert <[e-mail]>]

Just installed pyang (probably not even newest, and it did create me 
ietf-voucher-tree-latest.txt as follows:

  structure voucher:
    +-- voucher
       +-- created-on?                        yang:date-and-time
       +-- extensions*                        union
       +-- manufacturer-private?              binary
       +-- assertion?                         enumeration
       +-- serial-number                      string
       +-- idevid-issuer?                     binary
       +-- (pinning)?
       |  +--:(pinned-domain-cert)
       |  |  +-- pinned-domain-cert?          binary
       |  +--:(pinned-domain-pubk)
       |  |  +-- pinned-domain-pubk?          binary
       |  +--:(pinned-domain-pubk-sha256)
       |     +-- pinned-domain-pubk-sha256?   binary
       +-- domain-cert-revocation-checks?     boolean
       +-- last-renewal-date?                 yang:date-and-time
       +-- (nonceless)?
       |  +--:(expires-on)
       |  |  +-- expires-on?                  yang:date-and-time
       |  +--:(nonce)
       |     +-- nonce?                       binary
       +-- est-domain?                        ietf:uri
       +-- additional-configuration-url?      ietf:uri

Which i guess looks correct at least to the indentation issue of those
components.

Maybe there is something wrong with the build setup in the directly so
that pyang is not correctly run ?

Cheers
    Toerless

On Tue, Nov 25, 2025 at 11:08:55AM -0500, Michael Richardson 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 <[e-mail]> 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   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 



-- 
---
[e-mail]