>>>> The confusion is likely because folks expect that the “yang-data”
>>>> extension define a node, but it doesn’t. It acts more like a YANG
>>>> “grouping” than a YANG “container” in that regard. For instance, give
>>>> the YANG:
>>>
>>> Okay, so are you saying that it has to be a voucher-artifact, not a voucher,
>>> and the examples in BRSKI are wrong?
>>> (That's really annoying)
>
>> I’m unsure what you mean by “it” but, again, the examples in RFC 8366 are
>> correct.
>> Note that “voucher-artifact” does NOT appear in the examples.
>
> By, "it", I meant the marker in the JSON:
>
> ranga> {
> ranga> "ietf-voucher:voucher-artifact": {
Ranga’s question was if this should be the case. The answer is “no” and no
errata is needed.
>> AFAICT, the examples in Section 3.3 in keyinfra-35 are also correct.
>
> okay, I was worried it didn't work out. (Whew!!!)
> What is it in the YANG that means the serialized JSON is
> "ietf-voucher:voucher" rather than "ietf-voucher:voucher-artifact”?
The "ietf-voucher:” prefix appears because “ietf-voucher" is the name of the
module (i.e. ietf-vouc...@2018-05-09.yang
<mailto:ietf-vouc...@2018-05-09.yang>).
The “name” parameter of the “rc:yang-data” statement has no effect on the
serialized encoding. Yes, the name is “voucher-artifact”, but that string
never appears in instance documents.
What does matter is that the rc:yang-data’s immediate descendent is a
‘container’ node called “voucher”. This string *does* appear in the serialized
form.
Hence it is "ietf-voucher:voucher" rather than "ietf-voucher:voucher-artifact”.
Kent
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
