Jari, thanks for your review. Younghwan, thank you for your responses. I entered a DISCUSS ballot to discuss the MIUX/FAR interop, the security considerations, and the use of normative keywords.
Alissa > On Jan 11, 2019, at 1:28 AM, 최영환 <y...@etri.re.kr> wrote: > > 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
