Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6lo-use-cases-16> for your review
Yong-Geun Hong <yonggeun.hong@gmail.com> Fri, 01 September 2023 01:02 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 0CC04C1524D3; Thu, 31 Aug 2023 18:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 sZwvyH-0Dz6z; Thu, 31 Aug 2023 18:02:15 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 00193C17EB5B; Thu, 31 Aug 2023 18:02:14 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-4ff7ecd0a0dso506630e87.0; Thu, 31 Aug 2023 18:02:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693530133; x=1694134933; 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=a9dGNeTce7ncq6dLdJZ7xh2kf+S2MbKQKJYu0XURmJo=; b=DDz3YAhX97WASNcXd/Kn+dGp15EqwW1u2/bHMb7P56lvWa1GOi9CdceV0MNGzKpio+ Tori3PJ1++4oXfJS4Kl4ka8Z76N6WZVUb+3mcNIt6I+4QlaKA10UaX4AtdAsks3hh+ZB zXcEvhnDwlAOvjaUXVne/rbrj5NXUd1/r6MHt0oCDN4K/7oz7Ymu+3+9mzncu+JkGX1S JcpVuHLOKbp+u2cF5thfvz8bkiVtGas+Xxr0gtU4sY/cfP7YC+CzC1fhUrwVhYXcyFFQ OgWmC28jhu0E9pfsVLUQhMITrTAkKQ1Ir5sGCKvEaO3k+l3Gshn0emdnwYRd1IJOouKH 16Zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693530133; x=1694134933; 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=a9dGNeTce7ncq6dLdJZ7xh2kf+S2MbKQKJYu0XURmJo=; b=UnXzlBjH1bdotn/K6M0I+EABHhQe8XOM2RO8sEMG1ZiYaaOwsq2KatHqVsatH7Xq2F tgz8GshTn8dC/aLjgUPxraOmpYPxJ/VPpLpVzxnQNyZHdr4IDCRhHzcIGyMOXRAqN8yO ur5MTri7yL4XeLbPzwl5OxsimTNhhb3YYY+lD1p/N4Cn/UzGoTP+RosSzPoLSygbEQCs oDWM6tY+etKtehwHom60C/14kATqjGrTqxaDpzDNkc/2MzohS9deNnqo4cSSV96W9azV s5lvFvhlY7YemByTfu7oKUCA5TNUDNiYMp1O9RYGsyqhaR1O+STq4IBAEUurpWSAhMEr eGvQ==
X-Gm-Message-State: AOJu0YzsSMa0oRAiDhyEW2kcXOtxmrSc6HHz/gW65dXWExAYL6wjl1lW uMq7g3fmcWz/dDs6nKPJ3+YTrCRBaaTF8x5t7lU=
X-Google-Smtp-Source: AGHT+IECEOOEmvgzx9wPws3yMQG6s+a67xMKDaLd/T0l55McFs5X6z/47f3Pvvp0UlxqemaMTwiGbgBSu45BFJtSEKc=
X-Received: by 2002:ac2:494b:0:b0:500:7c56:ff5 with SMTP id o11-20020ac2494b000000b005007c560ff5mr568592lfi.0.1693530132539; Thu, 31 Aug 2023 18:02:12 -0700 (PDT)
MIME-Version: 1.0
References: <20230808073125.CCB933E8A7@rfcpa.amsl.com> <FFB231D5-654A-4987-B673-FFBFDC3F8660@etri.re.kr> <CACt2foFEkkgOUor6x5B-Cj3WL06_50vbf2DvrUiz699nhJZAhQ@mail.gmail.com> <0BAA6F3B-0664-4757-A73A-D1D78B164A51@amsl.com> <CACt2foFgXX9g-cu=K1t73DvPVX0DGWUkN1mZuBG4ke_ffZ+4RQ@mail.gmail.com> <371CB92D-5DF4-4712-A74E-B480CDFEE847@amsl.com>
In-Reply-To: <371CB92D-5DF4-4712-A74E-B480CDFEE847@amsl.com>
From: Yong-Geun Hong <yonggeun.hong@gmail.com>
Date: Fri, 01 Sep 2023 10:02:00 +0900
Message-ID: <CACt2foEcX1Wwae9mH=tYa_noXC+25rotr_k_XHU3W7gYZV0pLQ@mail.gmail.com>
To: Sandy Ginoza <sginoza@amsl.com>
Cc: RFC Editor <rfc-editor@rfc-editor.org>, Carles Gomez Montenegro <carles.gomez@upc.edu>, 최영환 <yhc@etri.re.kr>, Rashid Sangi <sangi_bahrian@yahoo.com>, samita Chakrabarti <samitac.ietf@gmail.com>, 6lo-ads@ietf.org, 6lo-chairs@ietf.org, Shwetha <shwetha.bhandari@gmail.com>, Erik Kline <ek.ietf@gmail.com>, auth48archive@rfc-editor.org
Content-Type: multipart/alternative; boundary="000000000000f76f13060441b5c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/WfVNleXhQAmQprHvSUBMv0Jd-Zc>
Subject: Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6lo-use-cases-16> 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: Fri, 01 Sep 2023 01:02:20 -0000
Dear Sandy Ginoza. Thanks again for your efforts. >From my side, there is no request to update. Everything is O.K. I want to check one thing for Samita's affiliation. Samita, if you want to reflect your new affiliation, let us know. Best regards. Yong-Geun. 2023년 9월 1일 (금) 오전 8:40, Sandy Ginoza <sginoza@amsl.com>님이 작성: > Hi Yong-Geun, Authors, > > We have updated the document as described below. Please review and let us > know if any additional updates are needed or if you approve the RFC for > publication. > > Note that we require an approval from each individual listed in the > document header. > > > The files are available here: > https://www.rfc-editor.org/authors/rfc9453.xml > https://www.rfc-editor.org/authors/rfc9453.txt > https://www.rfc-editor.org/authors/rfc9453.pdf > https://www.rfc-editor.org/authors/rfc9453.html > > Diffs highlighting the most recent updates only: > https://www.rfc-editor.org/authors/rfc9453-lastdiff.html > https://www.rfc-editor.org/authors/rfc9453-lastrfcdiff.html > > AUTH48 diff (highlighting changes since the document entered AUTH48): > https://www.rfc-editor.org/authors/rfc9453-auth48diff.html > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9453-diff.html > https://www.rfc-editor.org/authors/rfc9453-rfcdiff.html > > An alternative comprehensive diff - this version will allow you to view > changes in the Acknowledgements more easily: > https://www.rfc-editor.org/authors/rfc9453-alt-diff.html > > > Thank you, > RFC Editor/sg > > > > > On Aug 23, 2023, at 5:52 PM, Yong-Geun Hong <yonggeun.hong@gmail.com> > wrote: > > > > Dear Sandy Ginoza. > > > > Thanks again for your efforts. > > > > I added my response in lines. > > > > Best regards. > > > > Yong-Geun. > > > > > > 2023년 8월 24일 (목) 오전 1:25, Sandy Ginoza <sginoza@amsl.com>님이 작성: > > Greetings Yong-Geun, > > > > Thank you for your review and detailed reply. We have updated the > document and have a few remaining questions below. The current files are > available here: > > > > https://www.rfc-editor.org/authors/rfc9453.xml > > https://www.rfc-editor.org/authors/rfc9453.txt > > https://www.rfc-editor.org/authors/rfc9453.pdf > > https://www.rfc-editor.org/authors/rfc9453.html > > > > AUTH48 diff (highlighting changes since the document entered AUTH48): > > https://www.rfc-editor.org/authors/rfc9453-auth48diff.html > > > > Comprehensive diffs: > > https://www.rfc-editor.org/authors/rfc9453-diff.html > > https://www.rfc-editor.org/authors/rfc9453-rfcdiff.html > > > > An alternative comprehensive diff - this version will allow you to view > changes in the Acknowledgements more easily: > > https://www.rfc-editor.org/authors/rfc9453-alt-diff.html > > > > > > Open items: > > > > 1) We mistakenly did not include this in our original set of questions. > For readability, may we update the following? > > > > > Original: > > > A user may turn on/off or may control home > > > appliances by pressing a wall switch or by pressing a button in a > > > remote control. > > > > > Perhaps: > > > A user may turn home appliances on and off, or the user may control > them > > by pressing a wall switch or a button on a > > > remote control. > > > > [Yong-Geun] Thanks for the update. Agreed. > > > > 2) Regarding table 2, thank you for your suggested updates. > Unfortunately, some of the hyphenation did not display as desired in all of > the outputs (i.e., the hyphenation breaks in the text were different from > those in the html). Please review our updates to Table 2 and let us know > if you have concerns with the current format and use of abbreviations > (e.g., Tx is used for transmission; we removed the brackets from RFCs > (seems reasonable because they are all referenced elsewhere in the > document). > > > > [Yong-Geun] Thanks for the update. It looks better and simpler. > > One question. As it changed from 'Automation' to > 'Autom.', how about changing from "Requirement" to "Req." ? > > > > > > Thank you, > > RFC Editor/sg > > > > > > > > > > > On Aug 18, 2023, at 11:04 PM, Yong-Geun Hong <yonggeun.hong@gmail.com> > wrote: > > > > > > Dear RFC Editor. > > > > > > Thanks for your efforts to publish RFC 9453. > > > > > > I add my response in lines. > > > > > > Best regards. > > > > > > Yong-Geun. > > > > > > > > > > > > > > >> 보낸 사람: rfc-editor@rfc-editor.org > > >> 날짜: 2023년 8월 8일 오후 4시 31분 32초 GMT+9 > > >> 받는 사람: yonggeun.hong@gmail.com, carles.gomez@upc.edu, yhc@etri.re.kr, > sangi_bahrian@yahoo.com, samitac.ietf@gmail.com > > >> 참조: rfc-editor@rfc-editor.org, 6lo-ads@ietf.org, 6lo-chairs@ietf.org, > shwetha.bhandari@gmail.com, ek.ietf@gmail.com, > auth48archive@rfc-editor.org > > >> 제목: Re: AUTH48: RFC-to-be 9453 <draft-ietf-6lo-use-cases-16> for your > review > > >> > > >> Authors, > > >> > > >> While reviewing this document during AUTH48, please resolve (as > necessary) > > >> the following questions, which are also in the XML file. > > >> > > >> 1) <!-- [rfced] For readability, we would like to flip the order of > the > > >> title. In addition, to match the 6lo Working Group's wording (see > > >> https://datatracker.ietf.org/wg/6lo/charter/), should the title be > updated > > >> as follows? Please review. > > >> > > >> Note that this update would also affect terminology in the abstract. > > >> > > >> Original: > > >> IPv6 over Constrained Node Networks (6lo) Applicability & Use cases > > >> > > >> Perhaps: > > >> Applicability and Use Cases for IPv6 over Networks of > Resource-constrained Nodes (6lo) > > >> --> > > > [Yong-Geun] Agreed. > > >> > > >> > > >> > > >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear > in the > > >> title) for use on https://www.rfc-editor.org/search. > > >> --> > > > [Yong-Geun] It seems that the updated title is enough. > > >> > > >> > > >> > > >> 3) <!-- [rfced] Should this list of design space dimensions be > capitalized > > >> as they are in Appendix A, or may we lowecase the dimensions in > Appendix A? > > >> In addition, we note that Security Level does not appear in the list > in > > >> Appendix A; should it be added to match the list in section 1? > > >> > > >> Original: > > >> In addition, it considers various network design space > > >> dimensions such as deployment, network size, power source, > > >> connectivity, multi-hop communication, traffic pattern, security > > >> level, mobility, and QoS requirements (see Appendix A). > > >> > > >> Original from Appendix A: > > >> In [RFC6568], the following design space dimensions are described: > > >> Deployment, Network size, Power source, Connectivity, Multi-hop > > >> communication, Traffic pattern, Mobility, Quality of Service (QoS). > > >> --> > > > [Yong-Geun] Agree to modify the list of design space dimensions to be > capitalized in Appendix A. > > > I propose to delete “Security Level”. > > >> > > >> > > >> > > >> 4) <!-- [rfced] May we expand SIG as Special Interest Group? > > >> > > >> Original: > > >> The Bluetooth > > >> SIG has also published the Internet Protocol Support Profile (IPSP). > > >> > > >> Perhaps (which matches what appears in RFC 9159): > > >> The Bluetooth Special Interest Group (Bluetooth SIG) has also > published > > >> the Internet Protocol Support Profile (IPSP). > > >> --> > > > [Yong-Geun] Agreed. > > >> > > >> > > >> > > >> 5) <!-- [rfced] Did you intend to include references for ISO/IEC > 14443 A&B > > >> and JIS-X 6319-4? If yes, please provide us with the reference > information > > >> or pointers to the reference information. > > >> > > >> Original: > > >> NFC complements many popular consumer-level wireless > > >> technologies, by utilizing the key elements in existing standards > for > > >> contactless card technology (ISO/IEC 14443 A&B and JIS-X 6319-4). > > >> --> > > > [Yong-Geun] The reference for ISO/IEC 14443 A&B and JIS-X 6319-4 is > not necessary in this draft. So proposed the expression of ISO/IEC 14443 > A&B and JIS-X 6319-4 > > > > > > --> Proposal: > > > NFC complements many popular consumer-level wireless > > > technologies, by utilizing the key elements in existing standards for > > > contactless card technology. > > >> > > >> > > >> > > >> 6) <!-- [rfced] We have the following questions related to Table 2. > > >> > > >> a) Table 2 exceeds the 72-character line limit by 5 characters. We > are reviewing possible ways to trim the length of the table. Please let us > know if you have any suggestions. > > >> > > >> b) Please confirm that the reference to RFC 7428 is correct. We ask > because > > >> we do not see mention of Z-Wave, Home Automation, L2-mesh, or > L3-mesh. > > >> --> > > > [Yong-Geun] Make the table 2 shorter under 72-character. Please find > the attached XML file > > > [Yong-Geun] The reference to RFC 7428 is correct because RFC 7428 > (Transmission of IPv6 Packets over ITU-T G.9959 Networks) is related to > ITU-T G.9959 Networks and the ITU-T G.9959 is one of protocol for Z-wave. > > >> > > >> > > >> > > >> 7) <!-- [rfced] "IPv6 address" is seemingly redundant. May we update > the > > >> text as follows? > > >> > > >> Original: > > >> For MAC-derived IPv6 addresses, please > > >> refer to [RFC8163] for IPv6 address mapping examples. > > >> > > >> Perhaps: > > >> For MAC-derived IPv6 addresses, refer to [RFC8163] for mapping > > >> examples. > > >> --> > > > [Yong-Geun] Agreed. > > >> > > >> > > >> > > >> 8) <!-- [rfced] For clarity and ease of the reader, may we update the > text > > >> as follows? > > >> > > >> Original: > > >> The 6LoWPAN node should > > >> also support [RFC8505] and use it as the default Neighbor > > >> Discovery method. > > >> > > >> Perhaps: > > >> The 6LoWPAN node should > > >> also support the registration extensions defined in [RFC8505] > and > > >> use the mechanism as the default Neighbor Discovery method. > > >> --> > > > [Yong-Geun] Agreed. > > >> > > >> > > >> > > >> 9) <!-- [rfced] May we update the expansion for AP-ND to match what > appears > > >> in RFC 8929, which expands it as "Address-Protected Neighbor > Discovery"? > > >> > > >> Original: > > >> Address Protection for 6LoWPAN > > >> Neighbor Discovery (AP-ND) [RFC8928] enables Source Address > > >> Validation [RFC6620] and protects the address ownership against > > >> impersonation attacks. > > >> --> > > > [Yong-Geun] Agreed. > > >> > > >> > > >> > > >> 10) <!-- [rfced] Is "objective function" needed here? It seems > redundant > > >> with the expansion of MRHOF. > > >> > > >> Original: > > >> Note > > >> that the L3 routing in Netricity uses RPL in non-storing mode with > > >> the MRHOF (Minimum Rank with Hysteresis Objective Function) > objective > > >> function based on their own defined Estimated Transmission Time > (ETT) > > >> metric. > > >> --> > > > [Yong-Geun] Agreed and proposed to delete ‘objective function’. > > >> > > >> > > >> > > >> 11) <!-- [rfced] For readability, may we update "enjoys the advantage > of" > > >> to "benefits from"? Or is there another way we may update? > > >> > > >> Original: > > >> Although other wired and wireless technologies are also used in > Smart > > >> Grid, PLC enjoys the advantage of reliable data communication over > > >> electrical power lines that are already present, and the deployment > > >> cost can be comparable to wireless technologies. > > >> > > >> Perhaps: > > >> Although other wired and wireless technologies are also used in a > > >> smart grid, PLC benefits from reliable data > > >> communication over electrical power lines that are already present, > > >> and the deployment cost can be comparable to wireless technologies. > > >> --> > > > [Yong-Geun] Agreed. > > >> > > >> > > >> 12) <!-- [rfced] We have the following questions related to > references. > > >> > > >> a) Would you like to update the reference [BACnet] reference to the > most > > >> recent version from 2020? > > >> > > >> Current: > > >> [BACnet] ASHRAE, "BACnet-A Data Communication Protocol for > Building > > >> Automation and Control Networks (ANSI Approved)", ANSI/ > > >> ASHRAE Standard 135-2016, January 2016, > > >> <https://www.techstreet.com/ashrae/standards/ashrae- > > >> 135-2016?product_id=1918140#jumps>. > > >> > > > [Yong-Geun] Proposal : > > > [BACnet] ASHRAE, "BACnet-A Data Communication > Protocol for Building > > > Automation and Control Networks (ANSI > Approved)", ANSI/ > > > ASHRAE Standard 135-2020, Ja20, October > 2020. > > > < > https://www.techstreet.com/standards/ashrae-135-2020?product_id=2191852>. > > > > > >> > > >> b) For the specification [BTCorev4.1], would you like to update to > the most > > >> recent version 5.4? Please review and let us know how/if we may > update. > > >> > > >> Current: > > >> [BTCorev4.1] > > >> Bluetooth, "Core Specification Version 4.1", December > > >> 2013, <https://www.bluetooth.com/specifications/specs/ > > >> core-specification-4-1/>. > > > [Yong-Geun] Proposal: > > > [BTCorev5.4] > > > Bluetooth, "Core Specification Version 5.4", > January > > > 2023, < > https://www.bluetooth.com/specifications/specs/core-specification-5-4/>. > > >> > > >> > > >> > > >> c) The URL provided for [IPSP] directs to a page titled > "Specifications and Documents", but there is no document named "Bluetooth > Internet Protocol Support Profile Specification Version 1.0.0". We are > unable to locate a document with this title. Please let us know how this > entry should be updated. > > >> > > >> > > >> Original: > > >> [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet > > >> Protocol Support Profile Specification Version 1.0.0", > > >> December 2014, <https://www.bluetooth.org/en- > > >> us/specification/adopted-specifications>.>. > > >> > > >> perhaps the URL should be to < > https://www.bluetooth.com/specifications/specs/> or > > >> < > https://www.bluetooth.com/specifications/specs/internet-protocol-support-profile-1-0/>? > > > >> > > > [Yong-Geun] Proposal: > > > > > > [IPSP] Bluetooth Special Interest Group, "Bluetooth > Internet > > > Protocol Support Profile Specification > Version 1.0.0", > > > December 2014, < > https://www.bluetooth.com/specifications/specs/internet-protocol-support-profile-1-0/ > >. > > >> > > >> d) Would you like to update the provided URL for [LLCP-1.4] to the > > >> following to lead directly to the document? > > >> > > >> Original: > > >> [LLCP-1.4] NFC Forum, "NFC Logical Link Control Protocol, Version > > >> 1.4", NFC Forum Technical Specification , January 2021, > > >> <https://nfc-forum.org/build/specifications>. > > >> > > >> Perhaps: > > >> [LLCP-1.4] NFC Forum, "Logical Link Control Protocol Technical > > >> Specification", Version 1.4, December 2022, > > >> <https://nfc-forum.org/build/specifications/logical- > > >> link-control-protocol-technical-specification/>. > > >> --> > > > [Yong-Geun] Agreed. > > >> > > >> > > >> > > >> 13) <!-- [rfced] Please note that we have updated this sentence as > follows. > > >> Please review and let us know if any corrections are needed. > > >> > > >> Original: > > >> * Buffering requirements: Some 6lo use case may require higher data > > >> rate than the link layer technology support. > > >> > > >> Current: > > >> Buffering Requirements: > > >> Some 6lo use cases may require a higher data rate than the link- > > >> layer technology supports. > > >> --> > > > [Yong-Geun] Agreed. > > >> > > >> > > >> > > >> 14) <!-- [rfced] We have the following terminology-related questions. > > >> > > >> a) We have updated the document to use "link-layer" (with a hyphen) > where > > >> the terms are acting as an adjective appearing before the noun. > > >> > > >> Similarly, we have updated "constrained node" to "constrained-node" > (with a > > >> hyphen). > > >> > > >> Please review and let us know if you have any concerns. > > > [Yong-Geun] Thanks for the update. Agreed. > > >> > > >> > > >> b) Throughout the text, the following acronyms are missing > expansions. > > >> Please review and let us know if/how we may update. We provided > possible > > >> expansions the right. > > >> > > >> GPRS - General Packet Radio Service or Ground Penetrating Radar > Systems > > >> ISM - Industrial, Scientific, and Medical > > >> LV PLC networks - Low-Voltage PLC networks > > >> > > >> Do instances of Low, Medium, and High Voltage need to be > capitalized? > > > [Yong-Geun] Proposal: > > > GPRS - General Packet Radio Service > > > ISM - Industrial, Scientific, and Medical > > > LV PLC networks - Low-Voltage PLC networks > > >> > > >> > > >> c) FYI, for clarity, we added the following expansions to the provided > > >> acronyms. Please let us know of any objections. > > >> > > >> FDMA - Frequency-Division Multiplex > > >> TDMA - Time-Division Multiple Access > > >> TDD - Time-Division Duplex > > >> --> > > > [Yong-Geun] Thanks for the update. Agreed. > > >> > > >> > > >> > > >> 15) <!-- [rfced] Some author comments are present in the XML. Please > > >> confirm that no updates related to these comments are outstanding. > Note > > >> that the comments will be deleted prior to publication. > > >> --> > > > [Yong-Geun] There are no updates related to these comments. It is > appreciated to delete the comments. > > >> > > >> > > >> > > >> 16) <!-- [rfced] Please review the "Inclusive Language" portion of > the > > >> online Style Guide < > https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > >> and let us know if any changes are needed. > > >> > > >> For example, please consider whether the following should be updated: > > >> Master > > >> Slave > > > [Yong-Geun] The expression of ‘Master’ and ‘Slave’ is not inclusive > language but is a technical word. I think it is O.K. > > >> > > >> > > >> In addition, some guides suggest avoiding "senior citizen" and > recommend > > >> replacements such as "older adults" or "persons 65 years and older" > (see > > >> information about "Age" in > https://www.apa.org/about/apa/equity-diversity-inclusion/language-guidelines?_gl=1*w1b56*_ga*MTg0ODg5NzI0My4xNjkxNDc0OTI5*_ga_SZXLGDJGNB*MTY5MTQ3NDkyOS4xLjAuMTY5MTQ3NDkzNy4wLjAuMA..&_ga=2.202736337.1920239215.1691474929-1848897243.1691474929 > ). > > >> --> > > > [Yong-Geun] I prefer the expression of ‘older adults” rather than > ‘senior citizen’ > > >> > > >> > > >> > > >> Thank you. > > >> > > >> RFC Editor > > >> > > >> > > >> On Aug 8, 2023, at 12:20 AM, rfc-editor@rfc-editor.org wrote: > > >> > > >> *****IMPORTANT***** > > >> > > >> Updated 2023/08/08 > > >> > > >> 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > >> > > >> * The archive itself: > > >> https://mailarchive.ietf.org/arch/browse/auth48archive/ > > >> > > >> * Note: If only absolutely necessary, you may temporarily opt > out > > >> of the archiving of messages (e.g., to discuss a sensitive > matter). > > >> If needed, please add a note at the top of the message that > you > > >> have dropped the address. When the discussion is concluded, > > >> 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://www.rfc-editor.org/authors/rfc9453.xml > > >> https://www.rfc-editor.org/authors/rfc9453.html > > >> https://www.rfc-editor.org/authors/rfc9453.pdf > > >> https://www.rfc-editor.org/authors/rfc9453.txt > > >> > > >> Diff file of the text: > > >> https://www.rfc-editor.org/authors/rfc9453-diff.html > > >> https://www.rfc-editor.org/authors/rfc9453-rfcdiff.html (side by > side) > > >> > > >> Diff of the XML: > > >> https://www.rfc-editor.org/authors/rfc9453-xmldiff1.html > > >> > > >> The following files are provided to facilitate creation of your own > > >> diff files of the XML. > > >> > > >> Initial XMLv3 created using XMLv2 as input: > > >> https://www.rfc-editor.org/authors/rfc9453.original.v2v3.xml > > >> > > >> XMLv3 file that is a best effort to capture v3-related format updates > > >> only: > > >> https://www.rfc-editor.org/authors/rfc9453.form.xml > > >> > > >> > > >> Tracking progress > > >> ----------------- > > >> > > >> The details of the AUTH48 status of your document are here: > > >> https://www.rfc-editor.org/auth48/rfc9453 > > >> > > >> Please let us know if you have any questions. > > >> > > >> Thank you for your cooperation, > > >> > > >> RFC Editor > > >> > > >> -------------------------------------- > > >> RFC9453 (draft-ietf-6lo-use-cases-16) > > >> > > >> Title : IPv6 over Constrained Node Networks (6lo) > Applicability & Use cases > > >> Author(s) : Y. Hong, C. Gomez, Y. Choi, A. Sangi, S. > Chakrabarti > > >> WG Chair(s) : Shwetha Bhandari, Carles Gomez > > >> > > >> Area Director(s) : Erik Kline, Éric Vyncke > > >> > > >> > > >> > > > <draft-ietf-6lo-use-cases-16_Table2.xml> > > > >
- [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6lo-u… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Yong-Geun Hong
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Yong-Geun Hong
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Yong-Geun Hong
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Yong-Geun Hong
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… 최영환
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Rashid Sangi
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Carles Gomez Montenegro
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Samita Chakrabarti
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Sandy Ginoza
- Re: [auth48] [E] Re: AUTH48: RFC-to-be 9453 <draf… Chakrabarti, Samita
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Erik Kline
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Yong-Geun Hong
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Erik Kline
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Yong-Geun Hong
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… 최영환
- Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6… Carles Gomez Montenegro
- [auth48] question for Younghwan Choi - Re: AUTH48… Alice Russo
- Re: [auth48] question for Younghwan Choi - Re: AU… 최영환
- Re: [auth48] question for Younghwan Choi - Re: AU… Alice Russo