Re: [T2TRG] T2TRG last call for draft-irtf-t2trg-iot-edge-06

I have not read this draft in some time so will try to make time to review
it.

Carsten, your comments remind me of a question I've been considering
since the Digital Twin meeting: just what is the difference between a mirror
and a digital twin? Is it that the latter has not just state, but also
exposes
a digital affordance (i.e. its state can be modified over the network)?

Also, can you describe an example of a service that does not expose an
API? I'm thinking that either my definition of service or API doesn't line
up with yours and I'm trying to determine which.

Cheers, Kerry

On Mon, Jun 13, 2022 at 12:19 PM Carsten Bormann <cabo@tzi.org> wrote:

> On 2022-05-30, at 21:38, Ari Keränen <ari.keranen=
> 40ericsson.com@dmarc.ietf.org> wrote:
> >
> > This is the RG last call for the draft "IoT Edge Challenges and
> Functions":
> > https://datatracker.ietf.org/doc/draft-irtf-t2trg-iot-edge/
>
> (No hat:)
>
> I believe this document is almost ready to be published as a consensus
> document of the T2TRG.
>
> I already reviewed an earlier version of this document with a chair hat
> on, but I have one question that came up while looking at the current
> version, and a few more observations.
>
> Grüße, Carsten
>
>
> ## Major
>
> Of all things [sic], I have a question on your definition of Thing.
>
> You seem to be defining "Thing" as follows:
>
>    Things are usually embedded systems of various kinds, such as home
>    appliances, mobile equipment, wearable devices, etc.  Things are
>    widely distributed, but typically have limited storage and processing
>    power, which raise concerns regarding reliability, performance,
>    energy consumption, security, and privacy [Lin].  This limited
>    storage and processing power leads to complementing IoT with cloud
>    computing.
>
> Please contrast this with (draft-ietf-asdf-sdf-11.txt):
>
>    Thing:  A physical item that is also made available in the Internet
>       of Things.  The term is used here for Things that are notable for
>       their interaction with the physical world beyond interaction with
>       humans; a temperature sensor or a light might be a Thing, but a
>       router that employs both temperature sensors and indicator lights
>       might exhibit less Thingness, as the effects of its functioning
>       are mostly on the digital side.
>
> Or (draft-irtf-t2trg-rest-iot-09.txt):
>
>    Thing:  A physical item that is made available in the Internet of
>       Things, thereby enabling digital interaction with the physical
>       world for humans, services, and/or other Things.
>
> The two latter definitions do not address constrainedness, so there is
> a reason why these are different.  But two things stand out:
>
> * You define Thing to be just the embedded system attached to a
>   physical item, while the other two define the whole item to be the
>   Thing.
> * You seem to always associate constrainedness with Thingness; which
>   makes one wonder whether your considerations apply to powerful
>   Things, too.
>
> You then also use terms such as end-device, endpoint.
>
> ## Minor
>
> Outside time and frequency distribution, jitter is often a red herring
> and 3.1 should talk about latency upper bounds.
>
> I'm not sure I like service discovery being equated with "advertising
> and consuming APIs" (4.1) -- not all services are described by an
> "API".
>
> In 4.3.2, I'm not sure whether you really want to cite
> [I-D.ietf-core-oscore-groupcomm] or maybe
> [I-D.ietf-core-groupcomm-bis].
>
> In Section 5, I'm not sure how compression enters the security
> considerations.
>
> ## Nits
>
> I pushed some nits to
> https://github.com/t2trg/t2trg-iot-edge-computing/pull/16 as well.
>
>
>
> _______________________________________________
> T2TRG mailing list
> T2TRG@irtf.org
> https://www.irtf.org/mailman/listinfo/t2trg
>