Re: [Yot] questions concerning sid value assignments

[peter van der Stok <[e-mail]>]

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:
> 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:
>> 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:[e-mail]]
>> Sent: Wednesday, February 14, 2018 3:07 AM
>> To: Michael Richardson <[e-mail]>
>> Cc: [e-mail]; Panos Kampanakis (pkampana)
>> <[e-mail]>; Michel Veillette
>> <[e-mail]>; Kent Watsen <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
>>> -= IPv6 IoT consulting =-