Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t2trg-iot-edge-10> for your review
Yong-Geun Hong <yonggeun.hong@gmail.com> Tue, 02 April 2024 23:28 UTC
Return-Path: <yonggeun.hong@gmail.com>
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 AABA9C14F5F1; Tue, 2 Apr 2024 16:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xpeHZmH2jNFQ; Tue, 2 Apr 2024 16:28:16 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 41A0BC151094; Tue, 2 Apr 2024 16:27:48 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2d71f9e07a9so8794881fa.1; Tue, 02 Apr 2024 16:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712100465; x=1712705265; darn=rfc-editor.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VBEeilMgqoKmog7xz3mdkxvC6tuDWq9F5lcERjzyew4=; b=LAmd7+hZz+UilBzSPWC/Onm/xBanjwICI3r7NLFk2Hb7l2ONBxQjx5+rOZySpHE+7p pEGZ0qMOYbmHP8/jY8tGHdZ+9d40sEj8Mibbhy9km26/J0M5PltCoVMyoy0vKUOhnynH b/npVdXyjqF6sPzHagGueol8LtO+qgWphB6EXB3c7+wAUTw/ll+2NhnChL63jfyVpcFv LYktR9MSt6dD3yCJNLHkufMwCp8mIls8HGlkha7T0nZ7U9eALmMM00GdcsB08oymQaHM csPUNmflO6DrGoFddYDDhkOSiWyogxHx64NCJdp1uuI6BWDSrLSo5auNI4C5KSg7MLNu NWdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712100465; x=1712705265; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VBEeilMgqoKmog7xz3mdkxvC6tuDWq9F5lcERjzyew4=; b=HlobTGAky+/sPHz0muR/7dViinrJ4H3ANwbsd/A0vsBUzWtdTvk6J3d2u9rJztW/Tj CSrBqDrl/A4lyv5G4vTjaKWxEE/SA+TFHIk+zS6m+zNLtiPU6fs1/70cVw97Mygdi4/Q iiZGfjMZ1rocj4cH75bSZo+/LDTuyhlifvAMiJM4LidfDmWlCYEEoiPMaFQZhQ9hgEnn +GsLT21ictrlpgFs+aSQZTcWePa/ITi8oVpsQ+sVhtbvuv1ntKwlqcn20KW99vFCuji5 9mvqLAXi0jWlEe2pNhz72NIvv8yRCQc6P2JCvXACjSrubpt9/mn25zgVvJIDh/Y1cKQh gGgQ==
X-Forwarded-Encrypted: i=1; AJvYcCWYUC+RLpDvbv+6hZnUULyk/V7v7G9wZlXEH+G0/B3NWj2OYW0qpSgDv/TmBWSPxnQkwUaasXbtVzppV9S/C+YtbBEf2cFCMfa8ZQjuIK/3SkPAkGKuAdJrxHl2mqA20fo8+JenTBYn
X-Gm-Message-State: AOJu0Yw2nAVHAJiCu4QbUcvCVGVA/KCiPpxIzVKmP/RT4gqvqiN1pfjg 2jad9C7G4jk+axdPnwJML+7hg/8R0+F6lgx0oyc2WKM/JA7yG5usZSTsrdPNCGVRLlkgKmXJlEa vGtJBk7g38uh/nD7zRc6T56Zd6UA=
X-Google-Smtp-Source: AGHT+IFLZrOTqtynCpePHemII5BuGj78JzpZai/XcSoNysFEBy2InaYEaH8zm7I7LHco4pxOkjxVuBAVDkEJ0ARr48s=
X-Received: by 2002:a05:651c:14a:b0:2d2:a4e6:a5b0 with SMTP id c10-20020a05651c014a00b002d2a4e6a5b0mr7860510ljd.4.1712100465043; Tue, 02 Apr 2024 16:27:45 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <7A24D617-7A09-42E7-88DA-EB9B40CC2EA2@amsl.com>
From: Yong-Geun Hong <yonggeun.hong@gmail.com>
Date: Wed, 03 Apr 2024 08:27:32 +0900
Message-ID: <CACt2foFLXvoAjzxmYwDdw_22pdsAK=9bUhBrQ3FB1J9MPGNWuQ@mail.gmail.com>
To: Alanna Paloma <apaloma@amsl.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>, "ietf@kovatsch.net" <ietf@kovatsch.net>, "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>
Content-Type: multipart/alternative; boundary="00000000000009f2d5061525747d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/U4y7cFs5qacRdW77t-3Q5XWHv1M>
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: Tue, 02 Apr 2024 23:28:21 -0000
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%7C92e84cebfbfd47abbe520 > >>> 8 > >>> 0c6b87953f%7C0%7C0%7C638466437584472449%7CUnknown%7CTWFpbGZsb3d8eyJWI > >>> j > >>> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > >>> C > >>> %7C&sdata=UvGwKQAJJYocuyF77hssONfQTP6o9OV0UprTpPbkYVc%3D&reserved=0 > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9556.txt&data=05%7C02%7Cari.keranen%40e > >>> r > >>> icsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abbe520 > >>> 8 > >>> 0c6b87953f%7C0%7C0%7C638466437584480911%7CUnknown%7CTWFpbGZsb3d8eyJWI > >>> j > >>> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > >>> C > >>> %7C&sdata=U2KKPmrb3or9wAvOffxi%2BymEVRnYJLPV1v4tPrL1ZNc%3D&reserved=0 > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9556.html&data=05%7C02%7Cari.keranen%40 > >>> e > >>> ricsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abbe52 > >>> 0 > >>> 80c6b87953f%7C0%7C0%7C638466437584486868%7CUnknown%7CTWFpbGZsb3d8eyJW > >>> I > >>> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C% > >>> 7 > >>> C%7C&sdata=TlBLeSFoWY8AUuikG6NWi0%2FP3l126rr4lRqvlx3m5zo%3D&reserved= > >>> 0 > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9556.pdf&data=05%7C02%7Cari.keranen%40e > >>> r > >>> icsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abbe520 > >>> 8 > >>> 0c6b87953f%7C0%7C0%7C638466437584491751%7CUnknown%7CTWFpbGZsb3d8eyJWI > >>> 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%7C92e84cebfbfd47a > >>> b > >>> be52080c6b87953f%7C0%7C0%7C638466437584496232%7CUnknown%7CTWFpbGZsb3d > >>> 8 > >>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > >>> 0 > >>> %7C%7C%7C&sdata=qXsDiPUJDQjTJEf2WU3c%2FUH29Klagl%2BFBNUHMQ2HcNU%3D&re > >>> s > >>> erved=0 (comprehensive diff) > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9556-auth48diff.html&data=05%7C02%7Cari. > >>> keranen%40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebf > >>> b > >>> fd47abbe52080c6b87953f%7C0%7C0%7C638466437584500657%7CUnknown%7CTWFpb > >>> G > >>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > >>> % > >>> 3D%7C0%7C%7C%7C&sdata=tR25pGpGhLaLxEy9A3R9wUNrCrfwv16bOz%2BZIyGEZrI%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%7C92e84cebfbfd47abbe52080c6b > >>> 8 > >>> 7953f%7C0%7C0%7C638466437584505133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > >>> 4 > >>> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C& > >>> s > >>> data=kzFEwCnqIAUny0o13ijF5OqnFQ9N99%2F%2Fz4YshWSMh1s%3D&reserved=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%7Ce84ce8fc30894c03e9f908dc49d78 > >>>> 462%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638466437584514144% > >>>> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 > >>>> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=VnIvjPVfSj92XST0UrVrZ1%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%7C92e84cebfbfd47abbe52080 > >>>> c6b87953f%7C0%7C0%7C638466437584520753%7CUnknown%7CTWFpbGZsb3d8eyJWI > >>>> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C > >>>> %7C%7C&sdata=YpmQ82BhRLWV6uZFaYqaTzsvN08TKVXmZSvjlL2RGJw%3D&reserved > >>>> =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%7Ce84ce8fc30894c > >>>> 03e9f908dc49d78462%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C6384 > >>>> 66437584538705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > >>>> 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%7C92e > >>>> 84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638466437584543163%7CUnknown > >>>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL > >>>> CJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=SudpBSCij8edoGrqCDfHkTHOFIXZ8kmb50O > >>>> 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%7C92e84cebfbfd47ab > >>>> be52080c6b87953f%7C0%7C0%7C638466437584547126%7CUnknown%7CTWFpbGZsb3 > >>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > >>>> %7C0%7C%7C%7C&sdata=KdSE6m1NJqWxMeMX%2FDJxQ2oFObt4shNMq%2BIqpxpdKTw% > >>>> 3D&reserved=0 > >>>> https://ww/ > >>>> w.rfc-editor.org%2Fauthors%2Frfc9556.html&data=05%7C02%7Cari.keranen > >>>> %40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47a > >>>> bbe52080c6b87953f%7C0%7C0%7C638466437584551533%7CUnknown%7CTWFpbGZsb > >>>> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > >>>> D%7C0%7C%7C%7C&sdata=NomIeyAnn%2BsOiWL22E5yM0VgVXoVq3cCFPTnK42kRTI%3 > >>>> D&reserved=0 > >>>> https://ww/ > >>>> w.rfc-editor.org%2Fauthors%2Frfc9556.pdf&data=05%7C02%7Cari.keranen% > >>>> 40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47ab > >>>> be52080c6b87953f%7C0%7C0%7C638466437584555905%7CUnknown%7CTWFpbGZsb3 > >>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > >>>> %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%7C92e84cebfbfd47ab > >>>> be52080c6b87953f%7C0%7C0%7C638466437584560260%7CUnknown%7CTWFpbGZsb3 > >>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > >>>> %7C0%7C%7C%7C&sdata=EJLtOrMGdFsYJfOSdoIrVqjFL3tXPI21umiD%2BMNF2p0%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%7C92e84cebfb > >>>> fd47abbe52080c6b87953f%7C0%7C0%7C638466437584564576%7CUnknown%7CTWFp > >>>> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > >>>> Mn0%3D%7C0%7C%7C%7C&sdata=WyMuoBr8IOQs1pQg2r4ZWe27NnMbBabaj8JHYizeLs > >>>> 4%3D&reserved=0 > >>>> https://ww/ > >>>> w.rfc-editor.org > %2Fauthors%2Frfc9556-rfcdiff.html&data=05%7C02%7Cari.keranen% > 40ericsson.com%7Ce84ce8fc30894c03e9f908dc49d78462%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638466437584568960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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%7C92e84c > >>>> ebfbfd47abbe52080c6b87953f%7C0%7C0%7C638466437584573332%7CUnknown%7C > >>>> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > >>>> VCI6Mn0%3D%7C0%7C%7C%7C&sdata=tbzNyICnGjlPIu%2F%2B7dZLpxG51bpOrbp0%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%7C92 > >>>> e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638466437584577745%7CUnknow > >>>> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > >>>> LCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fNcgFCayFQT7%2Fix15yulkzG1hNcPvUuw > >>>> 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%7C92e84cebfbf > >>>> d47abbe52080c6b87953f%7C0%7C0%7C638466437584582102%7CUnknown%7CTWFpb > >>>> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M > >>>> 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%7C92e84cebfbfd47abbe520 > >>>> 80c6b87953f%7C0%7C0%7C638466437584586464%7CUnknown%7CTWFpbGZsb3d8eyJ > >>>> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0% > >>>> 7C%7C%7C&sdata=aHlxHfX%2Fwk%2Ft6BR7cS4MgQoxbWExVG3I%2FJE%2FoSz5%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. > > >
- [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t2trg… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Dirk Kutscher
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Xavier De Foy
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Yong-Geun Hong
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Ari Keränen
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Ari Keränen
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Jungha Hong
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Xavier De Foy
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Dirk Kutscher
- Re: [auth48] [irsg] AUTH48: RFC-to-be 9556 <draft… Colin Perkins
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Jungha Hong
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Xavier De Foy
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Yong-Geun Hong
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Matthias Kovatsch
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Dirk Kutscher
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Eve Schooler
- Re: [auth48] AUTH48: RFC-to-be 9556 <draft-irtf-t… Alanna Paloma