Subject: [Iot-onboarding] RFC 8366: voucher artifact error in example?

From: "M. Ranganathan" <[email-masked]>
Date: Sun, 9 Feb 2020 22:27:49 -0500

Hello,

I am wondering if the format of the example should be
{
  "ietf-voucher:voucher-artifact": {
    "voucher": {
      "created-on": "2016-10-07T19:31:42Z"
      ......
instead of

{ "ietf-voucher:voucher":
    { "created-on": "2016-10-07T19:31:42Z",
      "assertion": "logged",

Based on the yang hierarchy (tree diagram).

I am going by what ygot is producing. I had to change the yang-data to
a container for ygot to work - perhaps this is the reason why the
output is different?  Not sure if this is quite right but I thought
I'd just point it out.

Ranga

--
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Feb 2020 19:05:10 +0100

> Based on the yang hierarchy (tree diagram).

No, the tree diagam is wrong.
I'm not sure what to do exactly.

    > output is different?  Not sure if this is quite right but I thought

It seems that there should be an errata.

Kent, is there a way we can change the YANG to match things correctly?
It seems that we might change:

   // Top-level statement
   rc:yang-data voucher-artifact {
     uses voucher-artifact-grouping;
   }

to:
   rc:yang-data voucher {

===
Or, do you think that we should changing the BRSKI document to match?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kent Watsen <[email-masked]>
Date: Tue, 11 Feb 2020 00:25:20 +0000

> I'm not sure what to do exactly.

The tree diagram and examples in RFC 8366 are all correct.  The examples were validated via this script: https://github.com/anima-wg/voucher/blob/master/refs/validate-all.sh <https://github.com/anima-wg/voucher/blob/master/refs/validate-all.sh>.

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:

	rc:yang-data foo {
	  leaf bar {
	    type string;
	  }
	}

A valid “foo” instance document (in JSON) would be:

	{
	    “bar”: “this is a string.”
	}

Kent

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Feb 2020 12:25:19 +0100

Kent Watsen <[email-masked]> wrote:
    > 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)

---

From: Kent Watsen <[email-masked]>
Date: Tue, 11 Feb 2020 15:18:12 +0000

> On Feb 11, 2020, at 6:25 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

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.

AFAICT, the examples in Section 3.3 in keyinfra-35 are also correct.

K.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Feb 2020 22:01:53 +0100

> 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": {

    > 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"?

---

From: Kent Watsen <[email-masked]>
Date: Wed, 12 Feb 2020 00:00:59 +0000

>    ranga> "ietf-voucher:voucher-artifact": {

Ranga’s question was if this should be the case.  The answer is “no” and no errata is needed.

>     "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. [email-masked] <mailto:[email-masked]>).

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