Hi Martin, Thank your for your effort to come up with the concrete example. This certainly illustrates the approach better. I made some inline note to your points
> -----Original Message----- > From: Martin Björklund <[email protected]> > Sent: Mittwoch, 7. Dezember 2022 08:50 > To: [email protected] > Cc: [email protected]; [email protected]; draft-ietf-anima-brski- > [email protected] > Subject: Re: Yangdoctors early review of draft-ietf-anima-brski-prm-05 > > Michael Richardson <[email protected]> wrote: > > > > Thank you very much for the review. > > > > Martin Björklund via Datatracker <[email protected]> wrote: > > > From a YANG perspective, this module is quite simple and looks good. > > The > only > > > thing you should change is to use sx:structure (from RFC 8791) > > instead of > > > rc:yang-data. > > > > yes, but we need to do this across the entire set of documents. > > I don't think this is necessary. > > > We have an RFC8366bis in progress anyway, so the timing is right. > > Ok, if you do 8366bis, then it makes sense to change it to use sx:structure. > (Side > note: if you do this, I would also suggest you look into splitting the > grouping into > several groupings; it seems 8995 wanted to reuse parts of the current > grouping). > > > > > > > However, you wrote in the request for the review "we would want to use > this > > > document as the spearhead for resolving our issue of augmenting > > rfc8366 > YANG". > > > I have read the thread on the netmod mailing list, but I am not sure I > > > understand the problem correctly. In the ML thread, there was the > example of > > > two independent modules that augmented RFC8366: > > > > > module B adds some leafs to RFC8366 > > > module C adds some leafs to RFC8366 > > > > 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. > > > 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. > > Perhaps an example can clarify what what I mean. Here's an example of some > instance data as modelled by RFC 8366: > > { > "ietf-voucher:voucher": { > "created-on": "2016-10-07T19:31:42Z", > "assertion": "logged", > "serial-number": "JADA123456789", > "idevid-issuer": "base64encodedvalue==", > "pinned-domain-cert": "base64encodedvalue==", > "nonce": "base64encodedvalue==" > } > } > > An eample of instance data that matches the RFC 8995 style of defining a *new* > strucure could look like this: > > { > "ietf-voucher-request:voucher": { > "created-on": "2016-10-07T19:31:42Z", > "assertion": "proximity", > "serial-number" : "JADA123456789", > "nonce": "base64encodedvalue==", > "proximity-registrar-cert": "base64encodedvalue==" > } > } > > If instead we wanted to *add* to the exisitng structure in RFC 8366, it could > have looked like this: > > { > "ietf-voucher:voucher": { > "created-on": "2016-10-07T19:31:42Z", > "assertion": "proximity", > "serial-number" : "JADA123456789", > "nonce": "base64encodedvalue==", > "ietf-voucher-request:proximity-registrar-cert": "base64encodedvalue==" > } > } > > (Note that this is hypothetical; it is not possible to do this with the > current RFC > 8366, since it uses rc:yang-data). This is important to know, as the intention with the augmentation was to extend the voucher with additional values as you did in the example above. > > Now, lets assume we have antother module "ietf-B", which is independent of > "ietf-voucher-request", that also wants to add a leaf (say "contact") to the > voucher. An example of instance data could look like this: > > { > "ietf-voucher:voucher": { > "created-on": "2016-10-07T19:31:42Z", > "assertion": "proximity", > "serial-number" : "JADA123456789", > "nonce": "base64encodedvalue==", > "ietf-voucher-request:proximity-registrar-cert": > "base64encodedvalue==", > "ietf-b:contact": "[email protected]" > } > } One question here regarding the voucher-request. In BRSKI-PRM, we have an extension of the voucher-request, which should be used additionally to the definitions in RFC 8995. In the structure above, you added "ietf-voucher-request:proximity-registrar-cert": "base64encodedvalue==" which is defined in RFC 8995. In BRSKI we have enhancements of the voucher-request with further parameters. Lets take "agent-provided-proximity-registrar-cert". As it is defined in a different document, would this lead at the end to a structure like { "ietf-voucher:voucher": { "created-on": "2016-10-07T19:31:42Z", "assertion": "proximity", "serial-number" : "JADA123456789", "nonce": "base64encodedvalue==", "ietf-voucher-request:proximity-registrar-cert": "base64encodedvalue==", "ietf-voucher-request-prm:agent-provided-proximity-registrar-cert": "base64encodedvalue==", "ietf-b:contact": "[email protected]" } } by providing a separate definition in BRSKI-PRM? So the module defined in BRSKI-PRM would be named "ietf-voucher-request-prm". > > > 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? To my understanding it is the latter for now. Thank you. Steffen > > > > > > If this is the > > > intention, the base structure needs to be defined with sx:structure, > > and B > and > > > C would have to use sx:augment-structure to add their leafs. This > approach > > > would e.g. allow an implementation to instantiate a "voucher-artifact" > > > structure with leaves from *both* B and C, even though they are > independent > > > modules. > > > > 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. > > > /martin > > > > > > > > > > > > > > > > > -- > > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
