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

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

Dears.

I agree with all the modifications and approve this RFC for publication.

Thanks for your efforts.

Yong-Geun.


2023년 7월 1일 (토) 오전 3:17, Madison Church <[e-mail]>님이 작성:

> Hi Younghwan,
>
> Thank you for your reply. We have marked your approval on the AUTH48
> status page for this document (see
> https://www.rfc-editor.org/auth48/rfc9428).
>
> We will await approvals from each author listed at the AUTH48 status page
> prior to moving this document forward in the publication process.
>
> Thank you!
> RFC Editor/mc
>
> > On Jun 30, 2023, at 1:12 AM, 최영환 <[e-mail]> wrote:
> >
> > Dear Madison,
> >
> > I've reviewed the final version of the draft.
> > I've no more comment on that.
> >
> > Many thanks.
> >
> > Best regards,
> > Younghwan Choi
> >
> > -----------------------------------------------
> > YOUNGHWAN CHOI, Ph.D.
> >
> > Principal Researcher, PEC, ETRI
> > Tel [phone]   Fax [phone]
> > Email  [e-mail]
> >
> > -----Original Message-----
> > From:  "Madison Church" <[e-mail]>
> > To:     "최영환" <[e-mail]>;  "Yong-Geun Hong" <
> [e-mail]>;  "#윤주상 교수" <[e-mail]>;
> > Cc:     "rfc-editor" <[e-mail]>;   <[e-mail]>;
>  <[e-mail]>;   <[e-mail]>;  "Erik Kline" <
> [e-mail]>;   <[e-mail]>;
> > Sent:  2023-06-28 (수) 02:30:17 (UTC+09:00)
> > Subject: Re: AUTH48: RFC-to-be 9428 <draft-ietf-6lo-nfc-22> for your
> review
> >
> > Hi Younghwan,
> >
> > Thank you for your reply. We have updated the document accordingly. All
> of our questions have now been addressed.
> >
> > Please review the document carefully to ensure satisfaction as we do not
> make changes once it has been published as an RFC. Contact us with any
> further updates or with your approval of the document in its current form.
> We will await approvals from each author prior to moving forward in the
> publication process.
> >
> > Updated XML file:
> >  https://www.rfc-editor.org/authors/rfc9428.xml
> >
> > Updated output files:
> >  https://www.rfc-editor.org/authors/rfc9428.html
> >  https://www.rfc-editor.org/authors/rfc9428.txt
> >  https://www.rfc-editor.org/authors/rfc9428.pdf
> >
> > Diff file showing all changes made during AUTH48:
> >  https://www.rfc-editor.org/authors/rfc9428-auth48diff.html
> >
> > Diff files showing all changes:
> >  https://www.rfc-editor.org/authors/rfc9428-diff.html
> >  https://www.rfc-editor.org/authors/rfc9428-rfcdiff.html (side-by-side
> diff)
> >
> > Note that it may be necessary for you to refresh your browser to view
> the most recent version.
> >
> > For the AUTH48 status of this document, please see:
> >  https://www.rfc-editor.org/auth48/rfc9428
> >
> > Thank you!
> > RFC Editor/mc
> >
> >> On Jun 25, 2023, at 9:55 PM, 최영환 <[e-mail]> wrote:
> >>
> >> Dear Madison Church,
> >>
> >> Many thanks for your feedback and the updates.
> >> Please find the answers the followup questions inline bellows:
> >>
> >> B.rgds,
> >> Younghwan
> >>
> >> -----------------------------------------------
> >> YOUNGHWAN CHOI, Ph.D.
> >>
> >> Principal Researcher, PEC, ETRI
> >> Tel [phone]   Fax [phone]
> >> Email  [e-mail]
> >>
> >>> 2023. 6. 24. 오전 4:10, Madison Church <[e-mail]> 작성:
> >>>
> >>> Hi Younghwan and Yong-Geun,
> >>>
> >>> Thank you for your replies. We have updated the document accordingly
> (see list of updated files below). We also have a few followup questions:
> >>>
> >>> 1)
> >>>> 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.
> >>>
> >>> Per your reply, we did not make any changes. However, we note that the
> following forms appear in the document:
> >>>
> >>> Information Field
> >>> information field
> >>>
> >>> May we update all instances to “Information field” (with “Information”
> capped and “field” lowercase)? Or do you prefer a different form?
> >>
> >> I prefer “Information field” (with “Information” capped and “field”
> lowercase) as your proposal.
> >>
> >>>
> >>>
> >>> 2)
> >>>> 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.
> >>>
> >>> We added [RFC8025] to the Reference column in Table 1. We also added a
> corresponding reference entry for RFC 8025 in the Informative References
> section. Please let us know if it should be placed in the Normative
> References instead.
> >>>
> >>
> >> I think it should be placed in the Normative References rather than the
> Informative References.
> >>
> >>>
> >>> 3)
> >>>> 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.
> >>>
> >>> For terms like this, we typically use the open form (no hyphens) for
> the noun and the hyphenated form when used in the attributive position
> (before a noun). We updated this document accordingly. Is "IPv6-over-NFC”
> (with hyphens) considered a term of art that should always appear with
> hyphens? If so, we will update the noun form to also use hyphenation.
> >>>
> >>
> >> I am sorry to make you confused because of the previous answer.
> >>
> >> As you mentioned, I agree with the use of the open form (no hyphens) is
> typically right for nouns, and I agree with use of the hyphenated form when
> used in the attributive position (before a noun). There are 26 nouns of
> “IPv6 over NFC” and 7 uses in the attributive position (like “IPv6-over-NFC
> ~~”). All of your updates are OK currently for me.
> >>
> >>>
> >>> 4)
> >>>> 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.
> >>>
> >>> We capitalized “adaptation layer” in the context of "IPv6-over-NFC
> Adaptation Layer” and "Adaptation Layer for IPv6 over NFC”, but we used
> lowercase for the term otherwise. Please review and let us know if any
> further updates are needed.
> >>
> >> Your proposal and updates are OK for me, and I don’t think I need any
> more further updates.
> >>
> >>>
> >>> _____________
> >>>
> >>> Updated XML file:
> >>> https://www.rfc-editor.org/authors/rfc9428.xml
> >>>
> >>> Updated output files:
> >>> https://www.rfc-editor.org/authors/rfc9428.txt
> >>> https://www.rfc-editor.org/authors/rfc9428.pdf
> >>> https://www.rfc-editor.org/authors/rfc9428.html
> >>>
> >>> Diff file showing all changes made during AUTH48:
> >>> https://www.rfc-editor.org/authors/rfc9428-auth48diff.html
> >>>
> >>> Diff files showing all changes:
> >>> https://www.rfc-editor.org/authors/rfc9428-diff.html
> >>> https://www.rfc-editor.org/authors/rfc9428-rfcdiff.html(side-by-side
> diff)
> >>>
> >>> Note that it may be necessary for you to refresh your browser to view
> the most recent version.
> >>>
> >>> Please review the document carefully to ensure satisfaction as we do
> not make changes once it has been published as an RFC. Contact us with any
> further updates or with your approval of the document in its current form.
> We will await approvals from each author prior to moving forward in the
> publication process.
> >>>
> >>> For the AUTH48 status of this document, please see:
> >>> https://www.rfc-editor.org/auth48/rfc9428
> >>>
> >>> Thank you,
> >>> RFC Editor/mc
> >>>
> >>>> On Jun 20, 2023, at 7:00 PM, Yong-Geun Hong <[e-mail]>
> wrote:
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
>
>