Dear Qin Wu,
Thanks for your comments.
Please find the answers inline bellows:
Best regards,
Younghwan Choi
-----Original Message-----
From: Qin Wu <bill.wu@xxxxxxxxxx>
Sent: Thursday, December 20, 2018 10:20 AM
To: ops-dir@xxxxxxxx
Cc: draft-ietf-6lo-nfc.all@xxxxxxxx; ietf@xxxxxxxx; 6lo@xxxxxxxx
Subject: Opsdir last call review of draft-ietf-6lo-nfc-12
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?
YH >> section 3.1 describes 3 modes of NFC. In the 3 modes, only peer-to-peer mode can support ipv6-over-nfc. peer-to-peer is for directional communications, the other is for rfid tag reader/writer and credit card emulation. I think that "only peer-to-peer mode can support ipv6-over-nfc" should be added in section 3.1 for clarification.
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.
YH >> It is a good idea, but those are new key words which are not defined in this document. Thus, I put references for all of them. I will think of which way is the best.
3. Section 3.2 How does Logical Link Control (LLC) and MAC Mapping is related to unicast and multicast mapping in section 4.9?
YH >> LLC makes a 5-bit address of link layer, and the link layer address is related to the unicast and multicast mapping in section 4.9.
4. Section 3.3 Why there is no IANA consideration for these address value ranges registering?
YH >> Regarding to RFC8126 (Guidelines for Writing an IANA Considerations Section in RFCs), I think there is no constants to identify various protocol parameters in this document.
5. Section 3.4 s/UI PDU/U-PDU s/I PDU/I-PDU
YH >> "UI PDU" and "I PDU" are just defined by NFC forum, I think I cannot change them with the other way..
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?
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.
7. Section 4.2 Suggest to move last paragraph to a sub-section 4.2.1 to
discuss limitation of link model
YH >> That’s one of good suggestions. If so, section 4.2 has just one sub-section only. I am not sure it is the best way or not.
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?
YH >> I would like to ask what is not clear in this section. I need more explanations from you about this. This is one of the ipv6-over-foo documents, and the other documents have the same issue with this.
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 of section 4.8, it seems Fragmentation and Reassembly is always supported which not true.
YH >> I agree with your suggestion. I will reflect it.
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
YH >> This is a good point. I agree with your suggestion, but I think the last paragraph about "not support multicast" in section 4.9 is important point in this document. Thus, the title needs to be keep as it is or changed to "4.9 Unicast Address Mapping and Multicast Address Mapping". all of ipv6-over-foo documents deals with this issues. I think I don't need to get rids of "multicast" in the title.
