Dear Samita, Thanks a lot for your comments. I’m going to reflect your comments on the draft (-10), and publish it. See you in Montreal (QC).
BRs, Younghwan Choi From: Samita Chakrabarti <[email protected]> Sent: Monday, July 9, 2018 12:42 PM To: 최영환 <[email protected]>; lo <[email protected]>; Gabriel Montenegro <[email protected]> Cc: [email protected] Subject: Shepherd's comments on draft-ietf-6lo-nfc-09 Hi Younghawn: I have volunteered to take over the shepherding job for this document. Here are my comments: Please update -10 with these comments. Let me know if you have any further questions. Though the -09 draft might expire before the submission gate opens in the IETF week, I believe you should not have issues to submit version 10. Let the chairs know if you do have issues for submission of the next revision. Thanks, -Samita [CC at my work email for quick attention ] --------------------------Comments------------------------------------------------ Section 3.2: 2nd para: "an IPv6 packet SHALL be" -- why SHALL? if this is the mandate this document requires for implementing the draft -- SHALL should be replaced by "MUST" Section 3.4: Typo in the first line - s /an IPv6 packet SHALL passed down/ an IPv6 packet MUST be passed down/ Please refer to RFC 2119 for when to use MUST, SHOULD and MAY Please check all SHALL references in this section (3.4) and throughout the document to appropriately mandate them as per RFC 2119 [i,e if these are specificed in this document for the first time]. Comment: Use this text for clarification -- 'default MTU value is 128 bytes when no MIUX parameter is transmitted by the NFC LLC layer'. CURRENT TEXT: Otherwise, the MTU size in NFC LLCP SHALL calculate the MIU value as follows: MIU = 128 + MIUX. When the MIUX parameter is encoded as a TLV, the TLV Type field SHALL be 0x02 and the TLV Length field SHALL be 0x02. The MIUX parameter SHALL be encoded into the least significant 11 bits of the TLV Value field. The unused bits in the TLV Value field SHALL be set to zero by the sender and SHALL be ignored by the receiver. However, a maximum value of the TLV Value field can be 0x7FF, and a maximum size of the MTU in NFC LLCP is 2176 bytes. Samita's Comments: Otherwise, the MTU size in NFC LLCP SHOULD be calculated from the MIU value as follows: [ is this correct? Not clear from the draft what is the relationship mapping between MTU and MIU - please clarify] MIU = 128 + MIUX. 1) Clarify length of type and len fields. From the value example (0x02), it appears that they are both 1 byte fields. THus the 0x02 value in len field means the value length is always 2 bytes. Is this what is meant? 2) Please replace the SHALL to SHOULD or MUST appropriately and then provide a min value and MAX val (0x7FF). Calculate the breakdown of MTU size of NFC LLCP(2176 bytes) - does it include the 128 byte default value of MIU? Section 4.2: The last parapgraph in this section and section 4.8 seem to indicate that this docuemnt recommends no FAR over NFC link for simplicity and thus defines a MIUX extension to avoid any fragmentation and reassembly. But the text is very ambiguous - this will surely create interoperability problem. I would suggest clarify the 3rd paragraph in section 4.2 and also clarify section 4.8 that at the time of writing this document does NOT RECOMMEND using FAR over NFC link due to simplicity of the protocol and implementation and the implementation for this specification SHOULD (MUST?) use MIUX extension to communicate the MTU of the link to the peer as defined in section 4.2 Section 4.5: Comment-1. Current text: Unless they are the same (e.g., different MTU, level of remaining energy, connectivity, etc.) Suggested text: When the NFC nodes are not of uniform category (e.g., different MTU, level of remaining energy, connectivity, etc.)... Comment-2. Current Text: Also, they MAY deliver their own information (e.g., MTU and energy level, etc.) to neighbors with NFC LLCP protocols during connection initialization Suggested Text ( with mandatory requirment for avoiding FAR): Also, they MUST deliver their MTU information to neighbors with NFC LLCP protocols during connection initialization. The router MAY also communicate other capabilities which is out of scope of this document. Comment 3. Suggestion: Please check with RFC6775-update latest ( and Pascal) to make sure that the update supoorts the NFC draft which is classic RFC 6775 compatible. Section 4.8: Re-word (if applicable) based on the comments above for section 4.2 Section 4.10: Does this mapping represent the link-layer address part (IID) of IPv6 address? It is not clear. Please provide an example of a full IPv6 multicast address when NFC LLC is used. Section 7: Please comment about connecting the NFC device over the Internet. Because of 6bit IID value the threat for man in the middle attack is multiplied. Thus the document should caution about that and recommend using it only over a secured tunnel or other security mechanism.
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
