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

[Yong-Geun Hong <[e-mail]>]

Dear Alanna Paloma.

Thanks for your efforts.

For your question, I agreed to  remove the period after “Y” to reflect RFC
9453.

Best regards.

Yong-Geun.

2024년 3월 22일 (금) 오전 3:48, Alanna Paloma <[e-mail]>님이 작성:

> Authors,
>
> Thank you for your replies.  We have updated the files as requested. See
> below for additional questions and comments.
>
> ) Yong-Geun - In RFC 9453, your name appears as "Y-G.” in the header, and
> in this document, it appears as "Y.-G.” May we update this document to
> remove the period after “Y” to reflect RFC 9453?
>
> ) Might it be helpful to the reader to clarify the slash in cases like the
> following (i.e., does it stand for "and", "or", or "and/or"?)?  Note: this
> appears in several places, the following is just an example.
>
> Original:
>    The IoT gateway plays a common role in providing access to a
>
>    heterogeneous set of IoT devices/sensors,...
>
>
>
> Perhaps:
>
>    The IoT gateway plays a common role in providing access to a
>
>    heterogeneous set of IoT devices and sensors,…
>
> >> 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.
> >> -->
> > Good catch – we meant the second variant.
>
> ) Please clarify, should the sentence be updated to use “devise” or should
> it be updated to the Perhaps text?
>
> >> 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.
> >> -->
> > The figure should probably be scaled so that the font size in the figure
> corresponds to the one in the text and so that the figure is not wider than
> the text width. What is a good way to achieve this in a portable fashion?
>
> ) We have removed the width and height attributes from both SVG figures in
> order for them to scale. Please see the HTML and PDF outputs.
>
> >> 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.
> >> -->
> > Good point – I suggest that we (authors) go through the document and add
> references to such statements.
>
> ) Please note that we still await word regarding where citations should be
> added.
> ---
> The files have been posted here (please refresh):
>  https://www.rfc-editor.org/authors/rfc9556.xml
>  https://www.rfc-editor.org/authors/rfc9556.txt
>  https://www.rfc-editor.org/authors/rfc9556.html
>  https://www.rfc-editor.org/authors/rfc9556.pdf
>
> The relevant diff files have been posted here:
>  https://www.rfc-editor.org/authors/rfc9556-diff.html (comprehensive diff)
>  https://www.rfc-editor.org/authors/rfc9556-auth48diff.html (AUTH48
> changes)
>
> Please review the document carefully and contact us with any further
> updates you may have.  Note that we do not make changes once a document is
> published as an RFC.
>
> We will await approvals from each party listed on the AUTH48 status page
> below prior to moving this document forward in the publication process.
>
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9556
>
> Thank you,
> RFC Editor/ap
>
> > On Mar 20, 2024, at 4:13 PM, Xavier De Foy <Xavier.DeFoy=
> [e-mail]> wrote:
> >
> > Hi,
> >  Thank you very much for the review and updates. I generally agree with
> Dirks replies and added a few minor comments with the marker [xdf] below. I
> believe at this stage there are a couple of open items (one about the
> figure, and one about possibly adding references).  About the figures, I
> don’t have a strong opinion (the current figures, which I guess are still
> not scaled, look fine to me on PC and phone, and I don’t know how to test
> with scaling). For the second point I’ll check with the editor of the use
> case section.
> >  Best Regards,
> > Xavier.
> >  From: Dirk Kutscher <[e-mail]>
> > Sent: Tuesday, March 19, 2024 10:43 AM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]; Xavier De Foy
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> > Subject: Re: AUTH48: RFC-to-be 9556 <draft-irtf-t2trg-iot-edge-10> for
> your review
> >  Hello,
> > many thanks for the careful review and the questions.
> > Some answers inline:
> > 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
> > -->
> > ACK
> > 2) <!--[rfced] Dirk and Matthias: Is there a "short name" we could use
> > for your organizations in the header?-->
> > For Dirk: HKUST(GZ)
> > 3) <!-- [rfced] Please insert any keywords (beyond those that appear in
> > the title) for use on https://www.rfc-editor.org/search. -->
> >     •
> > in-network computing
> >     • in network caching
> >     • in network storage
> >
> > 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.-->
> > ACK
> > 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.
> > -->
> > Variant A sounds good.
> > 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.
> > -->
> > Good catch – we meant the second variant.
> > 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.
> > -->
> > Yes, thank you.
> > 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.
> > -->
> > Variant B sounds good.
> > 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.
> > -->
> > The figure should probably be scaled so that the font size in the figure
> corresponds to the one in the text and so that the figure is not wider than
> the text width. What is a good way to achieve this in a portable fashion?
> > [xdf] I don’t have a strong opinion on this, but after checking the pdf
> and html links you provide at the end of this email, on a laptop and on a
> phone, the 2 figures look fine as they are right now.
> > 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.
> > -->
> > How about this:
> > Similarly, in a distributed image processing application, some image
> processing
> > functions can be executed at the edge or in the cloud. To limit the
> amount of data to be uploaded to central cloud functions, IoT edge devices
> may pre-process data.
> > 11) <!--[rfced] Should "IRTF attendees" be further clarified? Is this a
> > particular meeting? Participants of all Research Groups?-->
> > I suggest "participants of T2TRG meetings".
> > 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.
> > -->
> > How about:
> > "In a broker-based system, an IoT gateway can act 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].
> > -->
> > Yes, much better.
> > 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
> > -->
> > Thanks for spotting this. This sentence seems problematic for a couple
> of reasons. The examples are quite specific. If co-authors and our shepherd
> agree, we could simplify as follows:
> > Adapting cloud management platforms to the edge to account for its
> distributed nature, heterogeneity, need for customization, and limited
> resources.
> > [xdf] sounds good to me. I would propose keeping the references, by
> adding a sentence after the one proposed by Dirk. Something like this (if
> co-authors and shepherd agree):
> > OLD:
> > * 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.
> > NEW:
> > * Adapting cloud management platforms to the edge to account for its
> distributed nature, heterogeneity, need for customization, and limited
> resources. For example, using Conflict-free Replicated Data Types (CRDTs)
> [Jeffery] or intent-based management mechanisms [Cao].
> > 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.
> > -->
> > Yes, much better – thanks!
> > 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.
> > -->
> > I suggest the following:
> >     • Maintaining consistency, freshness, reliability, and privacy of
> stored/cached data in systems that are distributed, constrained, and
> dynamic (e.g., due to node mobility, energy-saving regimes, and
> disruptions) 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].
> > -->
> > Thanks, much better. Some additional edits:
> > 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
> > 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].
> > [xdf] minor typo: need to close the parenthesis at the end of the
> paragraph.
> > 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:
> > -->
> > Yes.
> > 19) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1
> of RFC 5743 have been adhered to in this document. -->
> > IMO, "Status of This Memo" has all the required information.
> > 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.
> > -->
> > Good point – I suggest that we (authors) go through the document and add
> references to such statements.
> > 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
> > I'm in favor of using lowercase for all terms except for "Thing".
> > b) hyphenation
> > edge computing vs. edge-computing (when in attributive position (before
> a noun))
> > -->
> > How about just using "edge computing"?
> > 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)
> > -->
> > Looks good.
> > 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.
> > -->
> > Personally, I don't think "native" and "tradition" needs updating (but
> open to suggestions from co-authors).
> > Many thanks for the careful review and the useful suggestions!
> > Best regards,
> > Dirk
> > 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) :
> >
> >
> >
> >
> > Defining the XR Experience: Enabling the Immersivity Ecosystem
> > 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.
>
>
>