[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.