[6lo] Shepherd's comments on draft-ietf-6lo-nfc-09
Samita Chakrabarti <samitac.ietf@gmail.com> Mon, 09 July 2018 03:42 UTC
Return-Path: <samitac.ietf@gmail.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9479130E0E for <6lo@ietfa.amsl.com>; Sun, 8 Jul 2018 20:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fayUpMk_BEEu for <6lo@ietfa.amsl.com>; Sun, 8 Jul 2018 20:42:05 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B615D130DC6 for <6lo@ietf.org>; Sun, 8 Jul 2018 20:42:04 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id s12-v6so19634816wmc.1 for <6lo@ietf.org>; Sun, 08 Jul 2018 20:42:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=VLkGclpxKzBKQMkQ5cxtlBSMWt24evy45STV5WeCXlI=; b=TUKl6qKlj1TGm0LawvnwToezx4gJxjiOzF5LhH7DVqqP4v1Tio1tiNxeD6qviwCAyn l0vklz9UCCBHA5CrYK2BR0jxBGBz/+54awXl+OsaA+626lFY0j0yqlstg+/6yk1vGGH7 gzI0QWZizZjVwamSEX4+1/6cSG9PdiXv6GdcNh7Z3Odo1lnm2VK3/LY4hJo3grrDh4u9 dGyF3gvHGxJHYwAX2n/IaFv+K6vJJrbxKDGsrn8paKHg/0ZEhdy1znrTBEkXcl/qWAXk Mw2NOPbd+HMYSQDlVmc5cIhVwmVCOCUBgoRVtBpoi1pBDpFXWag9cYBJVDQOUIjpWoJ/ d30w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=VLkGclpxKzBKQMkQ5cxtlBSMWt24evy45STV5WeCXlI=; b=bBM45ppbIJGEWqn2sUazF0TvOC/WAeeKvPz1FK1CKe5uhTllPOV2YLCwoyYcIeA/XT 2oxO344WseLOGzt0q1dhBArD4K5H7cLkugzUK103bVv4LK+sPD00uKBvU/xhyg/H9Ea6 MEm4vmw3vNyHhqxh+7QhLO1y596vrpNX/4dt8NTSuLcbwnBBIIGrfFpe9qDPbVDtNUiw PZuqO8VdwNqaULPPLeBVg1RlmJcC1wA/iUanDiHtfXVZwJa6YH3iCVmd8Rtbj1JTrzCn zRfNHW1YOMi13MPLI49bTF0aJcx987tNkb858HZ4JDvwvnizyeEJtcfr6bkl8N/ykvJH 9eFA==
X-Gm-Message-State: APt69E3PbWp/UzevPTaj3jY6D8nGH4VEC+ab+P1SAE+WWo1iT61h8wRv okevBN/k6LeSRHiOf/vxHtCjj5aT55tM5cotMDc=
X-Google-Smtp-Source: AAOMgpd1CFQWGfSe3HsDAVOxYt++o8LF5NHlOhtQvcmllGbi3WV7ty1vSZpWqdTVq/AwV6nFe6I4NOVWvvpVusAoRDI=
X-Received: by 2002:a1c:1695:: with SMTP id 143-v6mr10593970wmw.12.1531107723172; Sun, 08 Jul 2018 20:42:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a1c:9145:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 20:42:02 -0700 (PDT)
From: Samita Chakrabarti <samitac.ietf@gmail.com>
Date: Sun, 08 Jul 2018 20:42:02 -0700
Message-ID: <CAKmdBpdNNSGiqjnRtaRwffZq63+PkQ0dyqzq-8PrTsSi-Hw+-w@mail.gmail.com>
To: 최영환 <yhc@etri.re.kr>, lo <6lo@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Cc: samita.chakrabarti@verizon.com
Content-Type: multipart/alternative; boundary="000000000000f3e023057088cb43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/3UniF_cpEyvuxZe-sB2Qp_wDMT4>
Subject: [6lo] Shepherd's comments on draft-ietf-6lo-nfc-09
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2018 03:42:08 -0000
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.