Martin Björklund <mbj+i...@4668.se> wrote:
>> And then Module D wishes to inherit from B and C :-)
> "inherit from" is quite generic; I would need to see a detailed
> example of the definitions you envision in B, C and D to give
> guidelines.
Yes, you are right.
>> In practical terms, this would be a constrained version of PRM.
>> (combining draft-ietf-anima-constrained-voucher +
draft-ietf-anima-brski-prm)
>>
>> > But if the intention is to add leafs to the *existing* structure
defined in RFC
>> > 8366 ("voucher-artifact"), then this approach doesn't work.
>>
>> We do this today in RFC8995 with augment.
> No, 8995 defines a *new* structure; it doens't add to the existing
> one.
Yes, I recognized this in the shower the other day.
We used augment to create a new structure, (with a new set of SID values,
btw), the voucher-request.
But, in PRM ("B") we want to extend the existing structures with new items, but
use
the same SID values.
Ditton in Constrained-Voucher ("C").
When we get around to doing Constrained PRM ("D"), then we would like the items
from "B" and from "C".
> (Note that this is hypothetical; it is not possible to do this with
> the current RFC 8366, since it uses rc:yang-data).
Understood.
> So it all depends on what you want to do with the instance documents -
> are they supposed to be "locked down" by explicit strcutures in
> different RFCs, or do the RFCs define pieces of structures that can be
> combined by implementations?
Not so much by implementations, but by derived RFCs.
>> We want to go this way, but we want to be sure we are really doing it
wrong.
>> Do you have an opinion about whether there is just a bug in pyang's
SID.py?
>> Or is there something else missing in the YANG?
> Yes this is missing in pyang. I have asked the authors of the sid
> plugin to have a look at this.
I have also filed and fixed bugs in sid.py, but before I do that, I just want to
make sure that the YANG is sane, otherwise, I might be doing the wrong thing.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
