Dear Jari Arkko, Thanks for your comments. Please find my answers inline bellows:
Best regards, Younghwan Choi -----Original Message----- From: Jari Arkko <jari.ar...@piuha.net> Sent: Friday, January 11, 2019 1:56 AM To: gen-art@ietf.org Cc: draft-ietf-6lo-nfc....@ietf.org; i...@ietf.org; 6...@ietf.org Subject: Genart last call review of draft-ietf-6lo-nfc-12 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? YH>> Actually, I would like all of further nfc-abled devices to support MIUX functionality in the future. If so, FAR is NOT necessary and I don't need to consider FAR for nfc devices. However, when I had a test bed for this, the chipset for NFC did not support MIUX option. So, I need to consider FAR for NFC, but I mentioned like above " IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is NOT RECOMMENDED in this document as discussed in Section 3.4." I think FAR of ipv6 over nfc adaptation layer needs to consider NFC worst cases. > 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? YH>> Even though NFC devices is directly connected to the Internet, the NFC device MUST send IPv6 packet as an original sender. If another device like NFC-dongle helps connect to the Internet, the devices and data are under much more security attacks. 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"? YH>> I prefer "... is not necessary". Thanks > 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? YH>> I agree. I will change it with "When two or more NFC 6LNs(or 6LRs) meet, there are two cases." > 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"? YH>> I mean "One is that three or more NFC devices are linked with multi-hop connections". This is ok for clarification? > and the other is that they meet within a sigle hop range (e.g., > isolated network). s/sigle/single/ YH>> Thanks a lot. I reviewed this docu. Several times but you find a new typo. I think some tool I used changed it automatically. :) 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. YH>> It means "One is that three or more NFC devices are connected within a single-hop area". Nits/editorial comments: > and the other is that they meet within a sigle hop range (e.g., > isolated network). s/sigle/single/ YH>> Thanks again. > 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? YH>> There is an election process of some sort, but I don't mention the details. I think it is an implementation issue. Thanks for your comments again. Take care. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
