[Gen-art] Genart last call review of draft-ietf-6lo-nfc-12

Jari Arkko <jari.arkko@piuha.net> Thu, 10 January 2019 16:56 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59737130ECE; Thu, 10 Jan 2019 08:56:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jari Arkko <jari.arkko@piuha.net>
To: gen-art@ietf.org
Cc: draft-ietf-6lo-nfc.all@ietf.org, ietf@ietf.org, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154713937431.30824.10339107300503360366@ietfa.amsl.com>
Date: Thu, 10 Jan 2019 08:56:14 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/TWwX-EAJxVpo4gzWfsuiaebYkNU>
Subject: [Gen-art] Genart last call review of draft-ietf-6lo-nfc-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2019 16:56:15 -0000

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


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


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

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?

> 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?

This topic should definitely be discussed in the Security Considerations

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"?

>  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?

> 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

> and the other is that they meet within a sigle hop range (e.g., isolated


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.

Nits/editorial comments:

> and the other is that they meet within a sigle hop range (e.g., isolated


> 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?