Hi Younghwan, Thanks! Please see below for point 3.
> On 7. Jun 2019, at 03:35, 최영환 <[email protected]> wrote: > > Hello Mirja and all, > > Thanks for your valuable reviews. > Please find my answers inline. > > BRs, > Younghwan Choi > >> -----Original Message----- >> From: Mirja Kühlewind via Datatracker <[email protected]> >> Sent: Wednesday, March 13, 2019 10:49 PM >> To: The IESG <[email protected]> >> Cc: [email protected]; Carles Gomez <[email protected]>; >> Samita Chakrabarti <[email protected]>; [email protected]; >> [email protected]; [email protected] >> Subject: Mirja Kühlewind's No Objection on draft-ietf-6lo-nfc-13: (with >> COMMENT) >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-6lo-nfc-13: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 1) I agree with Benjamin's discuss point on sec 3.4: there seems to be a >> mismatch between the text and the figure that needs to be resolved or >> clarified before publication. > > I agreed with Benjamin's point, so I will change the paragraph for > clarification. Please refer to my answers for Benjamin's DISCUSS and COMMENTS. > >> >> 2)Use of normative language doesn't always seem quite appropriate, >> especially SHALL. Benjamin already identified some cases in section 3.3. >> >> Here is an additional one in sec 4.1: >> "The adaptation layer for IPv6 over NFC SHALL support neighbor >> discovery, stateless address auto-configuration, header compression, >> and fragmentation & reassembly." > > I will get rid of the "SHALL". > >> >> Also this MAY in sec 5.2: >> "In an isolated NFC-enabled device network, >> when two or more LRs MAY be connected with each other, and then they >> are acting like routers, the 6LR MUST ensure address collisions do >> not occur." >> >> Please also check other occurrences. > > I will change "MAY" with "are". And I will check the others as well. > >> >> 3) I would have expected to see some discussion about the ability to >> potentially connect devices over an IP-gateway device to the Internet that >> were previously not designed to be connected to the Internet. However, >> maybe that's asked too much as that is certainly something that needs to >> be addressed by either a higher layer or the device system architecture as >> a whole. >> > > I don’t get your point about 3), but IPv6 over NFC is a just protocol and can > be used for every NFC-enabled device (including IP-Gateway devices), which > are connected to the Internet. If the assumption is that any IPv6 over NFC is only send in secured networks, maybe the higher layers are not further protected, and therefore a gateway should probably not just take the IPv6 packet and send it out in the Internet as is. I wonder if that is something that should be further discussed or at least mentioned in the security consideration section. Mirja _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
