Re: [yang-doctors] [Anima] Yangdoctors early review of draft-ietf-anima-brski-async-enroll-03

[Reshad Rahman <[e-mail]>]

 On Thursday, August 19, 2021, 04:43:33 PM EDT, Michael Richardson <[e-mail]> wrote:
 
 
 On 2021-08-15 11:22 a.m., Reshad Rahman via Datatracker wrote:
> It was correctly pointed out that the enumeration for "leaf assertion" in
> RFC8366 can not be augmented. If my understanding is correct, there is a
> suggestion to do a IANA-maintained module for the assertion and republish a new
> YANG module revision when a new assertion is added. However, I don't believe
> the "assertion values" are actually IANA-maintained. 

The RFC8366bis would create the IANA Registry.

<RR> If you want a central location for these values, then doing IANA maintained values is the way to go. But I am not familiar with the details of the process, so I don't know of the extra cost, if any, of doing it that way. e..g I assume when a new value is needed in the future, we'll need a bis of 8366bis on top of the new document which uses that value?Adding Rob to shed some light on this.
 >So I don't think that
> doing a IANA-maintained module is good in this case (disclaimer: I won't
> pretend to be an expert on IANA-maintained modules). As comparision point, the
> IANA BFD module at
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-17#section-2.12 is
> for BFD registries maintained by IANA
> (https://datatracker.ietf.org/doc/html/rfc5880#section-8).

Thank you, I did need another example.

> Since 8366bis is being worked on, can the enum be changed to an identity? That
> way, when a new assertion is needed, a new identity is added. Identities would
> also enable to support "multiple inheritance" as was asked here:
> https://mailarchive.ietf.org/arch/msg/netmod/dNGvcvckwuS_pBmkVg_Te8bedZs/. For
> an example, see https://datatracker.ietf.org/doc/html/rfc7950#section-7.18.3

I don't know if I can use an identity.
<RR> I believe you can use an identity. But if you want a central location for all 'values', identity is not the way to go. If you're ok with having the uses distributed in various documents, identity will work.RFC6020 section 6.2, I think?<RR> No that's identifiers. 
I'm not sure that I understand the 7950 example.<RR> Does this help: https://datatracker.ietf.org/doc/html/rfc7950#section-7.18As opposed to having enum E with e.g. values E1 and E2, you have an identity I (no "base") and then new identities I1 and I2 with I as base. For example:  identity path-type {
    description
      "Base identity for BFD path type. The path type indicates
       the type of path on which BFD is running.";
  }
  identity path-ip-sh {
    base path-type;
    description "BFD on IP single hop.";
    reference
      "RFC 5881: Bidirectional Forwarding Detection (BFD)
       for IPv4 and IPv6 (Single Hop).";
  }
  identity path-ip-mh {
    base path-type;
    description "BFD on IP multihop paths.";
    reference
      "RFC 5883: Bidirectional Forwarding Detection (BFD) for
       Multihop Paths.";
  }

> Other comments:
> - rc:yang-data (RFC8040) is used. While this seems to be fine, if the
> voucher-request-async-artifact template needs to be extended in the future, my
> understanding is that it is not possible with yang-data. However, you could use

Uhm, but we use rc:yang-data in RFC8366, and we extend it in RFC8995 to 
make voucher-request.  And we take that, and we extend it in 
anima-constrained-voucher.

So I'm confused.
Is that we are doing this a bug?<RR> No. When 8366 was written, afaik the work on structure had just started. So it made sense that you used yang-data.

> "structure" and (eventually) "augment-structure" from RFC8791 for this. -

I have read 8791 now.
It seems fine.  I don't see why we would or wouldn't do RFC8366bis as a 
structure.  I would appreciate a deeper understanding of what it does 
better.<RR> structure allows for extensions and doesn't need to be at top-level (which is the case for yang-data). Maybe you don't need those 2 enhancements.

BTW: we plan to rename all of our extensions (still in ID stage) to be 
ietf-voucher-foo, rather than ietf-foo-voucher, and I wondered if there 
was any reason why this was a bad idea.  It seems like a good idea from 
a collection/sorting point of view for the humans involved.<RR> Sounds good.