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

[Xavier De Foy <[e-mail]>]

A new revision -07 has been published, reflecting the proposed changes and including the pull request (thanks again Carsten).
Best Regards,
Xavier

---

Name: draft-irtf-t2trg-iot-edge
Revision: 07
Title: IoT Edge Challenges and Functions
Document date: 2022-06-23
Group: t2trg
Pages: 34
URL: https://www.ietf.org/archive/id/draft-irtf-t2trg-iot-edge-07.txt<https://www.ietf.org/archive/id/draft-irtf-t2trg-iot-edge-07.txt>
Status: https://datatracker.ietf.org/doc/draft-irtf-t2trg-iot-edge/
Html: https://www.ietf.org/archive/id/draft-irtf-t2trg-iot-edge-07.html<https://www.ietf.org/archive/id/draft-irtf-t2trg-iot-edge-07.html>
Htmlized: https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-iot-edge
Diff: https://www.ietf.org/rfcdiff?url2=draft-irtf-t2trg-iot-edge-07<https://www.ietf.org/rfcdiff?url2=draft-irtf-t2trg-iot-edge-07>

Abstract:
Many IoT applications have requirements that cannot be met by the
traditional Cloud (aka cloud computing). These include time
sensitivity, data volume, connectivity cost, operation in the face of
intermittent services, privacy, and security. As a result, the IoT
is driving the Internet toward Edge computing. This document
outlines the requirements of the emerging IoT Edge and its
challenges. It presents a general model, and major components of the
IoT Edge, to provide a common base for future discussions in T2TRG
and other IRTF and IETF groups. This document is a product of the
IRTF Thing-to-Thing Research Group (T2TRG).


From: Xavier De Foy <[e-mail]>
Sent: Friday, June 17, 2022 13:11
To: Carsten Bormann <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [T2TRG] T2TRG last call for draft-irtf-t2trg-iot-edge-06

Thanks Carsten for sharing your comments. We agree with them and provided some responses below, along with proposed changed to the text. Please let us know if your comments are appropriately addressed. Best Regards,Xavier, on behalf of the co-authors > I believe this document  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌

<https://us.report.cybergraph.mimecast.com/alert-details/?dep=MQVNNYSh82cKxcjToi6Ibw%3D%3DXx%2FBkFAraJJORiBcQbCcdY4rZFfjfL%2BhC%2FZ9jAcipCkyezMRN9Hirg8DuwJNbzQibea6SGn5MZnsFoXV8CPDLsPI0k2TQmx1VOYnARDYFXMAUmHB3d%2BsudmOhvxSHtFrQnbKGE4GnmpdcdfGt%2FecLGNPTV8jPJm7h3RAbiEInVrtkPw07x9YBGysXTY3d4LhOFQLkt8yCmaKfoHKdUpSbHjVySVm3YokFZ3VZduij7JkB8aa3cZ8ircedzO6T8xQsn9IX40pc7Q7hNv66wrTdCqk94voAGLhHmRIVtPooJXGvu0fNKlehRr9k20eI6LAZVQoNqFMlpSsQ4Hu0Mzjro5BEXcGmgrRqG6U1AAlA0yGdsS52pkgndzqI4PMIoCM766NNcvJTGCcQUkBKFVSkDmX8DQKk%2FklzzGzW8K3Edm6CYYzFATRPTK3qS7Oedc1%2Bj6QMlXp%2F34fDPfX1GZxO4SWWLXbW6ox5MVN54qMOo2e4aeB379%2FUfACsv8E%2BvyTxLF36NbZH3X4dLfI1MDcWdYD2JEJpKPIhvESQR6vXcO0htCyJ6OWVuSQUyiQ5XOwASipNyeNbRNu5Ir4Gr%2FM0p1r14vuAraLW6UkVAq%2Fggy90sSico1sHVN%2BkiLSJvpIvgfwu46MspzGbEegNx7CnB3UXVstGgVsmEeXb4w2tbuRKlvpB0b00vdCuw%2FzQkeT8sZqos%2BaqfJFZJ0dIQUIJg%3D%3D>
Thanks Carsten for sharing your comments. We agree with them and provided some responses below, along with proposed changed to the text. Please let us know if your comments are appropriately addressed.

Best Regards,
Xavier, on behalf of the co-authors

> 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.

Thanks for bringing this up, we agree with the view that a Thing is not necessarily (or even not mostly) constrained, and so the text you pointed on needs to be changed. This text focused on “contrainedness”. However, another major aspect is the data these Things generate can be voluminous, and to accommodate the data, we must migrate compute and storage closer to the edge. (Please see our proposed updated text below)

About our use of the term "IoT end device" (along with "endpoint" and "end device" for more general designations): actually, "IoT end device" is not used in other documents in IETF/IRTF apparently, so it may be best to change that. We propose to converge towards "IoT devices" (which is used in several RFCs/drafts) and "end devices" when a more general term is needed. We also propose to introduce the “IoT device” term along with the Thing definition updated below.

OLD:
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.

NEW:
A Thing is 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 ([draft-irtf-t2trg-rest-iot]).
In this document we will use the term "IoT device" to designate the embedded system attached to the Thing.

Things are not necessarily constrained.
Resource-constrained Things such as sensors, home appliances and wearable devices
have limited storage and processing power, which raise concerns regarding reliability, performance,
energy consumption, security, and privacy [Lin].
However, more generally Things, constrained or not, tend to generate a voluminous amount of data.
This range of factors led to complementing IoT with cloud computing, at least initially.


> ## Minor
>
> Outside time and frequency distribution, jitter is often a red herring
> and 3.1 should talk about latency upper bounds.

Thank you for pointing this out. RFC 8578 section 7 provide a reference in line with your point and we propose to update the text as:

OLD:
Guarantees for jitter are also important to those
   industrial IoT applications.

NEW:
Guarantees for bounded latency and jitter ([rfc8578] section 7) are also important to those
   industrial IoT applications.

>
> 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".

Thanks, the term "API" was I believe chosen to avoid reusing "service" too much. But as a consequence this makes the description less general. See below for a new text proposal.

Also moved up the paragraph on resilience, which messed up with the flow (adding an unrelated paragraph between the initial description of edge cloud management platforms and the paragraph further detailing some of its aspects.)

OLD:

Life cycle management of services and applications on physical IoT
   gateways is often cloud-based.  Edge cloud management platforms and
   products (such as StarlingX, Akraino Edge Stack, Mobile EdgeX) adapt
   cloud management technologies (e.g., Kubernetes) to the edge cloud,
   i.e., to smaller, distributed computing devices running outside a
   controlled data center.  Services and application life-cycle is
     typically using an NFV-like management and orchestration model.

Resilience in IoT often entails the ability to operate autonomously
   in periods of disconnectedness in order to preserve the integrity and
   safety of the controlled system, possibly in a degraded mode.  IoT
   devices and gateways are often expected to operate in the always-on
   and unattended mode, using fault detection and unassisted recovery
     functions.

The platform typically includes services to advertise or consume APIs
  (e.g., Mp1 interface in ETSI MEC supports service discovery and
   communication), and enables communicating with local and remote
   endpoints (e.g., message routing function in IoT gateways).  The
   service platform is typically extensible by edge applications, since
   they can advertise an API that other edge applications can consume.
   IoT communication services include protocols translation, analytics,
   and transcoding.  Communication between edge computing devices is
     enabled in tiered deployments or distributed deployments.

NEW:

Resilience in IoT [...]

Life cycle management [...]

The platform typically enables advertising or consuming services hosted on the platform
   (e.g., Mp1 interface in ETSI MEC supports service discovery and
   communication), and enables communicating with local and remote
   endpoints (e.g., message routing function in IoT gateways).  The
   platform is typically extensible by edge applications, since
   they can advertise a service that other edge applications can consume.
   IoT communication services include protocols translation, analytics,
   and transcoding.  Communication between edge computing devices is
     enabled in tiered deployments or distributed deployments.

>
> 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].

Thanks, we will change the citation to [I-D.ietf-core-groupcomm-bis]

>
> In Section 5, I'm not sure how compression enters the security
> considerations.

Agreed, compressing is not appropriate in the context of this section. Rephrased as:

OLD:
An edge cloud
   can be used to take actions based on sensitive data, or anonymizing,
   aggregating or compressing data prior to transmitting to a remote
   cloud server.

NEW:
An edge cloud
   can be used to take actions based on sensitive data, or to anonymize or
   aggregate data prior to transmitting to a remote
   cloud server.


>
> ## Nits
>
> I pushed some nits to  https://github.com/t2trg/t2trg-iot-edge-computing/pull/16<https://github.com/t2trg/t2trg-iot-edge-computing/pull/16> as well.

Thank you, they will be integrated in the next revision.

[Banner]

[Banner]<https://www.interdigital.com/white_papers/video-over-5g-new-networks-new-possibilities?utm_source=Email&utm_medium=Signature&utm_term=Video&utm_content=Banner&utm_campaign=Video_Over_5G>

Video Over 5G: New networks, new possibilities<https://www.interdigital.com/white_papers/video-over-5g-new-networks-new-possibilities?utm_source=Email&utm_medium=Signature&utm_term=Video&utm_content=Banner&utm_campaign=Video_Over_5G>
This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.