Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6lo-use-cases-16> for your review
Yong-Geun Hong <yonggeun.hong@gmail.com> Thu, 24 August 2023 00:53 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 3EF3CC17CEA9; Wed, 23 Aug 2023 17:53:17 -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_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=ham 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 Ht4dP7k7U_CD; Wed, 23 Aug 2023 17:53:12 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 21B7EC17CEAA; Wed, 23 Aug 2023 17:53:12 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5008c19d97fso864224e87.1; Wed, 23 Aug 2023 17:53:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692838390; x=1693443190; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KrOmu7VAQYXE6xWy6Vyf9/iS3Ax/1Z+DfL8HWzES1hg=; b=GJT1vHcT3Sxm2brxQNLBuKvZn0icel+9/4V6pZDAar0f2g17KH3sL+NlKilSR6KrqE EcwSSxrfNqu0zXgDNPXNb1TQnvDKF8gFcnPUoaR7XdPpk9aiw+xKH9yR1NVkeGNraNk1 fXTj9Dgq5HYcUUMMHXtHbG0AO9PctIreyDnFexu8JWps8ZxQrAf0veDUo0nNhX+FEJTV 1n84SKXuKB9YzEVAgf8aU8X+9Z55pqiMcPFAoK9yaSB38Ahz9sRS0SBnBO8czsn4BOm9 E+atMfUZdJxixZ88zDx1/fN1lOOAEGYHk50YwUP2osRJzkPwrKjcVOQ2el8cPcPzjkYB xIvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692838390; x=1693443190; 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=KrOmu7VAQYXE6xWy6Vyf9/iS3Ax/1Z+DfL8HWzES1hg=; b=crtduJO4oryVhcBeqGnFxOvh37dT74NC2fMTM0NulBNVmhQnz8gNFHZ+Hwg3Hvv7vp KnRgqfxygfmvhQ8qIZhdMviwFiRHhikDdkVrZXSXVQp+t5HAUjm0jq07L6Ree6jRQzHR 7CBahnIWIQ6+W+poFs6QOBd3V5ooGmWRk+hpMJPO1uSdNyQVm3YkCwYNqqe1G2F7I3Qe vviZG8QYHsxKlQjYFAdjuloPM0U4JWxksuYGxLE0SlZ60RDowG47WO6wJdgPwB6Aqgvj /QlXYQY92PdxYVEQygjdaKw6G4kyjh0lGSJEyrxlXu7TsPFDvKU931720ao6EDhIpzJc q2nA==
X-Gm-Message-State: AOJu0YzxseyWCCUD3XW5ttmVjlSkmDXT3S1rCCJ7SeMraIV4JIJ1D6Zh hnhl8VCi7Z6m7r3F/kq5+Ufo3yfdinBvjCd5orc=
X-Google-Smtp-Source: AGHT+IE7pB7yEaFLE/ZRrNEwV8iLSdsKWDrBHsVzzPY95iyEZQnxZRMpBe/RZBHo1Y5RxPL+BIG2ml8qvmq6Ty76NIA=
X-Received: by 2002:a19:f510:0:b0:500:8b8d:d567 with SMTP id j16-20020a19f510000000b005008b8dd567mr5058722lfb.1.1692838389290; Wed, 23 Aug 2023 17:53:09 -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>
In-Reply-To: <0BAA6F3B-0664-4757-A73A-D1D78B164A51@amsl.com>
From: Yong-Geun Hong <yonggeun.hong@gmail.com>
Date: Thu, 24 Aug 2023 09:52:57 +0900
Message-ID: <CACt2foFgXX9g-cu=K1t73DvPVX0DGWUkN1mZuBG4ke_ffZ+4RQ@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="000000000000db1c480603a0a678"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/zoW42iEMsqqHAdnRedfp4U89OEk>
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: Thu, 24 Aug 2023 00:53:17 -0000
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