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

[Yong-Geun Hong <[e-mail]>]

Dears.

I agreed with the proposal of RFC Editor and Younghwan's modification.

Best regards.

Yong-Geun

2023년 6월 20일 (화) 오전 10:15, 최영환 <[e-mail]>님이 작성:

> Dear RFC Editor,
>
> Many thanks for your review.
> Your review is perfect to me, and every changes you recommend is OK.
>
> Please find my answer inline bellows:
>
> Best regards,
> Younghwan
>
> -----Original Message-----
> From:  "" <[e-mail]>
> To:      <[e-mail]>;   <[e-mail]>;   <
> [e-mail]>;
> Cc:      <[e-mail]>;   <[e-mail]>;   <
> [e-mail]>;   <[e-mail]>;   <[e-mail]>;
>  <[e-mail]>;
> Sent:  2023-06-13 (화) 12:27:49 (UTC+09:00)
> Subject: Re: AUTH48: RFC-to-be 9428 <draft-ietf-6lo-nfc-22> 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] Please insert any keywords (beyond those that appear in the
> title) for use on https://www.rfc-editor.org/search. -->
>
> >> There are 7 keywords such as
>
>                 "Near Field Communication",
>                 "NFC",
>                 "6LowPAN",
>                 "IPv6",
>                 "Adaptation Layer",
>                 "IoT", and
>                 "Internet of Things".
>
>
>
> 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.
> -->
>
> >> Your suggestion in "Perhaps" is OK.
>
>
>
> 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. -->
>
> >> Your suggestion in "Perhaps" is OK.
>
>
>
> 4) <!-- [rfced] We have a few questions regarding expansions.
>
> a) Is "RF" the expansion of "radio frequency" in this context?
>
> >> It is right.
>
> 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.
>
> >> Your suggestion in "Perhaps" is OK.
>
>
>
> 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.
>
> >> "I" means "information", but I prefer "Original" text to your
> suggestion in order to avoid a kinds of confusion.
>
>
>
> 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. -->
>
> >> It looks prefect to me.
>
>
>
> 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.
> -->
>
> >> The "value" should be plural, so revised texts should be like following
> (NEW).
> >> NEW:
>    The LLCP to IPv6 protocol
>    binding MUST transfer the Source Service Access Point (SSAP) and
>    Destination Service Access Point (DSAP) values 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. -->
>
> >> Your suggestion in "Perhaps" is OK.
>
>
>
>
> 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]. -->
>
> >> Your suggestion in "Current" is OK.
>
>
>
>
> 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.
> -->
>
> >> Your suggestion in "Suggested" is OK.
>
>
>
>
> 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. -->
>
> >> Your suggestion in "Current" is OK.
>
>
>
>
> 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. -->
>
> >> Your suggestion in "Perhaps" is OK.
>
>
>
>
> 11) <!-- [rfced] The IANA entry for LOWPAN_IPHC includes references to
> both
> [RFC6282] and [RFC8025].  Should these both be listed in Table 1?
>
> >> Yes, there two references should be listed in the 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].
>
> -->
>
> >> I have checked your updated texts in "Diff file of the text". Your
> updated texts are OK.
>
>
>
>
> 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>.
>
> >> Your suggestion in "Current" is OK.
>
>
>
>
>
> 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>.
> -->
>
> >> Your suggestion in "Current" is OK.
>
>
>
>
>
> 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.
>
> >> Only the "IPv6-over-NFC" is OK throughout the text.
>
>
>
>
> 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.
>
> >> Your suggestion in "Perhaps" is OK, and the "value" should be plural in
> the sentence.
>
>
>
>
> 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"?
>
> -->
>
> >> The "adaptation layer" should be capitalized as well.
>
>
>
>
> 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. -->
>
> >> I prefer using "man-in-the-middle" in the text because this document
> refer to the terms used in [LLCP-1.4] specification.
>
> 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
>
>
>
>