Genart last call review of draft-ietf-6lo-nfc-12
Jari Arkko <firstname.lastname@example.org> Thu, 10 January 2019 16:56 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59737130ECE; Thu, 10 Jan 2019 08:56:14 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: Jari Arkko <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Subject: Genart last call review of draft-ietf-6lo-nfc-12
Date: Thu, 10 Jan 2019 08:56:14 -0800
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2019 16:56:15 -0000
Reviewer: Jari Arkko Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-6lo-nfc-?? Reviewer: Jari Arkko Review Date: 2019-01-10 IETF LC End Date: 2018-12-24 IESG Telechat date: Not scheduled for a telechat Summary: I found the work useful and generally well written. Thanks for doing the work! There's some further clarity needed in what exactly is supported in all NFC nodes wrt FAR vs. extended MTU. There's also some use of RFC 2119 keywords that should probably be formulated slightly differently. And few other unclear wordings. Finally, the security considerations of devices only connectable 10cm from each other but at the same time providing potentially global IP connectivity need further discussion. Major issues: > IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is > NOT RECOMMENDED in this document 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. However, if the NFC device > does not support extension, IPv6-over-NFC uses FAR with default MIU > (128 bytes), as defined in [RFC4944]. I like the idea of mandating sufficient MIUX. But I don't understand why you need the FAR process in that case. Or if you do, how its use is possible, in a network with mixed set of devices that implement MIUX and no FAR, or FAR and no MIUX. It doesn't seem like interoperability is possible in that situation, or am I missing something? Or is FAR mandated to be implemented for the NFC IPv6 nodes? > 5.1. NFC-enabled Device Connected to the Internet I found the discussion of NFC-can-only-be-reached-from-10cm-away a little bit in contradiction with the goals of providing connectivity to the device on IP. Presumably after such connectivity is arranged, the device needs to prepare for anyone from the Internet potentially sending a packet to it. Or is the idea that there's IP connectivity only between a local node and the NFC device? This topic should definitely be discussed in the Security Considerations section. Minor issues: I feel that the keyword MAY is used in a place that is not appropriate here: > In addition, if DHCPv6 is used to assign an address, > Duplicate Address Detection (DAD) MAY not be required. Perhaps you would like to say "... may not be necessary" and then expand on what implementations are supposed to do under specific conditions. Or can you already say "... is not necessary"? > o When two or more NFC 6LNs(or 6LRs) meet, there MAY be two cases. Are you saying that there are exactly these two situations, or that there are many different situations, but you only list two? In either case, the use of the keyword MAY is inappropriate here. If you could say "... there are two cases" that would be best. Or if there are more cases, talk about them as well? > One is that they meet with multi-hop connections This language is unclear, at least to me. Networks don't "meet". Be precise. Did you mean "One is that the two networks are connected through intermediate routers"? > and the other is that they meet within a sigle hop range (e.g., isolated network). s/sigle/single/ Also, again, be precise about what you mean by "meet". Are the two networks connected via a device? Or are devices within the same area confused about which network they are communicating with, if there are multiple networks? The rest of the paragraph is similarly vague about the actual connectivity that is going on here. Nits/editorial comments: > and the other is that they meet within a sigle hop range (e.g., isolated network). s/sigle/single/ > a performance-outstanding device can become a router Did you mean to say "a high-performance device can choose to be a router and serve others in the network"? But how does this selection happen? Someone just decides they are "performance-outstanding"? Or there's an election process of some sort?