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

Matthias Kovatsch <ietf@kovatsch.net> Thu, 04 April 2024 09:35 UTC

Return-Path: <ietf@kovatsch.net>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7139C14F6ED for <auth48archive@ietfa.amsl.com>; Thu, 4 Apr 2024 02:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z770YFP5ENB3 for <auth48archive@ietfa.amsl.com>; Thu, 4 Apr 2024 02:35:04 -0700 (PDT)
Received: from ma04-relay.lansolnet.com (ma04-relay.lansolnet.com [176.95.46.38]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0560C14F6E2 for <auth48archive@rfc-editor.org>; Thu, 4 Apr 2024 02:35:03 -0700 (PDT)
ARC-Authentication-Results: i=1; ma04.lansolnet.com 1; spf=none reason=mailfrom (ip=192.168.8.238, headerfrom=kovatsch.net) smtp.mailfrom=kovatsch.net smtp.helo=mbx100f.cloud4partner.com; dmarc=fail action=none header.from=kovatsch.net disposition=none
ARC-Message-Signature: a=rsa-sha256; b=Q76h/qGQ5BoNazUu5PPLIctMQjVxmRXnjRxCXbO55vnJtVASulMXYd1hcF0LtwWQFGs02KSJzDc PNYcL8x2yBiLcO6kZ6UFVgPm4BthKmkFUgNMCEjTe9fBRu4dG9lWWhclOxLjRg1mkeN41/jQZyy C1MFbhKx030/QGyJysSKsb4mzMazHX6gt6+nIWiZDUl/wdu9bjgoBjDAtQ4xukhPX2ow6nJGwIj mRK9K1Q9XUtmDTCGWQqVSs/09WGef/lr8AvieiqzseW2eRkob1or9eiMIIwdBzCbZV0kuoRHf2L UJwK2c9+oy7SeXCWBbg8vwj+qhyYoVy0q/GGU5LIpw== ; bh=RdZtdsXVHjIxnu9BFww4y/yCxDdTX9czpdgh/RfGFng=; c=relaxed/relaxed; d=hornetsecurity.com; h=from:to:date:subject:mime-version:; i=1; s=hse1; t=1712223202
ARC-Seal: a=rsa-sha256; b=Encdl1jLOF5YyqPSoI9zVdQ3ScSt4vHkHoWB0qcZI5Q+mQhVC1zmkI/yqxsp6E1sWi7i39IWBp6 LTUMAbbChfXtT+Uzx7UEqEVBhrhaSkvMFA03mdtNx6ARM/kyweBVJSP/ihUwg6iAWoJcxwzN8Da P5L0FRYH2gL+gIwBfW03mM+xiJVe0O6GPIJ67LnTV/nGSSHY5sAKrANQ6cI6r6t0/SrCw9pKKr3 mytpKAho37BjpMjmqrsQCbBDu2ee1Aq/HPyYa8pVMqirIDL7iaHGTKWLRw+p+ryL62NS4rsbGZR 8/jUUHZsYX4Xk59NU3jKi6NRIUI7PCqnBfZ2k4N1Rg== ; cv=none; d=hornetsecurity.com; i=1; s=hse1; t=1712223202
Received: from unknown ([192.168.8.238]) by ma04-relay.lansolnet.com; Thu, 04 Apr 2024 11:33:22 +0200
Received: from MBX400B.cloud4partner.com (192.168.8.152) by MBX100F.cloud4partner.com (192.168.8.238) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 4 Apr 2024 11:33:18 +0200
Received: from MBX400B.cloud4partner.com (192.168.8.152) by MBX400B.cloud4partner.com (192.168.8.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.6; Thu, 4 Apr 2024 11:33:17 +0200
Received: from MBX400B.cloud4partner.com ([fe80::b4bf:82e5:a24c:1b81]) by MBX400B.cloud4partner.com ([fe80::b4bf:82e5:a24c:1b81%9]) with mapi id 15.01.2507.006; Thu, 4 Apr 2024 11:33:17 +0200
From: Matthias Kovatsch <ietf@kovatsch.net>
To: Alanna Paloma <apaloma@amsl.com>, Yong-Geun Hong <yonggeun.hong@gmail.com>
CC: Xavier De Foy <Xavier.DeFoy@interdigital.com>, Jungha Hong <jhong@etri.re.kr>, Ari Keränen <ari.keranen@ericsson.com>, Colin Perkins <csp@csperkins.org>, "eve.schooler@gmail.com" <eve.schooler@gmail.com>, "Kutscher, Dirk" <ietf@dkutscher.net>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "irsg@irtf.org" <irsg@irtf.org>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Thread-Topic: AUTH48: RFC-to-be 9556 <draft-irtf-t2trg-iot-edge-10> for your review
Thread-Index: AQHaeVf32T3UWdwz/UmEkt2LbWEU3LE+KU+AgAMLoACAAUhQgIABS48AgAAEn4CAABlsAIAAB0EAgATSWoCACqRKgIAAqj0AgAGHeQCAAQiKgIABU90g
Date: Thu, 04 Apr 2024 09:33:17 +0000
Message-ID: <fd4932405221498aacef5af2711f622d@kovatsch.net>
References: <20240318171609.DB1CBEEA0B@rfcpa.amsl.com> <C01CBC1F-2BB6-42DA-9200-A383FFDC18E1@dkutscher.net> <DS7PR10MB4863BC10556CE4A86998383CE5332@DS7PR10MB4863.namprd10.prod.outlook.com> <EAF7B09B-9840-41D1-AEE4-FD4BDB8D9BE9@amsl.com> <VI1PR07MB6365066AF156EEE967D1898085312@VI1PR07MB6365.eurprd07.prod.outlook.com> <VI1PR07MB6365B1F7B90A4B46F0E8780585312@VI1PR07MB6365.eurprd07.prod.outlook.com> <FA02CD65-1900-44E7-8DFE-F431E5D26872@amsl.com> <004001da7c78$c88d3cb0$59a7b610$@etri.re.kr> <B5D49315-791D-471F-BB69-49051D5E75C0@amsl.com> <DS7PR10MB4863A8A6508B5978AFC675E4E53F2@DS7PR10MB4863.namprd10.prod.outlook.com> <7A24D617-7A09-42E7-88DA-EB9B40CC2EA2@amsl.com> <CACt2foFLXvoAjzxmYwDdw_22pdsAK=9bUhBrQ3FB1J9MPGNWuQ@mail.gmail.com> <6D4DD44C-A60A-475D-86F8-4E8BDA135A18@amsl.com>
In-Reply-To: <6D4DD44C-A60A-475D-86F8-4E8BDA135A18@amsl.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.8.240]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-cloud-security-sender: ietf@kovatsch.net
X-cloud-security-recipient: auth48archive@rfc-editor.org
X-cloud-security-Virusscan: CLEAN
X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on ma04-relay.lansolnet.com with 9B88FB818F1
X-cloud-security-connect: unknown[192.168.8.238], TLS=1, IP=192.168.8.238
X-cloud-security: scantime:.9347
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/E_g1Qc6Gpd_zKexefdD8Z7qNsGg>
Subject: Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t2trg-iot-edge-10> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2024 09:35:08 -0000

Dear Alanna

I hereby also approve the publication.

Kind regards,
Matthias

> -----Original Message-----
> From: Alanna Paloma <apaloma@amsl.com>
> Sent: Wednesday, April 3, 2024 5:14 PM
> To: Yong-Geun Hong <yonggeun.hong@gmail.com>
> Cc: Xavier De Foy <Xavier.DeFoy@interdigital.com>; Jungha Hong
> <jhong@etri.re.kr>; Ari Keränen <ari.keranen@ericsson.com>; Colin Perkins
> <csp@csperkins.org>; Matthias Kovatsch <matthias@kovatsch.net>;
> eve.schooler@gmail.com; Kutscher, Dirk <ietf@dkutscher.net>; rfc-editor@rfc-
> editor.org; irsg@irtf.org; auth48archive@rfc-editor.org
> Subject: Re: AUTH48: RFC-to-be 9556 <draft-irtf-t2trg-iot-edge-10> for your
> review
> 
> Hi Yong-Geun,
> 
> You approval has been noted:
> https://www.rfc-editor.org/auth48/rfc9556
> 
> We will await approvals from Matthias and Eve prior to moving this document
> forward in the publication process.
> 
> Thank you,
> RFC Editor/ap
> 
> > On Apr 2, 2024, at 4:27 PM, Yong-Geun Hong <yonggeun.hong@gmail.com>
> wrote:
> >
> > Dear Alanna Paloma.
> >
> > Thanks for your efforts.
> >
> > I approve the publication of this draft.
> >
> > Best regards.
> >
> > Yong-Geun.
> >
> > 2024년 4월 2일 (화) 오전 9:06, Alanna Paloma <apaloma@amsl.com>님이
> 작성:
> > Hi Xavier,
> >
> > Thank you for your reply. We’ve updated the files accordingly.
> >
> > The files have been posted here (please refresh):
> > https://www.rfc-editor.org/authors/rfc9556.txt
> > https://www.rfc-editor.org/authors/rfc9556.pdf
> > https://www.rfc-editor.org/authors/rfc9556.html
> > https://www.rfc-editor.org/authors/rfc9556.xml
> >
> > The relevant diff files are posted here:
> > https://www.rfc-editor.org/authors/rfc9556-diff.html (comprehensive diff)
> > https://www.rfc-editor.org/authors/rfc9556-auth48diff.html (all AUTH48
> changes)
> > https://www.rfc-editor.org/authors/rfc9556-lastdiff.html (htmlwdiff diff
> between last version and this)
> > https://www.rfc-editor.org/authors/rfc9556-lastrfcdiff.html (rfcdiff between
> last version and this)
> >
> > 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 Apr 1, 2024, at 6:57 AM, Xavier De Foy
> <Xavier.DeFoy@InterDigital.com> wrote:
> > >
> > > Hi Alanna,
> > >
> > > Here is my take on the use of "/" in the draft (if my co-authors agree)
> > >
> > > Original => my suggestion (note: additional note for the editor)
> > >
> > >
> > > 2.1
> > > and/or => and/or
> > > 2.4
> > > and/or => and/or
> > > highly available/efficient => highly available and efficient
> > > audio/video => audio and/or video
> > > Artificial intelligence (AI) / machine learning (ML) systems => Artificial
> intelligence (AI) and machine learning (ML) systems
> > > 3.3
> > > and/or => and/or
> > > 4.2
> > > devices/sensors => devices and sensors
> > > remote/cloud => remote (e.g., cloud)
> > > remote/cloud => remote (e.g., cloud)
> > > IoT devices/computing nodes => The computing nodes
> > > 4.3
> > > network/compute/storage => network/compute/storage
> > > (note to the editor: actually, if using / here is a problem, possibly use
> "network, compute, and storage", but I find the resulting sentence hard to
> parse)
> > > 4.3.2
> > > multi-vendor/operator => multi-vendor and multi-operator
> > > 4.4.1
> > > compute/storage => compute and storage
> > > to/from => to or from
> > > distributed/peer-to-peer => distributed (e.g., peer-to-peer)
> > > 4.4.2
> > > stored/cached data => data stored or cached
> > > 4.4.3
> > > local/mobile => local or mobile
> > > 4.5.1
> > > edge/local => local (e.g., edge)
> > > functions/services => functions and services
> > > 4.5.2
> > > AI/ML => AI/ML (note: keep as is, this is a common contraction)
> > >
> > >
> > > Best Regards,
> > > Xavier.
> > >
> > > -----Original Message-----
> > > From: Alanna Paloma <apaloma@amsl.com>
> > > Sent: Monday, March 25, 2024 2:26 PM
> > > To: Jungha Hong <jhong@etri.re.kr>
> > > Cc: Ari Keränen <ari.keranen@ericsson.com>; Colin Perkins
> <csp@csperkins.org>; yonggeun.hong@gmail.com; Xavier De Foy
> <Xavier.DeFoy@InterDigital.com>; ietf@kovatsch.net;
> eve.schooler@gmail.com; Kutscher, Dirk <ietf@dkutscher.net>; rfc-editor@rfc-
> editor.org; irsg@irtf.org; auth48archive@rfc-editor.org
> > > Subject: Re: AUTH48: RFC-to-be 9556 <draft-irtf-t2trg-iot-edge-10> for your
> review
> > >
> > > Hi Jungha,
> > >
> > > Thank you for your reply. We have updated the files accordingly.
> > >
> > > Please note that we have one remaining query:
> > >> ) 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,…
> > >
> > > …
> > > The files have been posted here (please refresh):
> > > https://www.rfc-editor.org/authors/rfc9556.txt
> > > https://www.rfc-editor.org/authors/rfc9556.pdf
> > > https://www.rfc-editor.org/authors/rfc9556.html
> > > https://www.rfc-editor.org/authors/rfc9556.xml
> > >
> > > The relevant diff files are posted here:
> > > https://www.rfc-editor.org/authors/rfc9556-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9556-auth48diff.html (all AUTH48
> changes)  https://www.rfc-editor.org/authors/rfc9556-lastdiff.html (htmlwdiff
> diff between last version and this)  https://www.rfc-
> editor.org/authors/rfc9556-lastrfcdiff.html (rfcdiff between last version and
> this)
> > >
> > > For the AUTH48 status of this document, please see:
> > > https://www.rfc-editor.org/auth48/rfc9556
> > >
> > > Thank you,
> > > RFC Editor/ap
> > >
> > >> On Mar 22, 2024, at 9:48 AM, Jungha Hong <jhong@etri.re.kr> wrote:
> > >>
> > >> Hi,
> > >>
> > >> Please find my answers inline with [JH].
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Alanna Paloma <apaloma@amsl.com>
> > >> Sent: Saturday, March 23, 2024 1:23 AM
> > >> To: Ari Keränen <ari.keranen@ericsson.com>; Colin Perkins
> > >> <csp@csperkins.org>; jhong@etri.re.kr; yonggeun.hong@gmail.com;
> Xavier
> > >> De Foy <Xavier.DeFoy=40InterDigital.com@dmarc.ietf.org>;
> > >> ietf@kovatsch.net; eve.schooler@gmail.com; Kutscher, Dirk
> > >> <ietf@dkutscher.net>
> > >> Cc: rfc-editor@rfc-editor.org; irsg@irtf.org;
> > >> auth48archive@rfc-editor.org
> > >> Subject: Re: AUTH48: RFC-to-be 9556 <draft-irtf-t2trg-iot-edge-10> for
> > >> your review
> > >>
> > >> Authors, Ari, and Colin,
> > >>
> > >> Thank you for your replies. We have updated the files accordingly. Please
> see below for our additional questions.
> > >>
> > >>> The text in sec 2.4 “Self-driving car”says :
> > >>>  such as high-resolution cameras, radars, Light Detection and
> > >>> Ranging (LiDAR), sonar sensors, and GPS systems  Since we say “radars”
> should we also say “LiDARs” or change “radars” to “radar”?
> > >>
> > >> ) Instead of pluralizing “LiDAR”, may we update it to “LiDAR systems”?
> > >>
> > >> Perhaps:
> > >>  With a multitude of sensors, such as high-resolution
> > >>  cameras, radars, Light Detection and Ranging (LiDAR) systems, sonar
> > >>  sensors, and GPS systems, autonomous vehicles generate vast
> > >>  amounts of real-time data.
> > >>
> > >> [JH] “LiDAR systems” is better.
> > >>
> > >> ) 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?
> > >>
> > >> [JH] Please update it to the Perhaps text.
> > >>
> > >>
> > >>>> 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.
> > >>
> > >> [JH] I have added 8 citations as follows:
> > >>
> > >> *Smart Factory*
> > >> The use of edge computing in a smart factory [Jamilu] can reduce the
> > >> cost of network and storage resources by reducing the communication
> > >> load to the central data center or server.
> > >>
> > >> [Jamilu] Argungu, J., Idina, M., Chalawa, U., Ummar, M., Bello, S., Arzika, I.,
> and Mala, B.,
> > >>   "A Survey of Edge Computing Approaches in Smart Factory", International
> Journal of Advanced
> > >>          Research in Computer and Communication Engineering, Vol. 12, Issue
> 9, September 2023.
> > >>
> > >> *Smart Grid*
> > >> In future smart city scenarios, the Smart Grid will be critical in
> > >> ensuring highly available/efficient energy control in city-wide
> > >> electricity management [Mehmood].
> > >>
> > >> [Mehmood] Mehmood, M., Oad, A., Abrar, M., Munir, H., Hasan, S.,
> Muqeet, H., and Golilarz, N.,
> > >>           "Edge computing for IoT-enabled smart grid", Security and
> Communication Networks, Vol. 2021,
> > >>           Article ID 5524025, https://doi.org/10.1155/2021/5524025.
> > >>
> > >> *Smart Agriculture*
> > >> In existing farms, simple systems such as management according to
> > >> temperature and humidity can be easily and inexpensively implemented
> > >> using IoT technology [Tanveer].
> > >>
> > >> As the number of people working on farming has been decreasing over
> > >> time, increasing automation enabled by edge computing can be a driving
> > >> force for future smart agriculture [OGrady].
> > >>
> > >> [Tanveer] Tanveer, S., Sree, N., Bhavana, B., and Varsha, D., "Smart
> Agriculture System using IoT",
> > >>           2022 IEEE World Conference on Applied Intelligence and Computing
> (AIC), Sonbhadra, India, 2022,
> > >>           pp. 482-486, doi: 10.1109/AIC55036.2022.9848948.
> > >>
> > >> [OGrady] O'Grady, M., Langton, D., and O'Hare, G., "Edge computing: A
> tractable model for smart agriculture?",
> > >>          Artificial Intelligence in Agriculture, Vol. 3, September 2019, Pages
> 42-51, https://doi.org/10.1016/j.aiia.2019.12.001.
> > >>
> > >> *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 [BigRentz].
> > >>
> > >> Using edge computing[Yue], data generated at the construction site can
> > >> be processed and analyzed on an edge server located within or near the
> > >> site.
> > >>
> > >> [BigRentz] BigRentz, "41 Construction Safety Statistics for 2024",
> https://www.bigrentz.com/blog/construction-safety-statistics.
> > >>
> > >> [Yue] Yue, Q.,Mu, S., Zhang, L., Wang, Z., Zhang, Z., Zhang, X., Wang, Y.,
> and Miao, Z.,
> > >>      "Assisting Smart Construction With Reliable Edge Computing
> Technology", Frontiers in Energy Research, Sec. Smart Grids,
> > >>       Vol. 10, 2022, https://doi.org/10.3389/fenrg.2022.900298.
> > >>
> > >> *Self-Driving Car*
> > >> Edge computing plays a crucial role in safety-focused self-driving car
> systems [Badjie].
> > >>
> > >> [Badjie] The Future of Autonomous Driving Systems with Edge Computing,
> > >>          https://medium.com/@bakarykumba1996/the-future-of-
> autonomous-driving-systems-with-edge-computing-8c919597c4ee.
> > >>
> > >> *Digital Twin*
> > >> Decision makers can use digital twins to test and validate different
> > >> strategies, identify inefficiencies, and optimize Performance [CertMagic].
> > >>
> > >> [CertMagic] CertMagic, "Digital Twin Technology: Simulating Real-World
> Scenarios for Enhanced Decision Making",
> > >>              https://certmagic.medium.com/digital-twin-technology-
> simulating-real-world-scenarios-for-enhanced-decision-making-8844c51e856d.
> > >>
> > >>
> > >> ---
> > >> The files have been posted here (please refresh):
> > >> https://www.rfc-editor.org/authors/rfc9556.txt
> > >> https://www.rfc-editor.org/authors/rfc9556.pdf
> > >> https://www.rfc-editor.org/authors/rfc9556.html
> > >> https://www.rfc-editor.org/authors/rfc9556.xml
> > >>
> > >> The relevant diff files are posted here:
> > >> https://www.rfc-editor.org/authors/rfc9556-diff.html (comprehensive
> > >> diff)  https://www.rfc-editor.org/authors/rfc9556-auth48diff.html (all
> > >> AUTH48 changes)
> > >> https://www.rfc-editor.org/authors/rfc9556-lastdiff.html (htmlwdiff
> > >> diff between last version and this)
> > >> https://www.rfc-editor.org/authors/rfc9556-lastrfcdiff.html (rfcdiff
> > >> between last version and this)
> > >>
> > >> For the AUTH48 status of this document, please see:
> > >> https://www.rfc-editor.org/auth48/rfc9556
> > >>
> > >> We will await approvals from each party listed on the AUTH48 status page
> below prior to moving this document forward in the publication process.
> > >>
> > >> Thank you,
> > >> RFC Editor/ap
> > >>
> > >>> On Mar 22, 2024, at 7:51 AM, Ari Keränen <ari.keranen@ericsson.com>
> wrote:
> > >>>
> > >>> One small thing that I noticed while reading the diff (sending to retracted
> audience since it’s really nitty). The text in sec 2.4 “Self-driving car”says :
> > >>>  such as high-resolution cameras, radars, Light Detection and
> > >>> Ranging (LiDAR), sonar sensors, and GPS systems  Since we say “radars”
> should we also say “LiDARs” or change “radars” to “radar”?
> > >>> Cheers,
> > >>> Ari
> > >>> From: irsg <irsg-bounces@irtf.org> on behalf of Ari Keränen
> > >>> <ari.keranen=40ericsson.com@dmarc.ietf.org>
> > >>> Date: Friday, 22. March 2024 at 16.35
> > >>> To: Alanna Paloma <apaloma@amsl.com>, Xavier De Foy
> > >>> <Xavier.DeFoy=40InterDigital.com@dmarc.ietf.org>, Kutscher, Dirk
> > >>> <ietf@dkutscher.net>, yonggeun.hong@gmail.com
> > >>> <yonggeun.hong@gmail.com>
> > >>> Cc: auth48archive@rfc-editor.org <auth48archive@rfc-editor.org>,
> > >>> jhong@etri.re.kr <jhong@etri.re.kr>, irsg@irtf.org <irsg@irtf.org>,
> > >>> ietf@kovatsch.net <ietf@kovatsch.net>, rfc-editor@rfc-editor.org
> > >>> <rfc-editor@rfc-editor.org>
> > >>> Subject: Re: [irsg] AUTH48: RFC-to-be 9556
> > >>> <draft-irtf-t2trg-iot-edge-10> for your review Hi Authors & Alanna,
> > >>> I believe the “DDS” acronym should be actually “Data Distribution
> Service” instead of “Discovery Domain Set”.
> > >>> Otherwise the updates as discussed below look good to me.
> > >>> Cheers,
> > >>> Ari (as the doc shepherd)
> > >>> From: Alanna Paloma <apaloma@amsl.com>
> > >>> Date: Thursday, 21. March 2024 at 20.49
> > >>> To: Xavier De Foy <Xavier.DeFoy=40InterDigital.com@dmarc.ietf.org>,
> > >>> Kutscher, Dirk <ietf@dkutscher.net>, yonggeun.hong@gmail.com
> > >>> <yonggeun.hong@gmail.com>
> > >>> Cc: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>,
> > >>> jhong@etri.re.kr <jhong@etri.re.kr>, ietf@kovatsch.net
> > >>> <ietf@kovatsch.net>, eve.schooler@gmail.com
> <eve.schooler@gmail.com>,
> > >>> irsg@irtf.org <irsg@irtf.org>, Ari Keränen
> > >>> <ari.keranen@ericsson.com>, auth48archive@rfc-editor.org
> > >>> <auth48archive@rfc-editor.org>
> > >>> Subject: Re: AUTH48: RFC-to-be 9556 <draft-irtf-t2trg-iot-edge-10>
> > >>> for your review 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%2Fauthors%2Frfc9556.xml&data=05%7C02%7Cari.keranen%40e
> > >>> r
> > >>>
> icsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abbe
> 520
> > >>> 8
> > >>>
> 0c6b87953f%7C0%7C0%7C638466437584472449%7CUnknown%7CTWFpbGZs
> b3d8eyJWI
> > >>> j
> > >>>
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%
> 7C%7
> > >>> C
> > >>>
> %7C&sdata=UvGwKQAJJYocuyF77hssONfQTP6o9OV0UprTpPbkYVc%3D&reserv
> ed=0
> > >>>
> > >>> https://www/.
> > >>> rfc-
> editor.org%2Fauthors%2Frfc9556.txt&data=05%7C02%7Cari.keranen%40e
> > >>> r
> > >>>
> icsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abbe
> 520
> > >>> 8
> > >>>
> 0c6b87953f%7C0%7C0%7C638466437584480911%7CUnknown%7CTWFpbGZs
> b3d8eyJWI
> > >>> j
> > >>>
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%
> 7C%7
> > >>> C
> > >>>
> %7C&sdata=U2KKPmrb3or9wAvOffxi%2BymEVRnYJLPV1v4tPrL1ZNc%3D&reser
> ved=0
> > >>>
> > >>> https://www/.
> > >>> rfc-
> editor.org%2Fauthors%2Frfc9556.html&data=05%7C02%7Cari.keranen%40
> > >>> e
> > >>>
> ricsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abb
> e52
> > >>> 0
> > >>>
> 80c6b87953f%7C0%7C0%7C638466437584486868%7CUnknown%7CTWFpbG
> Zsb3d8eyJW
> > >>> I
> > >>>
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C%
> > >>> 7
> > >>>
> C%7C&sdata=TlBLeSFoWY8AUuikG6NWi0%2FP3l126rr4lRqvlx3m5zo%3D&rese
> rved=
> > >>> 0
> > >>>
> > >>> https://www/.
> > >>> rfc-
> editor.org%2Fauthors%2Frfc9556.pdf&data=05%7C02%7Cari.keranen%40e
> > >>> r
> > >>>
> icsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abbe
> 520
> > >>> 8
> > >>>
> 0c6b87953f%7C0%7C0%7C638466437584491751%7CUnknown%7CTWFpbGZs
> b3d8eyJWI
> > >>> j
> > >>>
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%
> 7C%7
> > >>> C
> > >>>
> %7C&sdata=aC7CtbDFryg%2FnYqlqiov%2FH777F7T4p2iW%2BSS4stxoqM%3D
> &reserv
> > >>> e
> > >>> d=0
> > >>>
> > >>> The relevant diff files have been posted here:
> > >>>
> > >>> https://www/.
> > >>> rfc-editor.org%2Fauthors%2Frfc9556-
> diff.html&data=05%7C02%7Cari.keran
> > >>> e
> > >>>
> n%40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd
> 47a
> > >>> b
> > >>>
> be52080c6b87953f%7C0%7C0%7C638466437584496232%7CUnknown%7CT
> WFpbGZsb3d
> > >>> 8
> > >>>
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C
> > >>> 0
> > >>>
> %7C%7C%7C&sdata=qXsDiPUJDQjTJEf2WU3c%2FUH29Klagl%2BFBNUHMQ2H
> cNU%3D&re
> > >>> s
> > >>> erved=0 (comprehensive diff)
> > >>>
> > >>> https://www/.
> > >>> rfc-editor.org%2Fauthors%2Frfc9556-
> auth48diff.html&data=05%7C02%7Cari.
> > >>>
> keranen%40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84
> cebf
> > >>> b
> > >>>
> fd47abbe52080c6b87953f%7C0%7C0%7C638466437584500657%7CUnknown
> %7CTWFpb
> > >>> G
> > >>>
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0
> > >>> %
> > >>>
> 3D%7C0%7C%7C%7C&sdata=tR25pGpGhLaLxEy9A3R9wUNrCrfwv16bOz%2BZI
> yGEZrI%3
> > >>> D
> > >>> &reserved=0 (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%2Fauth48%2Frfc9556&data=05%7C02%7Cari.keranen%40ericss
> > >>> o
> > >>>
> n.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abbe5208
> 0c6b
> > >>> 8
> > >>>
> 7953f%7C0%7C0%7C638466437584505133%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC
> > >>> 4
> > >>>
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7
> C%7C&
> > >>> s
> > >>>
> data=kzFEwCnqIAUny0o13ijF5OqnFQ9N99%2F%2Fz4YshWSMh1s%3D&reserve
> d=0
> > >>>
> > >>> Thank you,
> > >>> RFC Editor/ap
> > >>>
> > >>>> On Mar 20, 2024, at 4:13 PM, Xavier De Foy
> <Xavier.DeFoy=40InterDigital.com@dmarc.ietf.org> 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 <ietf@dkutscher.net>
> > >>>> Sent: Tuesday, March 19, 2024 10:43 AM
> > >>>> To: rfc-editor@rfc-editor.org
> > >>>> Cc: jhong@etri.re.kr; yonggeun.hong@gmail.com; Xavier De Foy
> > >>>> <Xavier.DeFoy@InterDigital.com>; ietf@kovatsch.net;
> > >>>> eve.schooler@gmail.com; irsg@irtf.org; ari.keranen@ericsson.com;
> > >>>> auth48archive@rfc-editor.org
> > >>>> 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://w/
> > >>>> ww.rfc-
> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=
> > >>>>
> 05%7C02%7Cari.keranen%40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d
> 78
> > >>>>
> 462%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C6384664375845
> 14144%
> > >>>>
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6
> > >>>>
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=VnIvjPVfSj92XST0UrVrZ
> 1%2FJ
> > >>>> jSaC864NLBEU00gSYYI%3D&reserved=0>
> > >>>> 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://w/
> > >>>> ww.nist.gov%2Fnist-research-library%2Fnist-technical-series-publicat
> > >>>> ions-author-
> instructions%23table1&data=05%7C02%7Cari.keranen%40erics
> > >>>>
> son.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abbe52
> 080
> > >>>>
> c6b87953f%7C0%7C0%7C638466437584520753%7CUnknown%7CTWFpbGZsb
> 3d8eyJWI
> > >>>>
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C
> > >>>>
> %7C%7C&sdata=YpmQ82BhRLWV6uZFaYqaTzsvN08TKVXmZSvjlL2RGJw%3D&r
> eserved
> > >>>> =0> 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
> > >>>> * rfc-editor@rfc-editor.org (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).
> > >>>> * auth48archive@rfc-editor.org, which is a new archival mailing list
> > >>>> to preserve AUTH48 conversations; it is not an active discussion
> > >>>> list:
> > >>>> * More info:
> > >>>> https://ma/
> > >>>> ilarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-
> 4Q9l2USxI
> > >>>>
> Ae6P8O4Zc&data=05%7C02%7Cari.keranen%40ericsson.com%7Ce84ce8fc308
> 94c
> > >>>>
> 03e9f908dc49d78462%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7
> C6384
> > >>>>
> 66437584538705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV
> > >>>>
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nGTm%
> 2F8DCz
> > >>>> J1MuFgkfRaS9LSNTRxPZmrwgXMfzyoAe6Y%3D&reserved=0
> > >>>> * The archive itself:
> > >>>> https://ma/
> > >>>>
> ilarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7
> > >>>>
> Cari.keranen%40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92
> e
> > >>>>
> 84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638466437584543163%7CU
> nknown
> > >>>>
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iL
> > >>>>
> CJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=SudpBSCij8edoGrqCDfHkTHOFIXZ8
> kmb50O
> > >>>> XIm%2BH6j8%3D&reserved=0
> > >>>> * 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,
> > >>>> auth48archive@rfc-editor.org 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://ww/
> > >>>> w.rfc-
> editor.org%2Fauthors%2Frfc9556.xml&data=05%7C02%7Cari.keranen%
> > >>>>
> 40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47
> ab
> > >>>>
> be52080c6b87953f%7C0%7C0%7C638466437584547126%7CUnknown%7CT
> WFpbGZsb3
> > >>>>
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D
> > >>>>
> %7C0%7C%7C%7C&sdata=KdSE6m1NJqWxMeMX%2FDJxQ2oFObt4shNMq%2B
> IqpxpdKTw%
> > >>>> 3D&reserved=0
> > >>>> https://ww/
> > >>>> w.rfc-
> editor.org%2Fauthors%2Frfc9556.html&data=05%7C02%7Cari.keranen
> > >>>>
> %40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd4
> 7a
> > >>>>
> bbe52080c6b87953f%7C0%7C0%7C638466437584551533%7CUnknown%7CT
> WFpbGZsb
> > >>>>
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3
> > >>>>
> D%7C0%7C%7C%7C&sdata=NomIeyAnn%2BsOiWL22E5yM0VgVXoVq3cCFPTnK
> 42kRTI%3
> > >>>> D&reserved=0
> > >>>> https://ww/
> > >>>> w.rfc-
> editor.org%2Fauthors%2Frfc9556.pdf&data=05%7C02%7Cari.keranen%
> > >>>>
> 40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47
> ab
> > >>>>
> be52080c6b87953f%7C0%7C0%7C638466437584555905%7CUnknown%7CT
> WFpbGZsb3
> > >>>>
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D
> > >>>>
> %7C0%7C%7C%7C&sdata=lbVjQbXdftUkixDMpukzb1zsw8A867gFVmbun04MS
> %2BQ%3D
> > >>>> &reserved=0
> > >>>> https://ww/
> > >>>> w.rfc-
> editor.org%2Fauthors%2Frfc9556.txt&data=05%7C02%7Cari.keranen%
> > >>>>
> 40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47
> ab
> > >>>>
> be52080c6b87953f%7C0%7C0%7C638466437584560260%7CUnknown%7CT
> WFpbGZsb3
> > >>>>
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D
> > >>>>
> %7C0%7C%7C%7C&sdata=EJLtOrMGdFsYJfOSdoIrVqjFL3tXPI21umiD%2BMNF2
> p0%3D
> > >>>> &reserved=0
> > >>>> Diff file of the text:
> > >>>> https://ww/
> > >>>> w.rfc-editor.org%2Fauthors%2Frfc9556-
> diff.html&data=05%7C02%7Cari.ke
> > >>>>
> ranen%40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84ce
> bfb
> > >>>>
> fd47abbe52080c6b87953f%7C0%7C0%7C638466437584564576%7CUnknown
> %7CTWFp
> > >>>>
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > >>>>
> Mn0%3D%7C0%7C%7C%7C&sdata=WyMuoBr8IOQs1pQg2r4ZWe27NnMbBab
> aj8JHYizeLs
> > >>>> 4%3D&reserved=0
> > >>>> https://ww/
> > >>>> w.rfc-editor.org%2Fauthors%2Frfc9556-
> rfcdiff.html&data=05%7C02%7Cari.keranen%40ericsson.com%7Ce84ce8fc3089
> 4c03e9f908dc49d78462%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0
> %7C638466437584568960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C
> &sdata=dQ4vn44aqsVouGJcUtusKAbPbo5lSKpKhGvFUSiSprA%3D&reserved=0
> (side by side) Diff of the XML:
> > >>>> https://ww/
> > >>>> w.rfc-editor.org%2Fauthors%2Frfc9556-
> xmldiff1.html&data=05%7C02%7Car
> > >>>>
> i.keranen%40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e8
> 4c
> > >>>>
> ebfbfd47abbe52080c6b87953f%7C0%7C0%7C638466437584573332%7CUnkn
> own%7C
> > >>>>
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> X
> > >>>>
> VCI6Mn0%3D%7C0%7C%7C%7C&sdata=tbzNyICnGjlPIu%2F%2B7dZLpxG51bp
> Orbp0%2
> > >>>> FlqNqSbqSzI%3D&reserved=0 The following files are provided to
> > >>>> facilitate creation of your own diff files of the XML.
> > >>>> Initial XMLv3 created using XMLv2 as input:
> > >>>> https://ww/
> > >>>> w.rfc-
> editor.org%2Fauthors%2Frfc9556.original.v2v3.xml&data=05%7C02%
> > >>>>
> 7Cari.keranen%40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C9
> 2
> > >>>>
> e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638466437584577745%7C
> Unknow
> > >>>>
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wi
> > >>>>
> LCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fNcgFCayFQT7%2Fix15yulkzG1hN
> cPvUuw
> > >>>> LietVv8csLI%3D&reserved=0
> > >>>> XMLv3 file that is a best effort to capture v3-related format
> > >>>> updates
> > >>>> only:
> > >>>> https://ww/
> > >>>> w.rfc-
> editor.org%2Fauthors%2Frfc9556.form.xml&data=05%7C02%7Cari.ker
> > >>>>
> anen%40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84ceb
> fbf
> > >>>>
> d47abbe52080c6b87953f%7C0%7C0%7C638466437584582102%7CUnknown
> %7CTWFpb
> > >>>>
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> M
> > >>>>
> n0%3D%7C0%7C%7C%7C&sdata=pLhJh0kYdZqj0WrixWHmFyc0rrjnrXnh4njB%
> 2BW2vb
> > >>>> yI%3D&reserved=0
> > >>>> Tracking progress
> > >>>> -----------------
> > >>>> The details of the AUTH48 status of your document are here:
> > >>>> https://ww/
> > >>>> w.rfc-
> editor.org%2Fauth48%2Frfc9556&data=05%7C02%7Cari.keranen%40eri
> > >>>>
> csson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abbe
> 520
> > >>>>
> 80c6b87953f%7C0%7C0%7C638466437584586464%7CUnknown%7CTWFpbG
> Zsb3d8eyJ
> > >>>>
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 0%
> > >>>>
> 7C%7C%7C&sdata=aHlxHfX%2Fwk%2Ft6BR7cS4MgQoxbWExVG3I%2FJE%2FoS
> z5%2Fro
> > >>>> %3D&reserved=0 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.
> >
> >