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

[Dirk Kutscher <[e-mail]>]

Hi Alanna,

many thanks!

We have been trying to reach Eve, but have not succeeded yet. Please allow for a few more days.

Thanks,
Dirk


On 5 Apr 2024, at 8:14, Alanna Paloma wrote:

> Hi Matthias,
>
> We have noted your approval:
> https://www.rfc-editor.org/auth48/rfc9556
>
> Once we’ve received Eve’s approval, we will move this document forward in the publication process.
>
> Thank you,
> RFC Editor/ap
>
>> On Apr 4, 2024, at 2:33 AM, Matthias Kovatsch <[e-mail]> wrote:
>>
>> Dear Alanna
>>
>> I hereby also approve the publication.
>>
>> Kind regards,
>> Matthias
>>
>>> -----Original Message-----
>>> From: Alanna Paloma <[e-mail]>
>>> Sent: Wednesday, April 3, 2024 5:14 PM
>>> To: Yong-Geun Hong <[e-mail]>
>>> Cc: Xavier De Foy <[e-mail]>; Jungha Hong
>>> <[e-mail]>; Ari Keränen <[e-mail]>; Colin Perkins
>>> <[e-mail]>; Matthias Kovatsch <[e-mail]>;
>>> [e-mail]; Kutscher, Dirk <[e-mail]>; rfc-editor@rfc-
>>> editor.org; [e-mail]; [e-mail]
>>> 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 <[e-mail]>
>>> 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 <[e-mail]>님이
>>> 작성:
>>>> 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
>>> <[e-mail]> 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 <[e-mail]>
>>>>> Sent: Monday, March 25, 2024 2:26 PM
>>>>> To: Jungha Hong <[e-mail]>
>>>>> Cc: Ari Keränen <[e-mail]>; Colin Perkins
>>> <[e-mail]>; [e-mail]; Xavier De Foy
>>> <[e-mail]>; [e-mail];
>>> [e-mail]; Kutscher, Dirk <[e-mail]>; rfc-editor@rfc-
>>> editor.org; [e-mail]; [e-mail]
>>>>> 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 <[e-mail]> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please find my answers inline with [JH].
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alanna Paloma <[e-mail]>
>>>>>> Sent: Saturday, March 23, 2024 1:23 AM
>>>>>> To: Ari Keränen <[e-mail]>; Colin Perkins
>>>>>> <[e-mail]>; [e-mail]; [e-mail];
>>> Xavier
>>>>>> De Foy <Xavier.DeFoy=[e-mail]>;
>>>>>> [e-mail]; [e-mail]; Kutscher, Dirk
>>>>>> <[e-mail]>
>>>>>> Cc: [e-mail]; [e-mail];
>>>>>> [e-mail]
>>>>>> 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 <[e-mail]>
>>> 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 <[e-mail]> on behalf of Ari Keränen
>>>>>>> <ari.keranen=[e-mail]>
>>>>>>> Date: Friday, 22. March 2024 at 16.35
>>>>>>> To: Alanna Paloma <[e-mail]>, Xavier De Foy
>>>>>>> <Xavier.DeFoy=[e-mail]>, Kutscher, Dirk
>>>>>>> <[e-mail]>, [e-mail]
>>>>>>> <[e-mail]>
>>>>>>> Cc: [e-mail] <[e-mail]>,
>>>>>>> [e-mail] <[e-mail]>, [e-mail] <[e-mail]>,
>>>>>>> [e-mail] <[e-mail]>, [e-mail]
>>>>>>> <[e-mail]>
>>>>>>> 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 <[e-mail]>
>>>>>>> Date: Thursday, 21. March 2024 at 20.49
>>>>>>> To: Xavier De Foy <Xavier.DeFoy=[e-mail]>,
>>>>>>> Kutscher, Dirk <[e-mail]>, [e-mail]
>>>>>>> <[e-mail]>
>>>>>>> Cc: [e-mail] <[e-mail]>,
>>>>>>> [e-mail] <[e-mail]>, [e-mail]
>>>>>>> <[e-mail]>, [e-mail]
>>> <[e-mail]>,
>>>>>>> [e-mail] <[e-mail]>, Ari Keränen
>>>>>>> <[e-mail]>, [e-mail]
>>>>>>> <[e-mail]>
>>>>>>> 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=[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://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
>>>>>>>> * [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://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,
>>>>>>>> [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://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.
>>>>
>>>>
>>