"Fries, Steffen" <[email protected]> wrote:
> 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.
Ok. Just to be clear; this is not what is defined today. In order to
get this, 8366bis would have to use sx:structure, and then an 8995bis
would have to use sx:augment-structure.
> > 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".
Yes, if BRSKI-PRM (and "ietf-b" and "ietf-voucher-reques") used
sx:augemnt-structure.
> > 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
/martin
>
> >
> > >
> > > > 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
