Re: [auth48] AUTH48: RFC-to-be 9453 <draft-ietf-6lo-use-cases-16> for your review

[Sandy Ginoza <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>님이 작성:
> 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 <[e-mail]> wrote:
> > 
> > Dear RFC Editor.
> > 
> > Thanks for your efforts to publish RFC 9453.
> > 
> > I add my response in lines.
> > 
> > Best regards.
> > 
> > Yong-Geun.
> > 
> > 
> > 
> > 
> >> 보낸 사람: [e-mail]
> >> 날짜: 2023년 8월 8일 오후 4시 31분 32초 GMT+9
> >> 받는 사람: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
> >> 참조: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
> >> 제목: 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, [e-mail] 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
> >> 
> >>   *  [e-mail] (the RPC team)
> >> 
> >>   *  other document participants, depending on the stream (e.g., 
> >>      IETF Stream participants are your working group chairs, the 
> >>      responsible ADs, and the document shepherd).
> >> 
> >>   *  [e-mail], which is a new archival mailing list 
> >>      to preserve AUTH48 conversations; it is not an active discussion 
> >>      list:
> >> 
> >>     *  More info:
> >>        https://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, 
> >>        [e-mail] will be re-added to the CC list and 
> >>        its addition will be noted at the top of the message. 
> >> 
> >> You may submit your changes in one of two ways:
> >> 
> >> An update to the provided XML file
> >> — OR —
> >> An explicit list of changes in this format
> >> 
> >> Section # (or indicate Global)
> >> 
> >> OLD:
> >> old text
> >> 
> >> NEW:
> >> new text
> >> 
> >> You do not need to reply with both an updated XML file and an explicit 
> >> list of changes, as either form is sufficient.
> >> 
> >> We will ask a stream manager to review and approve any changes that seem
> >> beyond editorial in nature, e.g., addition of new text, deletion of text, 
> >> and technical changes.  Information about stream managers can be found in 
> >> the FAQ.  Editorial changes do not require approval from a stream manager.
> >> 
> >> 
> >> Approving for publication
> >> --------------------------
> >> 
> >> To approve your RFC for publication, please reply to this email stating
> >> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> >> as all the parties CCed on this message need to see your approval.
> >> 
> >> 
> >> Files 
> >> -----
> >> 
> >> The files are available here:
> >>   https://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>
>