Last Call Review of draft-ietf-6lo-nfc-12

Request Review of draft-ietf-6lo-nfc
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-12-24
Requested 2018-12-10
Authors Younghwan Choi, Yong-Geun Hong, Joo-Sang Youn, Dongkyun Kim, JinHyeock Choi
Draft last updated 2018-12-19
Completed reviews Intdir Early review of -10 by Sheng Jiang (diff)
Iotdir Early review of -10 by Brian Haberman (diff)
Tsvart Last Call review of -12 by Wesley Eddy (diff)
Opsdir Last Call review of -12 by Qin Wu (diff)
Secdir Last Call review of -13 by Leif Johansson (diff)
Genart Last Call review of -12 by Jari Arkko (diff)
Assignment Reviewer Qin Wu
State Completed
Review review-ietf-6lo-nfc-12-opsdir-lc-wu-2018-12-19
Reviewed rev. 12 (document currently at 17)
Review result Has Nits
Review completed: 2018-12-19


I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Near field communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm. This document describes how IPv6 is transmitted over NFC using 6LowPAN techniques. I have review this document and believe it is ready for publication, but with a few nits:
1. Section 3.1
This paragraph seems not complete, since NFC enabled device support card emulation, peer to peer, and reader/writer three modes, what’s their difference?
2. Please create terminology section and define all the terms such as SSAP and DSAP, LLCP, 6LBR, 6LN, 6LR in the terminology section, for reader who are not familiar with 6lowpan technique, it is hard to follow these terms, especially you use a lot of abbreviations in the document.
3. Section 3.2
How does Logical Link Control (LLC) and MAC Mapping  is related to unicast and multicast mapping in section 4.9?
4. Section 3.3
Why there is no IANA consideration for these address value ranges registering?
5. Section 3.4
6. 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?
7. Section 4.2
Suggest to move last paragraph to a sub-section 4.2.1 to discuss limitation of link model
8. Section 4.6 said
“   The dispatch value may be treated as an unstructured namespace.  Only
   a single pattern is used to represent current IPv6-over-NFC

              |  Pattern   | Header Type        | Reference |
              | 01  1xxxxx | 6LOWPAN_IPHC       | [RFC6282] |

                         Figure 7: Dispatch Values
It is not clear the length of IPHC Dispatch and the length of IPHC header? How single patter and dispatch value is formatted in the IPHC Dispatch?

9. Section 4.8
Suggest to change title into “Fragmentation and Reassembly  consideration”, since in the section 3.2, LLCP doesn’t support Fragmentation and Reassembly , in section 4.2, L2CAP support fragmentation and reassembly, looking at the title ofsection 4.8, it seems Fragmentation and Reassembly  is always supported which not true.
10. Section 4.9
The title is not consistent with text in the section 4.9, The title is unicast and multicast address mapping, it is not clear whether there is any multicast can be mapped into link layer unicast address since link layer address doesn’t support multicast based on last paragraph of section 4.9