Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t2trg-iot-edge-10> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Please note that the title of the document has been
     updated as follows. Abbreviations have been expanded per Section
     3.6 of RFC 7322 ("RFC Style Guide"). Please review.

Original:
IoT Edge Challenges and Functions

Current:
Internet of Things (IoT) Edge Challenges and Functions
-->


2) <!--[rfced] Dirk and Matthias: Is there a "short name" we could use
     for your organizations in the header?-->


3) <!-- [rfced] Please insert any keywords (beyond those that appear in
     the title) for use on https://www.rfc-editor.org/search. -->


4) <!--[rfced] To help with longevity, we have updated uses of
     "currently", "today" and the like to say "at the time of
     writing". Please let us know any objections.-->


5) <!--[rfced] Is the meaning of this sentence that IoT technology is
     being applied in more types of domains?  Or that the applications
     listed are more demanding than other domains?  (That is, is the
     healthcare domain itself more demanding or is there some
     application inside the healthcare domain that is more demanding?)

Original:
  IoT technology is used with increasingly demanding applications, for
   example, in industrial, automotive and healthcare domains, leading
   to new challenges.
   
Perhpas A:   
   IoT technology is used with increasingly demanding applications in
   domains such as industrial, automotive, and healthcare, which leads
   to new challenges.

Perhaps B:
   IoT technology is used with increasingly demanding applications, for
   example, the industrial, automotive, and healthcare domains, leading
   to new challenges.
-->


6) <!--[rfced] Should "device" be updated to "devise" or is there another
     way to rephrase this sentence?

Original:
   Conversely, a cloud back-end might want to device data
   even if it is currently asleep.

Perhaps:
   Conversely, a cloud backend might want to access device data
   even if the device is currently asleep.
-->


7) <!--[rfced] The following three sentences use "typically".  We will
     update to use another word to reduce redundancy unless we hear
     objection.

Original:
The service and application life-cycle is
   typically using an NFV-like management and orchestration model.

   The platform typically enables advertising or consuming services
   hosted on the platform (e.g., the Mp1 interface in ETSI MEC supports
   service discovery and communication), and enables communication with
   local and remote endpoints (e.g., message routing function in IoT
   gateways).  The platform is typically extensible to edge applications
   because it can advertise a service that other edge applications can
   consume. 

Perhaps:
Typically, the service and application life cycle is
   using an NFV-like management and orchestration model.

   The platform generally enables advertising or consuming services
   hosted on the platform (e.g., the Mp1 interface in ETSI MEC supports
   service discovery and communication), and enables communication with
   local and remote endpoints (e.g., message routing function in IoT
   gateways).  The platform is usually extensible to edge applications
   because it can advertise a service that other edge applications can
   consume. 
-->


8) <!--[rfced] Please review the following questions related to this text:

a) We are having trouble parsing "the list associated logical
functions". Is "list" intended to be a noun or a verb?

b) The placement of "in this section" is somewhat jarring (and makes
two introductory phrases in the sentence).  May we update as follows?

Original:
   Although there are many approaches to
   edge computing, in this section, we attempt to lay out a general
   model and the list associated logical functions.

Perhaps A (list is a noun):
   Although there are many approaches to
   edge computing, this section lays out an attempt at a general
   model and the list of associated logical functions.

Perhaps B (list is a verb):
   Although there are many approaches to
   edge computing, this sections lays out an attempt at a general
   model and lists associated logical functions.
-->   


9) <!--[rfced] The SVG figures in Section 4.2 have their width and height
     specified, which will make the artwork not scale. Please consider
     whether scaling should be enabled. Scaling will allow the figure
     to be resized when it is viewed on a mobile device; however,
     there may be aesthetic trade-offs (e.g., image may appear too
     large on a desktop screen or different figures may scale
     differently based on their relative sizes).  Please review the
     HTML and PDF outputs and let us know how to proceed.
-->


10) <!--[rfced] In the following text, how does the last clause relate to
     the rest of the sentence?  If our suggested rephrase does not
     correctly capture your intent, please let us know how to
     rephrase.

Original:
   In a distributed image processing application, some image processing
   functions can be similarly executed at the edge or in the cloud,
   while preprocessing, which helps limiting the amount of uploaded data,
   is performed by the IoT device.

Perhaps:
   Similarly, in a distributed image processing application, some
   image processing functions can be executed at the edge or
   in the cloud, which helps with limiting the amount
   of uploaded data to be performed by the IoT device.

-->


11) <!--[rfced] Should "IRTF attendees" be further clarified?  Is this a
     particular meeting?  Participants of all Research Groups?-->


12) <!--[rfced] To avoid the awkward readability of both "used" and
     "using" in the same sentence, may we make the following update?

Original:

   Broker-based solutions can be used, for example, using an IoT
   gateway as a broker to discover IoT resources.

Perhaps:

   Broker-based solutions can be implemented; an example would be using an
   IoT gateway as a broker to discover IoT resources.
-->   


13) <!--[rfced] Please review our update to "in replacement or complement"
     and let us know if it does not capture your intended meaning.

Original:
   More decentralized solutions can also be used in replacement or
   complement, for example, CoAP enables multicast discovery of an IoT
   device, and CoAP service discovery enables obtaining a list of
   resources made available by this device [RFC7252].

Current:
   More decentralized solutions can also be used in replacement of or
   in complement to the broker-based solutions; for example, CoAP
   enables multicast discovery of an IoT device and CoAP service
   discovery enables one to obtain a list of resources made
   available by this device [RFC7252].
-->


14) <!--[rfced] Please review our update to the following text to ensure
     we've correctly captured your intended meaning.  Because this
     text includes an example within an example and both are within a
     list, please review carefully.

Original:

   * Adapting cloud management platforms to the edge, to account
   for its distributed nature, e.g., using Conflict-free Replicated
   Data Types (CRDT) [Jeffery], heterogeneity
   and customization, e.g., using intent-based management mechanisms
   [Cao], and limited resources.

Current:

   * Adapting cloud management platforms to the edge to account for
   its distributed nature, e.g., using Conflict-free Replicated Data
   Types (CRDTs) [Jeffery], heterogeneity and customization (e.g.,
   using intent-based management mechanisms [Cao]), and limited
   resources
-->


15) <!--[rfced] How can we break this run-on sentence up for the reader?

Original:

   *  (Computation placement) Selecting, in a centralized or
      distributed/peer-to-peer manner, an appropriate compute device
      based on available resources, location of data input and data
      sinks, compute node properties, etc., and with varying goals
      including end-to-end latency, privacy, high availability, energy
      conservation, or network efficiency, for example, using load-
      balancing techniques to avoid congestion.

Perhaps:

   * Computation placement: in a centralized or
   distributed/peer-to-peer manner, selecting an appropriate compute
   device.  The selection is based on available resources, location of
   data input and data sinks, compute node properties, etc. with
   varying goals.  These goals include end-to-end latency, privacy, high
   availability, energy conservation, or network efficiency.  For
   example, using load-balancing techniques to avoid congestion.


-->


16) <!--[rfced] We are having difficulty parsing the parenthetical. Please
     review and let us know how it may be updated for clarity.  

Original:

   * Maintaining consistency, freshness, reliability, and privacy of
   stored/cached data in systems that are distributed, constrained,
   and dynamic (e.g., owing to end devices and computing nodes churn
   or mobility), and which can have additional data governance
   constraints on data storage location.
-->      


17) <!--[rfced] Is the following sentence intended to be a list of
     characteristics of communication brokering? If so, may we update
     it as follows?

Original:

   Communication brokering is a typical function of IoT edge computing
   that facilitates communication with IoT devices, enabling clients
   to register as recipients for data from devices, as well as
   forwarding/ routing of traffic to or from IoT devices, enabling
   various data discovery and redistribution patterns, for example,
   north-south with clouds, east-west with other edge devices
   [I-D.mcbride-edge-data-discovery-overview].

Perhaps:

   Communication brokering is a typical function of IoT edge computing
   that facilitates communication with IoT devices, enables clients to
   register as recipients for data from devices forwards/routes of
   traffic to or from IoT devices, enables various data discovery and
   redistribution patterns (for example, north-south with clouds and
   east-west with other edge devices
   [I-D.mcbride-edge-data-discovery-overview].
-->   


18) <!--[rfced] It's unclear how "dynamic" fits into the sentence below.
     Is it meant to read "dynamic environtments"?

Original:
   *  Addressing concerns such as limited resources, privacy, dynamic,
      and heterogeneous environments to deploy machine learning at the
      edge:

Perhaps:
   *  Addressing concerns such as limited resources, privacy, and dynamic
      and heterogeneous environments to deploy machine learning at the
      edge:
-->      


19) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of RFC 5743 have been adhered to in this document.  -->


20) <!--[rfced] Throughout the document, there were certain places we may
     have expected a citation.  Please review cases like the following
     (there may be more, just examples):

 As the number of people working on farming has been decreasing over
 time,...

  *Smart Construction*
      Safety is critical at construction sites.  Every year, many
      construction workers lose their lives because of falls,
      collisions, electric shocks, and other accidents.

 Policy makers have begun to provide frameworks that limit the usage
 of personal data and impose strict requirements on data controllers
 and processors.

-->


21) <!-- [rfced] Throughout the text, the following terminology appears to
     be used inconsistently. Please review these occurrences and let
     us know if/how they may be made consistent.

a) Capitalization

Big Data vs. big data
Cloud vs. cloud
Industrial IoT vs. industrial IoT
Smart Grid vs. smart grid
Thing vs. thing
Edge vs. edge

b) hyphenation

edge computing vs. edge-computing (when in attributive position (before a noun))
-->


22) <!-- [rfced] FYI - We have added expansions for the following
     abbreviations per Section 3.6 of RFC 7322 ("RFC Style
     Guide"). Please review each expansion in the document carefully
     to ensure correctness.

Content Delivery Network (CDN)
Constrained Application Protocol (CoAP)
Discovery Domain Set (DDS)
Information-Centric Networking (ICN)
Light Detection and Ranging (LiDAR)
Multi-access Edge Computing (MEC)
Message Queuing Telemetry Transport (MQTT)
Open Platform Communications Unified Architecture (OPC UA)
Software-Defined Networking (SDN)
Virtual Machine (VM)
-->


23) <!-- [rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any changes are needed. For example, please
     consider whether "native" should be updated.

In addition, please consider whether "traditional" should be updated
for clarity.  While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
-->


Thank you.

RFC Editor/ap/mf

*****IMPORTANT*****

Updated 2024/03/18

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

   Please review and resolve any questions raised by the RFC Editor 
   that have been included in the XML file as comments marked as 
   follows:

   <!-- [rfced] ... -->

   These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

   Please ensure that you review any changes submitted by your 
   coauthors.  We assume that if you do not speak up that you 
   agree to changes submitted by your coauthors.

*  Content 

   Please review the full content of the document, as this cannot 
   change once the RFC is published.  Please pay particular attention to:
   - IANA considerations updates (if applicable)
   - contact information
   - references

*  Copyright notices and legends

   Please review the copyright notice and legends as defined in
   RFC 5378 and the Trust Legal Provisions 
   (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

   Please review the markup in the XML file to ensure that elements of  
   content are correctly tagged.  For example, ensure that <sourcecode> 
   and <artwork> are set correctly.  See details at 
   <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

   Please review the PDF, HTML, and TXT files to ensure that the 
   formatted output, as generated from the markup in the XML file, is 
   reasonable.  Please note that the TXT will have formatting 
   limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

   *  your coauthors
   
   *  [e-mail] (the RPC team)

   *  other document participants, depending on the stream (e.g., 
      IETF Stream participants are your working group chairs, the 
      responsible ADs, and the document shepherd).
     
   *  [e-mail], which is a new archival mailing list 
      to preserve AUTH48 conversations; it is not an active discussion 
      list:
     
     *  More info:
        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
     
     *  The archive itself:
        https://mailarchive.ietf.org/arch/browse/auth48archive/

     *  Note: If only absolutely necessary, you may temporarily opt out 
        of the archiving of messages (e.g., to discuss a sensitive matter).
        If needed, please add a note at the top of the message that you 
        have dropped the address. When the discussion is concluded, 
        [e-mail] will be re-added to the CC list and 
        its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
 — OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
   https://www.rfc-editor.org/authors/rfc9556.xml
   https://www.rfc-editor.org/authors/rfc9556.html
   https://www.rfc-editor.org/authors/rfc9556.pdf
   https://www.rfc-editor.org/authors/rfc9556.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9556-diff.html
   https://www.rfc-editor.org/authors/rfc9556-rfcdiff.html (side by side)

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9556-xmldiff1.html

The following files are provided to facilitate creation of your own 
diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
   https://www.rfc-editor.org/authors/rfc9556.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates 
only: 
   https://www.rfc-editor.org/authors/rfc9556.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9556

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9556 (draft-irtf-t2trg-iot-edge-10)

Title            : IoT Edge Challenges and Functions
Author(s)        : J. Hong, Y. Hong, X. de Foy, M. Kovatsch, E. Schooler, D. Kutscher
WG Chair(s)      : 
Area Director(s) :