[6lo] Review of draft-ietf-6lo-nfc-16

[Carles Gomez Montenegro <[e-mail]>]

Dear authors of draft-ietf-6lo-nfc,

Thanks for updating the draft and producing revision -16.

In my opinion, the document has improved. I checked the document again,
and I have another round of comments. Perhaps just one more iteration to
address this round of comments might suffice to proceed to the next step.

Please find below my comments on -16.

Cheers,

Carles (shepherd of draft-ietf-6lo-nfc)

---------------------------------------------------------------------------


1.- Section 3.1, 2nd line: s/enables/allows (this is to avoid repeating
the same term so quickly in the text).

2.- Section 3.1, 1st paragraph:

CURRENT:
information and share files, so that users of NFC-enabled devices can
quickly share contact information and other files with a touch. The other
two modes does not support two-way communications between two devices.
Therefore, the peer mode is used for ipv6-over-nfc.

PROPOSED:
information bidirectionally. The other two modes do not support two-way
communications between two devices. Therefore, the peer-to-peer mode is
used for IPv6 over NFC.

3.- Section 3.2 title: s/Stacks/Stack

4.- Section 3.2, 1st paragraph:

CURRENT:
The peer-to-peer mode is made in Activities Digital Protocol in NFC
Physical Lay. The NFC Logical Link consists of

PROPOSED:
The peer-to-peer mode is offered by the Activities Digital Protocol at the
NFC Physical Layer. The NFC Logical Link Layer consists of

5.- Section 3.2, 2nd sentence: does this sentence apply always, or only
when IPv6 is used over NFC?  If the latter, then some proposed text is as
follows:
"The NFC Logical Link Layer comprises the Logical Link Control Protocol
(LLCP), and when IPv6 is used over NFC, it also includes an IPv6-LLCP
Binding"

6.- Section 3.2, 2nd paragraph. Please stick to one term for the whole
document ("Connection-less" and "Connectionless" are both used in the
paragraph).

7.- Section 3.2, last paragraph, 2nd sentence:

   s/LLCP/The LLCP  (first "LLCP" instance)
   s/LLCP/the LLCP  (second "LLCP" instance)

8.- Section 3.2, last paragraph:

CURRENT:
The LLCP to IPv6 protocol binding MUST transfer the SSAP and DSAP value to
the IPv6 over NFC protocol. SSAP stands for Source Service Access Point,
which is a 6-bit value meaning a kind of Logical Link Control (LLC)
address

PROPOSED:
The LLCP to IPv6 protocol binding MUST transfer the Source Service Access
Point (SSAP) and Destination Service Access Point (DSAP) value
to the IPv6 over NFC protocol. SSAP is a Logical Link Control (LLC)
address of the source NFC-enabled device with a size of 6 bits.

9.- Section 3.3: s/Logical Link Control Protocol/LLCP

10.- Section 3.4, 1st paragraph: there may be a bit of confusion regarding
the concepts of I PDU and UI PDU. In previous sections, there seem to be
the I field of a PDU and the UI field of a PDU. However, it seems like now
there is a definition of two different types of PDUs (I PDU and UI PDU).
Are
"I PDU" and "UI PDU" different and exclusive types of PDU? Can a given PDU
carry an I field and a UI field?

Clarifications are needed regarding these terms.

11.- Section 3.4, 2nd paragraph. Only "I PDU" is mentioned here. What
about UI PDUs?

12.- Section 3.4, last paragraph. If the maximum possible value of the TLV
Value field is 0x7FF, wouldn't the maximum possible value of the LLCP MTU
be 2175 bytes instead of 2176?

13.- Section 3.4, last paragraph:

CURRENT:
If fragmentation functionality is not used at the
adaptation layer between IPv6 and NFC, the MIUX value MUST be 0x480 to
support the IPv6 MTU requirement (of 1280 bytes).

PROPOSED:
The MIUX value MUST be 0x480 to support the IPv6 MTU requirement (of 1280
bytes).

14.- Section 4, 1st paragraph:
CURRENT:
NFC technology also has considerations and requirements

PROPOSED:
NFC technology has requirements

15.- Section 4, 1st paragraph:
CURRENT:
reducing overhead which can be applied to NFC

PROPOSED:
reducing the overhead of IPv6 over NFC

16.- Section 4, 1st paragraph: s/see Section 4.2/see Section 4.2 and
Section 4.3.

17.- Section 4.1 title: s/Stacks/Stack

18.- Section 4.1: s/Figure 3 illustrates IPv6 over NFC/Figure 3
illustrates the IPv6 over NFC protocol stack

19.- Figure 3. (Just a suggestion.) Perhaps close the upper part of the
figure, i.e. adding a horizontal line closing the box for "Upper Layer
Protocols"?

20.- Figure 3: in Figure 1 there is the term "NFC Logical Link Layer". Is
this the same as "NFC Link Layer"? If yes, please stick to the same term
in both figures.

21.- Section 4.2, 3rd paragraph: s/the algorithm, F()/the F() algorithm

22.- Section 4.2, 3rd paragraph: s/easy and short/short and easy

23.- Section 4.2, 3rd paragraph: s/The F() can provide/The F() algorithm
can provide

24.- Section 4.3, 1st sentence: s/appending the IID, to/appending the IID to

25.- Section 4.3, last sentence: s/IIDs/IID
26.- Section 4.4. When mentioning RFC 6775, you may probably want to cite
RFC 8505. Likewise, the ARO is now an Extended Address Registration Option
(EARO), as per RFC 8505.

27.- Section 4.4, 2nd bullet: remove "(e.g., isolated network)". Note that
two NFC devices might still talk to each other (point-to-point topology),
but one of them may be connected to the Internet.

28.- Section 4.4, 2nd bullet: s / play a router for 6LR/6LBR / may act as
routers

29.- Section 4.5, 1st paragraph: s/6LoWPAN_IPHC/LOWPAN_IPHC compressed
IPv6 header (see section 4.6)

30.- Section 4.7:

CURRENT:
IPv6-over-NFC SHOULD NOT use fragmentation and reassembly (FAR) for the
payloads as discussed in Section 3.4. The NFC link connection
for IPv6 over NFC MUST be configured with an equivalent MIU size to fit
the MTU of IPv6 Packet. The MIUX value is 0x480 in order to fit the MTU
(1280 bytes) of a IPv6 packet if NFC devices support
extension of the MTU.

PROPOSED:
IPv6-over-NFC MUST NOT use fragmentation and reassembly (FAR) at the
adaptation layer for the payloads as discussed in Section 3.4. The NFC
link connection for IPv6 over NFC MUST be configured with an equivalent
MIU size to support the IPv6 MTU requirement (of 1280 bytes). To this end,
the MIUX value is 0x480.

31.- Section 5, 1st paragraph: s/in link layer/at the link layer

32.- Section 5.1 title: s/NFC-enabled Device Connected to the
Internet/NFC-enabled Device Network Connected to the Internet

33.- Section 5.1, 1st paragraph:

CURRENT:
Figure 10 illustrates an example of an NFC-enabled device network
connected to the Internet. The distance between 6LN and 6LBR is
typically 10 cm or less. If there is any laptop computers close to a
user, it will become a 6LBR. Additionally, when the user mounts an
NFC-enabled air interface adapter (e.g., portable NFC dongle) on the
close laptop PC, the user’s NFC-enabled device (6LN) can communicate
with the laptop PC (6LBR) within 10 cm distance.

PROPOSED:
Figure 10 illustrates an example of an NFC-enabled device network
connected to the Internet. The distance between 6LN and 6LBR is
typically 10 cm or less. For example, a laptop computer that is connected
to the Internet (e.g. via Wi-Fi, Ethernet, etc.) may also support NFC and
act as a 6LBR. Another NFC-enabled device may run as a 6LN and communicate
with the 6LBR, as long as both are within each other's range.

34.- Figure 10: please fix the couple of vertical lines that are shifted
to the right.

35.- Section 5.1, last paragraph: s/Two or more 6LNs are/Two or more 6LNs
may be

36.- Section 5.2: is "transiently" the only case where a network may be
isolated? I.e. could such a network be *permanently* isolated?

37.- Section 5.2. Please indicate the subnet model.

38.- Section 7, 1st line:

CURRENT:
There are the intrinsic security properties of NFC due to its short
link range.

PROPOSED:
NFC is often considered to offer intrinsic security properties due to its
short link range.

39.- Section 7, 2nd paragraph: does "Short Address" need to be capitalized
here?