Subject: [core] Using CoMI to change resource attributes

From: Christian Amsüss <[email-masked]>
Date: Wed, 3 Jan 2018 10:43:30 +0100

Hello people in the CoMI area,

in one open issue[1] of the RD-DNS-SD document, we could come to the
point that as .well-known/core is typically a read-only resource,
authorized clients could want to change attributes of some advertised
resources, in particular the title= or ins= attribute values.

How that is done will be out of scope for RD-DNS-SD.

It would, however, be nice if other current WG documents can provide a
means to do that which could be referenced in an non-normative way. My
impression is that the documents around CoMI could be used to do that,
but I have bitter little overview of that area. Can the documents be
pieced together in such a way that a client could do something like

* Find out that a device is CoMI managed,
* find which attribute governs the value of a particular resource's
  "ins=" attribute, and
* assign a new value to that?

and if yes, where do I need to look?

Thanks
Christian

[1]: https://github.com/core-wg/rd-dns-sd/issues/2

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn

---

From: peter van der Stok <[email-masked]>
Date: Wed, 03 Jan 2018 11:13:01 +0100

Hi Christian,

being one of the Comi people it is a pleasure to answer.

> * Find out that a device is CoMI managed,

Yes, simple, standard CoAP discovery with rt=core.c

> * assign a new value to that?

You will need a YANG description file that describes all names 
(attribute-names) that can be managed.

Once the YANG file is written, the code is written that manipulates the 
attribute names in the server, and all things are compiled and loaded 
into the server, changing is easy

PUT [comi-server]/c/ins attribute-value

will probably do it

In general, the names need to be converted to SIDs (identifier numbers) 
and ins is a number.

In practice, I am afraid this is much work for just changing two 
attribute values.

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 3 Jan 2018 12:04:13 +0100

Hi Peter,

thanks for your quick response.

> (attribute-names) that can be managed.

The part I expect to be tricky (and couldn't find in your mail) is that
there can be multiple resources with ins attributes on a device (as
there can be multiple network interfaces). Just to set up an example,
say a device advertises

    </radio>;rt="radio.vhf";ins="TheRadioCompany Radio",
    </alarm>;rt="alarm.cloc";ins="TheRadioCompany Alarm"

Per DNS-SD design, those are independent instances with independent
names. If there is already one instance `TheRadioCompany
Radio._radio._udp` in the domain, the exporter might want to rename the
alarm radio's radio instance to "TheRadioCompany Radio #2" following the
renaming process[1]. For that, it needs to know not only which SID
number "ins" represents (something we'd probably need to mint, given ins
is still being defined), but also where to find which entry in an (array?
container?) list represents the ins of a particular link or resource.

> In general, the names need to be converted to SIDs (identifier numbers) and
> ins is a number.
> 
> In practice, I am afraid this is much work for just changing two attribute
> values.

I don't expect this to be actually implemented in areas that don't
already use CoMI, and the devices that would act as CoMI clients here
would not be very constrained either.

If you think it's a very impractical example, I can just let it go, but
I think it might be a good opportunity to tie the whole CoRE
architecture together.

Best regards
Christian

[1]: https://tools.ietf.org/html/rfc6763#appendix-D

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: peter van der Stok <[email-masked]>
Date: Wed, 03 Jan 2018 12:55:51 +0100

> container?) list represents the ins of a particular link or resource.

YANG is quite powerful. The YANG model can include quite a lot of 
complexity.

A possible approach is to make a list of ins containers.
attributes of the ins container can be
the rt value
the domain name
the resource path
the ins name value

One can make attributes unique or key.
The selection of the ins instance(s) in the array to be changed, is 
based on the key attribute values.

Before starting the exercise of modelling the links, some analysis of 
objectives is needed.
and represents quite an investment.

Cheerio,

peter

---

From: chrysn <[email-masked]>
Date: Wed, 3 Jan 2018 13:11:35 +0100

> and represents quite an investment.

OK, that's a pretty clear "there's nothing that can do it
out-of-the-box" here, so I won't try to construct an example for
RD-DNS-SD.

Thanks for taking the time to elaborate
Christian

---

From: peter van der Stok <[email-masked]>
Date: Wed, 03 Jan 2018 16:33:11 +0100

Hi Christian,

may be senml is an easy way to change ins values?

Peter

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 3 Jan 2018 17:51:40 +0100

Hello Peter,

> may be senml is an easy way to change ins values?

Possibly that, possibly also whichever format would be used to make an
RD entry patchable. (After all, it's either discovering a resource
dedicated to a particular attribute of a link, or modifying the link as
a whole).

I do not even expect many constrained devices to actually implement that
kind of modifiability -- most people seem to be content with appending
#hexbarf to any identifier that needs to be both human readable and
unique. Probably, nly those who try to make their IoT devices and
integration to pass for first class DNS-SD citizens will go the
modifiable path.

At any rate, unless there is actual demand for it, I don't think we
should try to create a solution here. I was just hoping that one already
existed that could be referenced, but otherwise it can be an "out of
scope with no suggestion on how to do it" item.

Best regards
Christian

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 3 Jan 2018 18:49:45 +0100

Hi Christian,

We’ve had a go on modeling RD with CoMI. As you said, there are no difficulties in doing so. The important thing is to get a the right people around the table and see some more use-cases. We discussed it rapidly on our Yang of Things side meeting in Chicago.

The one that you mention seems quite interesting to me. I thing the YoT could also be the right place to talk it over.

Best,
Alexander

> Le 3 janv. 2018 à 17:51, Christian Amsüss <[email-masked]> a écrit :
> 
> Hello Peter,
>

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 4 Jan 2018 10:39:29 +0100

Hi Alexander,

On Wed, Jan 03, 2018 at 06:49:45PM +0100, Alexander Pelov wrote:
> We’ve had a go on modeling RD with CoMI. As you said, there are no
> difficulties in doing so. The important thing is to get a the right
> people around the table and see some more use-cases. We discussed it
> rapidly on our Yang of Things side meeting in Chicago.

are there any minutes of that? On the YoT list and the repo[1], I only
found Prague's.

The information model of the RD is intentionally close to that of typed
links (link headers / link-format). So far I've only encountered some
weak use cases for managing existing link-format resources (usually for
naming things, like the ins= example for DNS-SD or providing a title)
that would need to operate on the origin resource or its .w-k/c.
What were the discussed uses cases for describing the full RD?

> The one that you mention seems quite interesting to me. I thing the
> YoT could also be the right place to talk it over.

CC'd.

Best regards
Christian

[1]: https://github.com/Ixau/yot