Opsdir last call review of draft-ietf-6lo-nfc-12

[Qin Wu <[e-mail]>]

Reviewer: Qin Wu
Review result: Has Nits

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