Transmission of IPv6 Packets over Near Field Communication
draft-ietf-6lo-nfc-22

Thank you for addressing my DISCUSS.

Only a nit to point out beyond the thorough treatment already provided by others:

Section 4.7, typo: "IIPv6-over-NFC"

I support Roman's DISCUSS and COMMENTS.

Thanks for addressing my DISCUSS feedback.

** Section 3.4.  Most of these normative statement appear to be restatements of Section 4.5.2 of NFC Forum’s LLCP version 1.4.  The style of this document seems to be specifying behavior that is in fact already specified authoritatively elsewhere.

** Section 7.
   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).

-- This entire text is cut-and-paste from Section 3.2.5 of NFC Forum LLC.  Given that this text is used verbatim shouldn’t it be cited?

-- If the text is going to be restated, in the spirit of inclusive language, please consider alternative language to “MiTM”.

I apologize - I've read the document, but it doesn't seem like it contains enough information to allow a full implementation.

The document keeps talking about the fact that the range is limited to 10cm, and makes some security assertions from this - from the little that I understand about this technology (and I wasn't able to follow all the references), ISO 15693 tags using NDEF are now part of the NFC specification - these  work up to 1M. I have no idea if this protocol is supposed to work over that, but if so, 1M is greater than 10cm.

Also, I see you did respond to the OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-6lo-nfc-12-opsdir-lc-wu-2018-12-19/ -- thank you very much, Qin) , but there are things in these which don't seem fully addressed. As an example, Qin asked:
----
 Section 3.4 said ” the MTU size in NFC LLCP MUST be calculated from the MIU
   value as follows:
                             MIU = 128 + MIUX.”
Can you provide formula to calculate MTU from MIU? Not clear how MTU is related to MIU? 
---

You responded: "YH >> Actually, MIU is the same as MTU. Specifications in NFC forum use 'MIU', and we use 'MTU'. But these two has the same meaning."

I read version 13 of this document and had the exact same question -- how do I calculate the MTU from the MIU? If they really are the same thing (which I'm not sure they are), the document should state that, so readers can more easily implement.

Thanks for addressing the TSVART review comments and my discuss.

Thanks for addressing my previous DISCUSS & COMMENT issues (https://mailarchive.ietf.org/arch/msg/6lo/plJVoupDzqryxS93tYY8Wbyr5-8/ ).

Thanks as well for the hard work.

Regards

-éric

Thanks for addressing my DISCUSS point.

I agree with Benjamin about antenna size. Despite that I have enjoyed reading this document. I have some questions/comments that I would like to discuss before recommending publication of this document as an RFC:

In 3.2:

   The LLCP consists of Logical Link Control (LLC) and MAC Mapping.  The
   MAC Mapping integrates an existing RF protocol into the LLCP
   architecture.  The LLC contains three components, such as Link
   Management, Connection-oriented Transmission, and Connection-less
   Transmission.  The Link Management component is responsible for
   serializing all connection-oriented and connection-less LLC PDU
   (Protocol Data Unit) exchanges and for aggregation and disaggregation
   of small PDUs.  This component also guarantees asynchronous balanced
   mode communication and provides link status supervision by performing
   the symmetry procedure.

Can you translate the last sentence for somebody who is not an expert in this?

In 4.4:

   The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC
   network is can be accomplished via DHCPv6 Prefix Delegation

I think "is" before "can be" should be deleted above.

   ([RFC3633]).

In 4.5:

   o  When two or more NFC 6LNs(or 6LRs) meet, there are two cases.  One
      is that three or more NFC devices are linked with multi-hop
      connections, and the other is that they meet within a single hop
      range (e.g., isolated network).  In a case of multi-hops, all of
      6LNs, which have two or more connections with different neighbors,
      MAY be a router for 6LR/6LBR.  In a case that they meet within a
      single hop and they have the same properties, any of them can be a
      router.  When the NFC nodes are not of uniform category (e.g.,
      different MTU, level of remaining energy, connectivity, etc.), a
      performance-outstanding device can become a router.

The last sentence: how can 2 NFC nodes figure out which one has higher level or remaining energy, etc?

In 4.7:

   Therefore, IPv6 header compression in [RFC6282] MUST be implemented.
   Further, implementations MAY also support Generic Header Compression
   (GHC) of [RFC7400].

Will 2 NFC implementations interoperate if one of them supports GHC and the other one doesn't?
If they can't, then "MAY" seems to be too weak here.


In 4.8:

   IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is
   NOT RECOMMENDED in this document as discussed in Section 3.4.

You are using "NOT RECOMMENDED", which is "SHOULD NOT". Why is this not a "MUST NOT" and why implementation of FAR would be Ok if one node supports it and another one doesn't?

Thanks for addressing my DISCUSS points. Original COMMENT below:

= General =

I agree with Benjamin that the marketing-type language in the document should be removed.

I wonder about the claims of security based on proximity in this document. Presumably attacks in which users are induced to tap their device against another node or terminal which has been compromised by an attacker are becoming more common as NFC becomes more common; adding IPV6 connectivity to the terminal stack surely broadens the potential damage done in such a case. This seems worth noting.

= Section 1 =

OLD
It has been used in devices such as mobile phones, running Android operating
   system, named with a feature called "Android Beam".  In addition, it
   is expected for the other mobile phones, running the other operating
   systems (e.g., iOS, etc.) to be equipped with NFC technology in the
   near future.

NEW
At the time of this writing, it had been used in devices such as mobile phones, running Android operating
   system, named with a feature called "Android Beam".  It was expected for the other mobile phones, running the other operating
   systems (e.g., iOS, etc.) to be equipped with NFC technology in the
   near future.

= Section 4.5 =

Per the Gen-ART review, the use of the term "meet" is confusing in this section. Please re-phrase.

# GEN AD review of draft-ietf-6lo-nfc-19

CC @larseggert

## Comments

Thanks for making the LLCP-1.4 spec available to the IESG.

### Section 3.4, paragraph 7
```
     When the MIUX parameter is used, the TLV Type field MUST be 0x02 and
     the TLV Length field MUST be 0x02.  The MIUX parameter MUST be
     encoded into the least significant 11 bits of the TLV Value field.
     The unused bits in the TLV Value field MUST be set to zero by the
     sender and ignored by the receiver.
```
Figure 2 shows that the V field is split into 4 bits and 12 bits, not
11? Also, the four bits are not zero?

### DOWNREFs

DOWNREF `[RFC3756]` from this Proposed Standard to Informational `RFC3756`.
(For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call
and also seems to not appear in the DOWNREF registry.)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `man`; alternatives might be `individual`, `people`, `person`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.1, paragraph 1
```
-    is used for IPv6 over NFC.
-    ^^
+    MUST be used for IPv6 over NFC.
+    ^^^^^^^
```

### Outdated references

Reference `[RFC3633]` to `RFC3633`, which was obsoleted by `RFC8415` (this may
be on purpose).

### Grammar/style

#### Section 4.2, paragraph 4
```
pology. NFC supports mesh topologies but most of all applications would use a
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

1) I agree with Benjamin's discuss point on sec 3.4: there seems to be a mismatch between the text and the figure that needs to be resolved or clarified before publication.

2)Use of normative language doesn't always seem quite appropriate, especially SHALL. Benjamin already identified some cases in section 3.3. 

Here is an additional one in sec 4.1:
"The adaptation layer for IPv6 over NFC SHALL support neighbor
   discovery, stateless address auto-configuration, header compression,
   and fragmentation & reassembly."

Also this MAY in sec 5.2:
"In an isolated NFC-enabled device network,
   when two or more LRs MAY be connected with each other, and then they
   are acting like routers, the 6LR MUST ensure address collisions do
   not occur."

Please also check other occurrences.

3) I would have expected to see some discussion about the ability to potentially connect devices over an IP-gateway device to the Internet that were previously not designed to be connected to the Internet. However, maybe that's asked too much as that is certainly something that needs to be addressed by either a higher layer or the device system architecture as a whole.

I support Alissa's second Discuss point about the plan for fragmentation interoperation, and her third Discuss point about connecting unsuspecting devices to the Internet :-) 

Other people have said this, but requiring MIUX would be awesome.