Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6lo-use-cases-16> for your review
Samita Chakrabarti <samitac.ietf@gmail.com> Tue, 05 September 2023 20:58 UTC
Return-Path: <samitac.ietf@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 B99AFC15199F; Tue, 5 Sep 2023 13:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 fqtRlm5ksxu7; Tue, 5 Sep 2023 13:58:34 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 EE77BC15199D; Tue, 5 Sep 2023 13:58:33 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-4107e6fb0e8so19788831cf.3; Tue, 05 Sep 2023 13:58:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693947513; x=1694552313; 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=W5dX1Sbcu2+kLmM0ricqn0GJzk/cgdu5bJAw17IIxMw=; b=PQWIdxuoWLY3WHnvOpeY4zZ6aaKj3Jb8sNIGv7eyzYm1URi+Ey67IjK4m19qSxjfV4 sDVL6UdBspg2z4TpznrvZ/v0GvBGVQvWpu1k/PfTn1FxjCjxO9f6PlLVp2oqsTgUIGuK +it7QMn61b7D6Neo+SbhAk3LVvZWD41lo7z5jO5J10+0scq4nt8ojhPw6B5/ziVjZpK4 fE/lQAk1FeGyqpBj55jW4ezP6TwXfUoRS34IJY7uXqPtvqftU8/jIaxW+15OFccSZjtX sfu8o9XlPB9VJXWo8DGYWPNr8cDxzJrsaKhWS8xlRIYruuziBnsFI9MhjS04kHjWUVHm hkZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693947513; x=1694552313; 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=W5dX1Sbcu2+kLmM0ricqn0GJzk/cgdu5bJAw17IIxMw=; b=EnKyPpLzgoC9dXHfGqke7LxV0J3MAcdJpw9bX3B52UvjGX6PhZq02lsLKsoXNHeMtz DHHdtA/PiD/sNwbC9uvzS+HlZ12bksc1v2PeQH/OqWyaKmi+pjrTkEyQODqzLyGdWDmi VOkfiJ12XHjRoZI/GjWExFQuGI7KnYXMl0F1oB3eZTkPdl8cd26gSxLgG19WJR3ts+fW iHEoEq3Dj1RtVgfoCD4GH6rxWbmHCWYdr+/AKZHat4r07sKKReCcme79QEPudpvkJZez n1nNPbLhK2/8SMhox5tqjKS6sne4LlmZZyJMt0jKKrhWOpzIvnafXQdLjt20NqVXsMmZ ezlg==
X-Gm-Message-State: AOJu0YwU/eo6nP7XiDZdDoLm6uYiwCmpYvwDDGw0UZOYb6VBmCsbwkh1 WyvnZknQmND6JGX0h1ivKTaSdSbAYvx+aSNdmNY=
X-Google-Smtp-Source: AGHT+IELvtGbPz6s1VFqKwoXApK3FIiMBQ4uhDKjzL6pCNI5x4nsJym19FAZoZbmqC246RxxeUyZdgpfLAb8OCv8T4k=
X-Received: by 2002:a05:622a:c6:b0:412:1c47:773b with SMTP id p6-20020a05622a00c600b004121c47773bmr19161461qtw.63.1693947512487; Tue, 05 Sep 2023 13:58:32 -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> <CACt2foEcX1Wwae9mH=tYa_noXC+25rotr_k_XHU3W7gYZV0pLQ@mail.gmail.com> <rhf7dm98xzq5.rhf7dm97nbu6.g1@dooray.com> <6AD4005B-065D-463A-8A27-F2462D041505@amsl.com> <1421995501.1889822.1693544394682@mail.yahoo.com> <CAAUO2xyhFkNqV9u30s8romaqWrEmaeLgC7QT8N4RaVcbtk2uEA@mail.gmail.com> <C3B221B1-E5A4-4358-B45D-099C78A55F86@amsl.com> <5FD01940-6EA9-4069-893C-8D8CA57B1BB2@amsl.com>
In-Reply-To: <5FD01940-6EA9-4069-893C-8D8CA57B1BB2@amsl.com>
From: Samita Chakrabarti <samitac.ietf@gmail.com>
Date: Tue, 05 Sep 2023 16:58:21 -0400
Message-ID: <CAKmdBpf10XBv2OBseZ29Tjvkbv0h3O8wT8bu992K1m86KVuDRQ@mail.gmail.com>
To: Sandy Ginoza <sginoza@amsl.com>
Cc: Carles Gomez Montenegro <carles.gomez@upc.edu>, Rashid Sangi <sangi_bahrian@yahoo.com>, 최영환 <yhc@etri.re.kr>, Yong-Geun Hong <yonggeun.hong@gmail.com>, RFC Editor <rfc-editor@rfc-editor.org>, 6lo-ads@ietf.org, 6lo-chairs@ietf.org, Shwetha <shwetha.bhandari@gmail.com>, Erik Kline <ek.ietf@gmail.com>, auth48archive@rfc-editor.org, "Chakrabarti, Samita" <samita.chakrabarti@verizon.com>
Content-Type: multipart/alternative; boundary="000000000000c0033b0604a2e31c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/V7eDzUfYIp4kDWYCD7WbqChEh-A>
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: Tue, 05 Sep 2023 20:58:38 -0000
Hi Sandy, Sorry, I missed the messages earlier. Now adding my work email to the distribution list. I am fine with the document. A few changes regarding my information. At the very end: Samita Chakrabarti Bedminster, NJ USA Email: samita.chakrabarti@verizon.com And my affiliation is Verizon. Thanks, -Samita On Tue, Sep 5, 2023, 12:54 PM Sandy Ginoza <sginoza@amsl.com> wrote: > Hi Samita, > > We do not believe we have heard from you regarding this document’s > readiness for publication. Please review the files at the URLs below and > let us know if any updates are needed or if you approve the RFC for > publication. Please let us know if you would like to update your > affiliation and contact information. > > Thank you, > RFC Editor/sg > > > > > On Sep 1, 2023, at 8:26 AM, Sandy Ginoza <sginoza@amsl.com> wrote: > > > > Hi Carles, Rashid, > > > > Thank you for your reviews. We have updated the document as described > by Carles and posted the revised files 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 updates described below only: > > https://www.rfc-editor.org/authors/rfc9453-lastdiff.html > > https://www.rfc-editor.org/authors/rfc9453-lastrfcdiff.html > > > > AUTH48 diff: > > 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 > > > > > > We have marked both of your approvals on the AUTH48 page < > https://www.rfc-editor.org/auth48/rfc9453>. We will wait to hear from > Samita Chakrabarti before continuing with the process. > > > > Thank you, > > RFC Editor/sg > > > > > > > > > > > > > >> On Aug 31, 2023, at 10:53 PM, Carles Gomez Montenegro < > carles.gomez@upc.edu> wrote: > >> > >> Dear Sandy, all, > >> > >> Many thanks for the editorial work done. > >> > >> I have two update requests, as shown below. > >> > >> > >> 1. In the Acknowledgments section, first paragraph: > >> > >> OLD: > >> 2017 through grant SGR 376. > >> > >> NEW: > >> through grants 2017 SGR 376 and 2021 SGR 00330. > >> > >> > >> 2. In the Authors' Addresses section: > >> > >> OLD: > >> Universitat Politecnica de Catalunya/Fundacio i2cat > >> > >> NEW: > >> Universitat Politecnica de Catalunya > >> > >> Other than the above, I approve the RFC for publication. > >> > >> Once again, many thanks. > >> > >> Best regards, > >> > >> Carles Gomez > >> > >> On Fri, 1 Sept 2023 at 07:00, Rashid Sangi <sangi_bahrian@yahoo.com> > wrote: > >>> > >>> Dear all, > >>> > >>> Thank you for your efforts. > >>> > >>> There is no update request from my side. > >>> > >>> Regards, > >>> Rashid Sangi > >>> > >>> On Friday, September 1, 2023 at 12:42:59 PM GMT+8, Sandy Ginoza < > sginoza@amsl.com> wrote: > >>> > >>> > >>> Greetings Younghwan Choi and Yong-Geun, > >>> > >>> Thank you for your review. We have noted your approvals on the AUTH48 > page <https://www.rfc-editor.org/auth48/rfc9453>. > >>> > >>> We will wait to hear from each of your coauthors before continuing > with the publication process. In particular, we will confirm Samita's > affiliation prior to publication. > >>> > >>> Thank you, > >>> RFC Editor/sg > >>> > >>> > >>> > >>>> On Aug 31, 2023, at 9:17 PM, 최영환 <yhc@etri.re.kr> wrote: > >>>> > >>>> Dear Sandy Ginoza and Yong-Geun, > >>>> > >>>> I am Younghwan Choi, who is one of the authors. > >>>> I have no comments on the updates. > >>>> > >>>> Many thanks. > >>>> > >>>> Best Regards, > >>>> Younghwan Choi > >>>> > >>>> ----------------------------------- > >>>> YOUNGHWAN CHOI, Ph.D. > >>>> Principal Researcher, PEC, ETRI > >>>> Tel +82-42-860-1429 Fax +82-42-860-5404 > >>>> Email yhc@etri.re.kr > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: "Yong-Geun Hong" <yonggeun.hong@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>; > >>>> Sent: 2023-09-01 (금) 10:02:17 (UTC+09:00) > >>>> Subject: Re: AUTH48: RFC-to-be 9453 <draft-ietf-6lo-use-cases-16> for > your review > >>>> > >>>> 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