[core] Using CoMI to change resource attributes

[Christian Amsüss]

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

[peter van der Stok]

Hi Christian,

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

Post by Christian Amsüss
* Find out that a device is CoMI managed,

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

Post by Christian Amsüss
* find which attribute governs the value of a particular resource's
"ins=" attribute, and
* 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.

Post by Christian Amsüss
and if yes, where do I need to look?
Thanks
Christian
[1]: https://github.com/core-wg/rd-dns-sd/issues/2
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Christian Amsüss]

Hi Peter,

thanks for your quick response.

Post by peter van der Stok

Post by Christian Amsüss
* find which attribute governs the value of a particular resource's
"ins=" attribute, and
* assign a new value to that?

You will need a YANG description file that describes all names
(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.

Post by peter van der Stok
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

[peter van der Stok]

Post by Christian Amsüss

Post by peter van der Stok
You will need a YANG description file that describes all names
(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.

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

[chrysn]

Post by peter van der Stok
Before starting the exercise of modelling the links, some analysis of
objectives is needed.
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

[peter van der Stok]

Hi Christian,

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

Peter

Post by chrysn

Post by peter van der Stok
Before starting the exercise of modelling the links, some analysis of
objectives is needed.
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

[Christian Amsüss]

Hello Peter,

Post by peter van der Stok
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

[Alexander Pelov]

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

Post by Christian Amsüss
Hello Peter,

Post by peter van der Stok
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
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Christian Amsüss]

Hi Alexander,

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