Re: [auth48] AUTH48: RFC-to-be 9428 <draft-ietf-6lo-nfc-22> for your review

[Madison Church <[e-mail]>]

Hi authors,

This is a friendly reminder that we await answers to the questions below and your review of the document before continuing with the publication process. 

Thank you,
RFC Editor/mc

> On Jun 12, 2023, at 10:27 PM, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) 
> the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on https://www.rfc-editor.org/search. -->
> 
> 
> 2) <!-- [rfced] We are having trouble parsing this sentence.  Please 
> consider whether the suggested update clarifies the text. 
> 
> Original:
>   In order to benefit from Internet connectivity, it is desirable for
>   NFC-enabled devices to support IPv6, considering its large address
>   space, along with tools for unattended operation, among other
>   advantages.
> 
> Perhaps: 
>   In order to benefit from Internet connectivity, it is desirable for
>   NFC-enabled devices to support IPv6 because of its large address space
>   and the availability of tools for unattended operation, along with other
>   advantages.
> -->
> 
> 
> 3) <!-- [rfced] May we rephrase the following text to form a complete 
> sentence?  Please consider whether the suggested update conveys the 
> intended meaning. 
> 
> Original: 
> An IPv6 datagram is transmitted by the Logical Link Control Protocol
> (LLCP) with guaranteed delivery, two-way transmission of information 
> between the peer devices.
> 
> Perhaps: 
> An IPv6 datagram is transmitted by the LLCP with guaranteed delivery
> and two-way transmission of information between the peer devices. -->
> 
> 
> 4) <!-- [rfced] We have a few questions regarding expansions.
> 
> a) Is "RF" the expansion of "radio frequency" in this context?
> 
> Original: 
> The MAC Mapping integrates an existing RF protocol into the LLCP
> architecture.
> 
> Perhaps: 
> The MAC Mapping integrates an existing radio frequency (RF) protocol
> into the LLCP architecture. 
> 
> b) Please confirm that I PDU expands to Information Field in an LLCP 
> Protocol Data Unit.
> 
> Original (from Section 3.2):
>   In order to send an IPv6 packet over NFC, the packet MUST be passed
>   down to the LLCP layer of NFC and carried by an Information Field in 
>   an LLCP Protocol Data Unit (I PDU).
> 
> If this is correct, should "information field" be removed from this 
> sentence in section 3.4 because it's redundant with "I"?
> 
> Original:
>   The information field of an I PDU contains a single service data
>   unit.
> 
> Perhaps:
>   The I PDU contains a single service data
>   unit.
> 
> c) FYI - We have added expansions for abbreviations upon first use
> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> expansion in the document carefully to ensure correctness. -->
> 
> 
> 5) <!-- [rfced] Should "value" be plural?  Is there a value for the Source 
> Service Access Point (SSAP) and another for the Destination Service Access 
> Point (DSAP)?  
> 
> Original:
>   The LLCP to IPv6 protocol                        
>   binding MUST transfer the Source Service Access Point (SSAP) and
>   Destination Service Access Point (DSAP) value to the IPv6 over NFC
>   adaptation layer.
> -->
> 
> 
> 6) <!-- [rfced] May we rephrase the following sentence to limit the use of
> "over"?
> 
> Original: 
> The latter can still be supported over IPv6 over NFC, albeit without
> the performance optimization of header compression.
> 
> Perhaps: 
> The latter can still be supported by IPv6 over NFC, albeit without
> the performance optimization of header compression. -->
> 
> 
> 7) <!-- [rfced] We have rephrased the following text to make the 
> introduction of the abbreviation "RID" more uniform. Please let us know any objections.
> 
> Original:
>   Following the guidance of [RFC7136], interface identifiers of all
>   unicast addresses for NFC-enabled devices are 64 bits long and
>   constructed by using the generation algorithm of random (but stable)
>   identifier (RID) [RFC7217].
> 
> Current:
>   Following the guidance of [RFC7136], IIDs of all
>   unicast addresses for NFC-enabled devices are 64 bits long and
>   constructed by using the generation algorithm of random 
>   identifiers (RIDs) that are stable [RFC7217]. -->
> 
> 
> 8) <!-- [rfced] Please consider whether the following suggested update is 
> correct.
> 
> Original: 
>   NFC supports mesh topologies, but most of all
>   applications would use a simple multi-hop network topology or
>   directly connected peer-to-peer network because NFC RF range is very
>   short. 
> 
> Suggested:
>   NFC supports mesh topologies, but most
>   applications would use a simple multi-hop network topology or
>   be directly connected a peer-to-peer network because the NFC RF 
>   range is very short. 
> -->
> 
> 
> 9) <!-- [rfced] Section 4.4: Is this a sequence of events (that is, they 
> happen in order) or do both occur when an NFC 6LN is directly connected to 
> a 6LBR? 
> 
> Original:
>   *  When an NFC 6LoWPAN Node (6LN) is directly connected to an 6LBR,
>      the 6LN MUST register its address with the 6LBR by sending
>      Neighbor Solicitation (NS) with the Extended Address Registration
>      Option (EARO) [RFC8505], and Neighbor Advertisement (NA) is
>      started. 
> 
> Current:
>      When an NFC 6LN is directly connected to a 6LBR,
>      the 6LN MUST register its address with the 6LBR by sending
>      Neighbor Solicitation (NS) with the Extended Address Registration
>      Option (EARO) [RFC8505]; then Neighbor Advertisement (NA) is 
>      started. -->
> 
> 
> 10) <!-- [rfced] Should "LN" read as "6LN"? There is no usage of "LN" on 
> its own throughout the document.  Or does this refer to LoWPAN? 
> 
> Original: 
> When two or more NFC LNs are connected to the 6LBR, two cases of
> topologies can be formed...In the multi-hop topology, LNs which have two or
> more links with neighbor nodes may act as routers. In star topology, any of
> LNs can be a router.
> 
> Perhaps: 
> When two or more NFC 6LNs are connected to the 6LBR, two cases of
> topologies can be formed... In the multi-hop topology, 6LNs which have two or
> more links with neighbor nodes may act as routers. In star topology, any of
> 6LNs can be a router. -->
> 
> 
> 11) <!-- [rfced] The IANA entry for LOWPAN_IPHC includes references to both 
> [RFC6282] and [RFC8025].  Should these both be listed in Table 1? 
> 
> See https://www.iana.org/assignments/_6lowpan-parameters
> 
> Original (Figure 6) - note that lines have been removed so the text could 
> be included in the XML as comments:: 
> 
>              |  Pattern   | Header Type        | Reference |
>              | 01  1xxxxx | LOWPAN_IPHC        | [RFC6282] |
> 
> -->
> 
> 
> 12) <!-- [rfced] We have updated the text in section 7.  However, it is 
> unclear to us whether the bulleted text is quoted from [LLCP-1.4] because 
> we do not have access to the document.  Please review and let us know if 
> reversions are needed to match what appears in the referenced 
> specification. 
> 
> Original: 
>   Per the NFC Logical Link Control Protocol [LLCP-1.4]:
> 
>   *  LLCP of NFC provides protection of user data to ensure
>      confidentiality of communications.  The confidentiality mechanism
>      involves the encryption of user service data with a secret key
>      that has been established during link activation. 
> 
>   *  LLCP of NFC has two modes (i.e., ad-hoc mode and authenticated 
>      mode) for secure data transfer.  Ad-hoc secure data transfer can
>      be established between two communication parties without any prior
>      knowledge of the communication partner.  Ad-hoc secure data
>      transfer can be vulnerable to Man-In-The-Middle (MITM) attacks.
>      Authenticated secure data transfer provides protection against 
>      Man-In-The-Middle (MITM) attacks.  In the initial bonding step,
>      the two communicating parties store a shared secret along with a 
>      Bonding Identifier.
> 
>   *  For all subsequent interactions, the communicating parties re-use
>      the shared secret and compute only the unique encryption key for
>      that session.  Secure data transfer is based on the cryptographic
>      algorithms defined in the NFC Authentication Protocol [NAP-1.0].               
> -->
> 
> 
> 13) <!-- [rfced] We have updated the following references to more closely 
> align with the information provided at the URL.  In particular, the dates 
> were updated to reflect the noted adoption dates.  Please let us know if 
> any corrections are needed. 
> 
> 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>.
> 
> Current:
>   [LLCP-1.4] NFC Forum, "Logical Link Control Protocol Technical
>              Specification", Version 1.4, December 2022,
>              <https://nfc-forum.org/build/specifications>.
> 
> 
> Original:
> [NAP-1.0]  NFC Forum, "NFC Authentication Protocol Candidate
>           Technical Specification, Version 1.0", NFC Forum Technical
>           Specification , December 2020,
>           <https://nfc-forum.org/build/specifications>.   
> 
> Current: 
>   [NAP-1.0]  NFC Forum, "NFC Authentication Protocol Technical
>              Specification", Verison 1.0, December 2022,
>              <https://nfc-forum.org/build/specifications>.
> -->
> 
> 
> 14) <!-- [rfced] We have a few questions regarding terminology in this 
> document.
> 
> a) Throughout the text, the terms "IPv6 over NFC" and "IPv6-over-NFC" 
> appear to be used inconsistently. We have used the hyphenated form when the 
> "IPv6-over-NFC" modifies the noun that follows.  Please review and let us 
> know if any updates are needed.  
> 
> b) We note that "IPv6-LLCP Binding" is used throughout the document. May we
> replace "LLCP to IPv6 protocol binding" with "IPv6-LLCP Binding" for
> consistency?
> 
> Original:
>   The LLCP to IPv6 protocol
>   binding MUST transfer the Source Service Access Point (SSAP) and
>   Destination Service Access Point (DSAP) value to the IPv6 over NFC
>   adaptation layer.
> 
> Perhaps:
>   IPv6-LLCP Binding MUST transfer the Source Service Access Point (SSAP) 
>   and Destination Service Access Point (DSAP) value to the IPv6-over-NFC
>   adaptation layer. 
> 
> c) We note that "NFC Physical Layer" and "NFC Logical Link Layer" are 
> capitalized consistently throughout the document.  Should "adaptation 
> layer" also be capitalized, for example, IPv6-over-NFC adaptation layer and 
> NFC adaptation layer?  Is "adaptation layer" lowercased when it's part a 
> nickname for "Adaptation Layer for IPv6 over NFC"?
> 
> -->
> 
> 
> 15) <!-- [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
> "man-in-the-middle" should be updated. -->
> 
> 
> Thank you.
> 
> RFC Editor
> 
> 
> 
> On Jun 12, 2023, at 8:23 PM, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2023/06/12
> 
> 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/rfc9428.xml
>   https://www.rfc-editor.org/authors/rfc9428.html
>   https://www.rfc-editor.org/authors/rfc9428.pdf
>   https://www.rfc-editor.org/authors/rfc9428.txt
> 
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9428-diff.html
>   https://www.rfc-editor.org/authors/rfc9428-rfcdiff.html (side by side)
> 
> Diff of the XML: 
>   https://www.rfc-editor.org/authors/rfc9428-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/rfc9428.original.v2v3.xml 
> 
> XMLv3 file that is a best effort to capture v3-related format updates 
> only: 
>   https://www.rfc-editor.org/authors/rfc9428.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9428
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9428 (draft-ietf-6lo-nfc-22)
> 
> Title            : Transmission of IPv6 Packets over Near Field Communication
> Author(s)        : Y. Choi, Ed., Y. Hong, J. Youn
> WG Chair(s)      : Shwetha Bhandari, Carles Gomez
> 
> Area Director(s) : Erik Kline, Éric Vyncke
> 
>