Subject: Re: [Yot] questions concerning sid value assignments

From: Michel Veillette <[email-masked]>
Date: Wed, 14 Feb 2018 21:31:40 +0000

About " When two YANG identifiers are different the SIDs should be different, I think."

[I-D.ietf-core-sid] map a SID to a fully qualified path.
The same leaf name or path defined in two different YANG modules will be map to two different SIDs.

For example:
       {
         "namespace": "data",
         "identifier": "/ietf-system:system-state/platform/os-name",
         "sid": 1726
       },

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2018 3:07 AM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]; Panos Kampanakis (pkampana) <[email-masked]>; Michel Veillette <[email-masked]>; Kent Watsen <[email-masked]>
Subject: Re: questions concerning sid value assignments

Hi Michael,

This is a serious issue; Thinking about is, I changed my mind several times.
I have cc'ed Kent, hoping he can provide some assistance.

Actually, there is a one to one relation between SID value and YANG identifier.
The YANG identifier includes the module name and prefix, as specified in the SID I-D (did not check).
When two YANG identifiers are different the SIDs should be different, I think.
Given that voucher and cwt-voucher have different module names, the YANG identifiers are different.
Conclusion, the SIDs should be different For example, the SID of expires-on in the cwt-voucher module is different from the SID of expires-on in the voucher module.

What do you think? It seems to hold more water than the semantics argument.

Peter

Michael Richardson schreef op 2018-02-13 20:50:
> peter van der Stok <[email-masked]> wrote:
>     > There are two ways to go forward:
>     > 1) reuse as much as possible SID values generated for the voucher
>     > identifiers in "used" versions
> 
> Are we talking about the SID value for "expires-on" would be the same 
> between an ietf-cwt-voucher-request and ietf-cwt-voucher, because both 
> are derived from the same ietf-voucher document?
> 
> I want to say that I can live with it either way. I prefer it to be 
> the same, because it makes coding easier, but I can cope.
> 
>     > 2) assume that reusing is OK, but the voucher identifiers can be 
> assigned
>     > different SID values, because their semantics are different.
> 
> So that's the thing, it might be different in other situations, and 
> wouldn't want to screw things up down the road just to save a 
> definition in a
> file.   Maybe different semantics are in fact a "do not" though.
> 
>     > Do you have an idea about that. Possibly you can explain how you 
> think that
>     > the grouping should be used for different voucher versions and 
> if that
>     > applies to the cwt-voucher.
> 
>     > As far as I understand, the semantics of identifiers of the 
> cwt-voucher are
>     > identical to the ones of the original yang voucher specification. 
> In that
>     > case the SID values should be identical as well (seems to me)
> 
> Agreed.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  
> -= IPv6 IoT consulting =-

---

From: peter van der Stok <[email-masked]>
Date: Thu, 15 Feb 2018 09:45:45 +0100

Hi Michel,

I understand.

What I have not completely reasoned through is the use of augment in 
test2 augment with grouping.
The SIDS of most of the voucher/leaves and the cwt-voucher/leaves are 
identical.
I wonder if that can lead to confusion when a server contains both 
cwt-vouchers and vouchers
Does the client need to check on the presence of the leaf 
"pinned-domain-subject-public-key-info" to know the answer?

I need to construct an example with a container containing both vouchers 
and a list of both vouchers.
Will do that next week.

Peter

Michel Veillette schreef op 2018-02-14 22:31:
> Cc: [email-masked]; Panos Kampanakis (pkampana)
> <[email-masked]>; Michel Veillette
> <[email-masked]>; Kent Watsen <[email-masked]>
> Conclusion, the SIDs should be different For example, the SID of
> expires-on in the cwt-voucher module is different from the SID of
> expires-on in the voucher module.
>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 19 Feb 2018 11:08:59 +0100

Hi Michel,

I created an example for myself by heart. Can you see if my memory is 
still correct?

I assume a server with one voucher module and one cwt-voucher module;
The augment with grouping is used for SID allocation.
The diagnostic notation is used for CBOR.

All goes well for the cwt-voucher use as described in the constrained 
voucher document.

A returned voucher may look like (checked with cbor.me)

{
      1001000: {
        +3 : "2016-10-07T19:31:42Z",
        +5 : "2016-10-21T19:31:42Z",
        +2 : "verified",
        +11 : "JADA123456789",
        +6 : "base64encodedvalue==",
        +9 : "base64encodedvalue==",
        +4 : "true",
        +7 : "2017-10-07T19:31:42Z",
      }
    }

A returned cwt-voucher may look like:

{
      1001030: {
        -27 : "2016-10-07T19:31:42Z",
        -25 : "2016-10-21T19:31:42Z",
        -28 : "verified",
        -19 : "JADA123456789",
        -24 : "base64encodedvalue==",
        -21 : "base64encodedvalue==",
        -26 : "true",
        -23 : "2017-10-07T19:31:42Z",
        +1 : "base64encodedvalue=="
      }
    }

Both can be identified nicely though the presence of 1001030 or 1001000

However, when using comi to return the value of for example:
ietf-voucher/created-on, or
iet-cwt-voucher/created-on

The request for both is identical:

GET //example-server.com/c/1001003

The server does not know which one to return.

Did I miss something?

Peter

peter van der Stok schreef op 2018-02-15 09:45:
> I need to construct an example with a container containing both
> vouchers and a list of both vouchers.
> Will do that next week.
> 
> Peter
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Feb 2018 13:23:15 -0500

peter van der Stok <[email-masked]> wrote:
    > I created an example for myself by heart. Can you see if my memory is still
    > correct?

    > The diagnostic notation is used for CBOR.

Cool...

It took me a moment to figure out that 1001000+3 == 1001030-27.
That's exactly what I would think should happen if we have SIDs allocate for
the underlying ietf-voucher object which we then repeat.

There is a concern if the gap between 1001000 and 1001030 was larger!
-27 is fortunately still a 1-byte CBOR integer.  Otherwise, we get into 2
byte CBOR integers and even three byte ones.  Since the delta is relative to
the enclosing value, not the previous value, we can't even amortize the gap.

This is an argument to not re-using the values.

---

From: peter van der Stok <[email-masked]>
Date: Tue, 20 Feb 2018 09:28:53 +0100

Hi Michel,

thanks for the rectifications; will work out the example better for the 
draft.
But it served its purpose.

> Example:
> {
>   1001001: {
>     +2 : "2016-10-07T19:31:42Z",  / SID = 1001003, created-on /
>     +4 : "2016-10-21T19:31:42Z",  / SID = 1001005, expires-on /
>     +1 : "verified",              / SID = 1001002, assertion /
>     +10 : "JADA123456789",        / SID = 1001011, serial-number /
>     +5 : h'0102030405060708090A0B0C0D0F',  / SID = 1001006, 
> idevid-issuer /
>     +8 : h'0102030405060708090A0B0C0D0F',  / SID = 1001009, 
> pinned-domain-cert /
>     +3 : true,                    / SID = 1001004,
> domain-cert-revocation-checks /
>     +6 : "2017-10-07T19:31:42Z"   / SID = 1001007, last-renewal-date /
>   }
> }
> 
> About "when using comi to return the value"
> 
> Currently, these YANG files don't define any data nodes which can be
> instantiated in a datastore.

This is an unexpected turn of events.
in ietf-voucher there is voucher container defined.
but the grouping makes sure that it is only a schema node and not a data 
node.

Nice to know.

> If you want to make the last voucher received accessible though CoMI,
> you will need to add in the AYNG file something like:
> 
> container last_voucher_received {
>    uses voucher-artifact-grouping;
> }
> 
> This definition creates a new set of SIDs for the different fields
> within the voucher.

what I would have expected;

cheerio,

peter

---

From: peter van der Stok <[email-masked]>
Date: Tue, 20 Feb 2018 09:40:29 +0100

> This is an argument to not re-using the values.

Well, that concludes the exercise for me.
Now we can make the examples and fix the cwt-voucher SID allocation

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 Feb 2018 07:36:06 -0500

>> +5 : h'0102030405060708090A0B0C0D0F',  / SID = 1001006, idevid-issuer /

    > but the grouping makes sure that it is only a schema node and not a data

Is there something we can/should change in ietf-voucher so that they do
define data nodes?  We aren't in AUTH48 yet.

---

From: peter van der Stok <[email-masked]>
Date: Tue, 20 Feb 2018 13:50:46 +0100

> define data nodes?  We aren't in AUTH48 yet.

I don't think that is needed.
As far as I remember the GROUPING was added to allow easy updates.
The consequence is that data node which use the voucher must be defined 
to specify storage of the voucher(s) in the server. Values of these 
nodes can be retrieved by RESTCONF, NETCONF of CoMI.

Peter

---

From: Michel Veillette <[email-masked]>
Date: Tue, 20 Feb 2018 15:47:38 +0000

Hi Peter, Hi Michael

In my previous email, I forgot to highlight the errors for the cwt-voucher encoding.

When the augment is on the 'voucher-artifac' template, the 'voucher' container is not redefined, the original definition, path and SID apply.
Only the "pinned-domain-subject-public-key-info" leaf is part of the augment and get specific SID assigned to it.

The encoding should be:
{
  1001001: {                                     
    +2 : "2016-10-07T19:31:42Z",  / SID = 1001003, created-on /
    +4 : "2016-10-21T19:31:42Z",  / SID = 1001005, expires-on /
    +1 : "verified",              / SID = 1001002, assertion /
    +10 : "JADA123456789",        / SID = 1001011, serial-number /
    +5 : h'01020D0F',             / SID = 1001006, idevid-issuer /
    +8 : h'01020D0F',             / SID = 1001009, pinned-domain-cert /
    +3 : true,                    / SID = 1001004, domain-cert-revocation-checks /
    +6 : "2017-10-07T19:31:42Z",  / SID = 1001007, last-renewal-date /
    +30 : h'01020D0F'             / SID = 1001031, pinned-domain-subject-public-key-info /
  }
}

This corrected encoding probably reinforce your current conclusion (This is an argument to not re-using the values.)

Regards,
Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2018 3:40 AM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]; [email-masked]; Michel Veillette <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>; Kent Watsen <[email-masked]>
Subject: Re: questions concerning sid value assignments

Michael Richardson schreef op 2018-02-19 19:23:
> That's exactly what I would think should happen if we have SIDs 
> allocate for the underlying ietf-voucher object which we then repeat.
> 
> -27 is fortunately still a 1-byte CBOR integer.  Otherwise, we get 
> into
> 2
> byte CBOR integers and even three byte ones.  Since the delta is 
> relative to the enclosing value, not the previous value, we can't even 
> amortize the gap.
>

---

From: Michel Veillette <[email-masked]>
Date: Tue, 20 Feb 2018 15:59:15 +0000

Hi Michael

" Is there something we can/should change in ietf-voucher so that they do define data nodes?"

You first need to determine which voucher you want to make available in the datastore.
Last received, last sent, a list of the last x received.
You also need to determine if meta information need to be added (e.g. 'timestamp', 'accepted/rejected').
Once done, you just need to add a container or list based on the grouping already defined.
This new definition(s) should be included in an optional feature.

Regards,
Michel

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2018 7:36 AM
To: [email-masked]
Cc: Michel Veillette <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>; Kent Watsen <[email-masked]>; [email-masked]
Subject: Re: questions concerning sid value assignments

    > but the grouping makes sure that it is only a schema node and not a data

Is there something we can/should change in ietf-voucher so that they do define data nodes?  We aren't in AUTH48 yet.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 Feb 2018 13:19:14 -0500

> In my previous email, I forgot to highlight the errors for the

okay.

    > When the augment is on the 'voucher-artifac' template, the 'voucher'
    > container is not redefined, the original definition, path and SID
    > apply.

What do you mean, "when the agument is on"?

    > Only the "pinned-domain-subject-public-key-info" leaf is part of the
    > augment and get specific SID assigned to it.

    > This corrected encoding probably reinforce your current conclusion
    > (This is an argument to not re-using the values.)

okay, we are pretty much have consensus that values should not be reused.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: peter van der Stok <[email-masked]>
Date: Wed, 21 Feb 2018 09:23:26 +0100

Hi Michel,

Sorry, some problems interpreting your answer

> You first need to determine which voucher you want to make available

What do you mean? a cwt-voucher or a voucher; OR how to derive 
cwt-voucher from voucher; OR
having a mailbox of vouchers?

> Last received, last sent, a list of the last x received.
May be, that is not a voucher problem but application specific??
> 'timestamp', 'accepted/rejected').
That information is in the voucher. (@Michael?)
> grouping already defined.
This I understand if you want to use, NETCOF, RESTCONF or CoMI, but is 
not necessary if we only talk serialization of the voucher.
> This new definition(s) should be included in an optional feature.
Here I am lost again
> Michel

Thanks for your efforts, but probably I don't understand their purpose.

Peter
> Cc: Michel Veillette <[email-masked]>; Panos
> Kampanakis (pkampana) <[email-masked]>; Kent Watsen
> <[email-masked]>; [email-masked]
> Is there something we can/should change in ietf-voucher so that they
> do define data nodes?  We aren't in AUTH48 yet.
> 
> --

---

From: peter van der Stok <[email-masked]>
Date: Wed, 21 Feb 2018 09:29:39 +0100

Hi Michel,

see below

> augment and get specific SID assigned to it.

(RIGHT)
To be sure:
The correct encoding (many thanks for doing this) is only in conjunction 
with YANG CBOR draft.
If you do not expect inter-operability problems with the voucher, an 
alternative encoding with the same resultant values is OK. (for example 
not using the h'number' encoding but just a bsd64 encoding also 
supported by CBOR)

Cheerio,

Peter
> Cc: [email-masked]; [email-masked]; Michel Veillette
> <[email-masked]>; Panos Kampanakis (pkampana)
> <[email-masked]>; Kent Watsen <[email-masked]>

---

From: Michel Veillette <[email-masked]>
Date: Wed, 21 Feb 2018 16:01:49 +0000

==========
About "The correct encoding is only in conjunction with YANG CBOR draft."

Yes, this encoding is based on https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ version 6.

========== In the previous email

About "What do you mean? a cwt-voucher or a voucher; OR how to derive cwt-voucher from voucher; OR having a mailbox of vouchers?"

I mean that the use cases for this information in the datastore need to be clearly defined.

What information need to be retrieved and why.

In the introduction of 'draft-ietf-anima-voucher', we can read:

" The lifetimes of vouchers may vary.  In some bootstrapping protocols

   the vouchers may include a nonce restricting them to a single use,

   whereas in others the vouchers may have an indicated lifetime."

This imply that a device may have multiple vouchers at the same time.

This can be implemented as a list or as multiple containers (e.g. previous-voucher, current-voucher, next-voucher)

About voucher vs. cwt-voucher, I assume that both need to be supported, this can be accomplished by using an anydata.

For example:

module ietf-voucher {

  ...

  anydata  current-voucher {

    description "voucher-artifact or any YANG template based on this artifact."

  }
  ...

}

========== In the previous email

About "should be included in an optional feature"

See https://tools.ietf.org/html/rfc7950#section-7.20.1

This mechanism is used to make a portion of the schema as conditional.

A CoMI client can discover which features are implemented by a server by reading its YANG library (e.g. https://datatracker.ietf.org/doc/draft-veillette-core-yang-library/)

Regards,

Michel

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: Wednesday, February 21, 2018 3:30 AM
To: Michel Veillette <[email-masked]>
Cc: [email-masked]; Michael Richardson <[email-masked]>; [email-masked]; Panos Kampanakis (pkampana) <[email-masked]>; Kent Watsen <[email-masked]>
Subject: Re: questions concerning sid value assignments

Hi Michel,

see below

> augment and get specific SID assigned to it.

(RIGHT)
To be sure:
The correct encoding (many thanks for doing this) is only in conjunction with YANG CBOR draft.
If you do not expect inter-operability problems with the voucher, an alternative encoding with the same resultant values is OK. (for example not using the h'number' encoding but just a bsd64 encoding also supported by CBOR)

Cheerio,

Peter
>> relative to the enclosing value, not the previous value, we can't
>> even amortize the gap.
>>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Feb 2018 17:41:41 -0500

> Sorry, some problems interpreting your answer

I think that some of the concerns are irrelevant to data-at-reset.

    > What do you mean? a cwt-voucher or a voucher; OR how to derive cwt-voucher
    > from voucher; OR

My discussion with Kent on Tuesday suggests that he doesn't think that there
is anything that needs adjusting. I just want to be sure.

    > That information is in the voucher. (@Michael?)

Yeah, that's all in the augment.

    > This I understand if you want to use, NETCOF, RESTCONF or CoMI, but is not
    > necessary if we only talk serialization of the voucher.

Exactly: it's all data at rest at this point.
as in:  https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/