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

Alissa Cooper <alissa@cooperw.in> Wed, 13 March 2019 14:51 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DCD1277D6; Wed, 13 Mar 2019 07:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=t0gZwEUF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=2ytaxkEW
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 TeEOjCXZjxS6; Wed, 13 Mar 2019 07:51:24 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73510126C87; Wed, 13 Mar 2019 07:51:24 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 72DCB2A8DB; Wed, 13 Mar 2019 10:51:23 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 13 Mar 2019 10:51:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=0 wl2TyTfa7i7GETcBsGkfuiMr5Z8TwkljiQ5BAnXLFM=; b=t0gZwEUFhhX9QgwKy HrPw8VFKSnaqVMZcELpez18vqErAnEmMln/P4VOgopaI3IZUk6p5S4Y8MhetgEk8 Tjs2MxLEV4UzpphnnZ4vJyUD6QIzoN8ECxWRXLN4KPPm/tjHr/zPfkYGxszBLPDk /vbGNAWz/bLNvlzcAGjYo7KWqt8fhElwglSh60F5Y2BIatcEieixlQDy109xz7An qVhKLCiTPXPtEbiBOK5i5l2z27qqHsMS/jeBsWIZjC0vnMzheyfxYu5MIpGDEPHf jLRWF5ZMyi/Kt8viLd47P/nuq8o/TX/wQOHz2B2mvRCYl2T6f4A7ZY66qnbGEMsH ZGWXg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=0wl2TyTfa7i7GETcBsGkfuiMr5Z8TwkljiQ5BAnXL FM=; b=2ytaxkEW5PTJJir0npa5Fiwd1bkiU2P0HLdOLPL94ivDopVNP0L3YbVMH 5Da33AoSQSeKdn1BlyzrR4KSfBP4RGIuWRnPtycgT8ThovYGPQ+G9T9FT8/fn1CY eLl00oxaE2kDfz1N4Nvtrd2XdeHNMkN6s//xrtCQ+k13d07mgIDqImoWjzFPWZra VZbbN6AJBhyOYJaYXeXZbfLQba7KM290J9dh4ldGTgCdHTD559nB9A9I4S6uKqyy /t81CncMBqhLGt5H96STMHaswunSLFluH5F1KdFdjlnAduFgzHCY4Vs/8oW9Hq4s FJt1QujoBwn8HMHNcdPLICjHeeUFg==
X-ME-Sender: <xms:6hiJXAZquxaYMgsWqYkI2Rbe_dLsbk1pe93fbFEjmnC9u_I2kzQEQA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrhedtgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdeiheenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt
X-ME-Proxy: <xmx:6hiJXIxgs1xQdPjmhAozZIu-yEboWjufV5M9Az34rFX68e_WqeWgEA> <xmx:6hiJXCRbMOOOoEEItV6PZWj_xCHSo0j61p-0QTrW8DTrhlwM_YoZQA> <xmx:6hiJXFKPaf4tdXaZkdtRrZpViPnDX8RrN335y1kn-wqC4gCgGCDKxw> <xmx:6xiJXH0k37SU4HwxA0sdT4DANyAkPx_hxC3NBbiRto0rTNbtbjUjlA>
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id BE67A1033A; Wed, 13 Mar 2019 10:51:21 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <B2C0C4C29044814AB285BBB7C754D9249AC1D7EF@SMTP2.etri.info>
Date: Wed, 13 Mar 2019 10:51:20 -0400
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, =?utf-8?B?7J206rCV7LCs?= <chan@etri.re.kr>, "draft-ietf-6lo-nfc.all@ietf.org" <draft-ietf-6lo-nfc.all@ietf.org>, =?utf-8?B?6rmA7ZiV7KSA?= <khj@etri.re.kr>, "ietf@ietf.org" <ietf@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2133A24C-1A77-45C6-B62C-BA262D4E8FC5@cooperw.in>
References: <154713937431.30824.10339107300503360366@ietfa.amsl.com> <B2C0C4C29044814AB285BBB7C754D9249AC1D7EF@SMTP2.etri.info>
To: =?utf-8?B?7LWc7JiB7ZmY?= <yhc@etri.re.kr>, Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/n6v5wL-8fikjep0JH1K92n5034A>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-6lo-nfc-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 13 Mar 2019 14:51:28 -0000

Jari, thanks for your review. Younghwan, thank you for your responses. I entered a DISCUSS ballot to discuss the MIUX/FAR interop, the security considerations, and the use of normative keywords.

Alissa

> On Jan 11, 2019, at 1:28 AM, 최영환 <yhc@etri.re.kr>; wrote:
> 
> Dear Jari Arkko,
> 
> Thanks for your comments.
> Please find my answers inline bellows:
> 
> Best regards,
> Younghwan Choi
> 
> -----Original Message-----
> From: Jari Arkko <jari.arkko@piuha.net>; 
> Sent: Friday, January 11, 2019 1:56 AM
> To: gen-art@ietf.org
> Cc: draft-ietf-6lo-nfc.all@ietf.org; ietf@ietf.org; 6lo@ietf.org
> Subject: Genart last call review of draft-ietf-6lo-nfc-12
> 
> 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
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
> 
> 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
> 
> Summary:
> 
> 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 wordings.
> 
> 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?
> 
> YH>> Actually, I would like all of further nfc-abled devices to support MIUX functionality in the future. If so, FAR is NOT necessary and I don't need to consider FAR for nfc devices. However, when I had a test bed for this, the chipset for NFC did not support MIUX option. So, I need to consider FAR for NFC, but I mentioned like above " IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is NOT RECOMMENDED in this document as discussed in Section 3.4." I think FAR of ipv6 over nfc adaptation layer needs to consider NFC worst cases.
> 
>> 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?
> 
> YH>> Even though NFC devices is directly connected to the Internet, the NFC device MUST send IPv6 packet as an original sender. If another device like NFC-dongle helps connect to the Internet, the devices and data are under much more security attacks.
> 
> This topic should definitely be discussed in the Security Considerations section.
> 
> 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"?
> 
> YH>> I prefer "... is not necessary". Thanks
> 
>> 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?
> 
> YH>> I agree. I will change it with "When two or more NFC 6LNs(or 6LRs) meet, there are two cases."
> 
>> 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 routers"?
> 
> YH>> I mean "One is that three or more NFC devices are linked with multi-hop connections". This is ok for clarification?
> 
>> and the other is that they meet within a sigle hop range (e.g., 
>> isolated
> network).
> 
> s/sigle/single/
> 
> YH>> Thanks a lot. I reviewed this docu. Several times but you find a new typo. I think some tool I used changed it automatically. :)
> 
> 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.
> 
> YH>> It means "One is that three or more NFC devices are connected within a single-hop area".
> 
> Nits/editorial comments:
> 
>> and the other is that they meet within a sigle hop range (e.g., 
>> isolated
> network).
> 
> s/sigle/single/
> 
> YH>> Thanks again.
> 
>> 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?
> 
> YH>> There is an election process of some sort, but I don't mention the details. I think it is an implementation issue.
> 
> Thanks for your comments again.
> Take care.