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).
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]"
}
}
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?
>
> > 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
