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. Summary: 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 s/UI PDU/U-PDU s/I PDU/I-PDU 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 functionality. +------------+--------------------+-----------+ | 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