Re: [6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-nfc-13: (with COMMENT)

Mirja Kuehlewind <ietf@kuehlewind.net> Fri, 07 June 2019 07:42 UTC

Return-Path: <ietf@kuehlewind.net>
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 BC2AA120019; Fri, 7 Jun 2019 00:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 UaUOlD-x4nbT; Fri, 7 Jun 2019 00:42:47 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 E6E4A1200FF; Fri, 7 Jun 2019 00:42:46 -0700 (PDT)
Received: from 200116b82c680300bdedf85ea96f86cd.dip.versatel-1u1.de ([2001:16b8:2c68:300:bded:f85e:a96f:86cd]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hZ9WI-00028E-Ov; Fri, 07 Jun 2019 09:42:38 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <B2C0C4C29044814AB285BBB7C754D9249AC9ED09@SMTP2.etri.info>
Date: Fri, 07 Jun 2019 09:42:25 +0200
Cc: Mirja Kühlewind via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "draft-ietf-6lo-nfc@ietf.org" <draft-ietf-6lo-nfc@ietf.org>, "carlesgo@entel.upc.edu" <carlesgo@entel.upc.edu>, Samita Chakrabarti <samitac.ietf@gmail.com>, "6lo@ietf.org" <6lo@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3B3E12A-947A-4BA5-8853-FAD2AF960405@kuehlewind.net>
References: <155248496919.27828.10433234865223953092.idtracker@ietfa.amsl.com> <B2C0C4C29044814AB285BBB7C754D9249AC9ED09@SMTP2.etri.info>
To: 최영환 <yhc@etri.re.kr>
X-Mailer: Apple Mail (2.3445.104.8)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1559893367;a481c2c2;
X-HE-SMSGID: 1hZ9WI-00028E-Ov
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/FNB5lVtG9JyHiyPMaCVv8wCcE-Q>
Subject: Re: [6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-nfc-13: (with COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 07 Jun 2019 07:42:50 -0000

Hi Younghwan,

Thanks! Please see below for point 3.

> On 7. Jun 2019, at 03:35, 최영환 <yhc@etri.re.kr> wrote:
> 
> Hello Mirja and all,
> 
> Thanks for your valuable reviews.
> Please find my answers inline.
> 
> BRs,
> Younghwan Choi
> 
>> -----Original Message-----
>> From: Mirja Kühlewind via Datatracker <noreply@ietf.org>
>> Sent: Wednesday, March 13, 2019 10:49 PM
>> To: The IESG <iesg@ietf.org>
>> Cc: draft-ietf-6lo-nfc@ietf.org; Carles Gomez <carlesgo@entel.upc.edu>;
>> Samita Chakrabarti <samitac.ietf@gmail.com>; 6lo-chairs@ietf.org;
>> carlesgo@entel.upc.edu; 6lo@ietf.org
>> Subject: Mirja Kühlewind's No Objection on draft-ietf-6lo-nfc-13: (with
>> COMMENT)
>> 
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-6lo-nfc-13: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> 1) I agree with Benjamin's discuss point on sec 3.4: there seems to be a
>> mismatch between the text and the figure that needs to be resolved or
>> clarified before publication.
> 
> I agreed with Benjamin's point, so I will change the paragraph for clarification. Please refer to my answers for Benjamin's DISCUSS and COMMENTS.
> 
>> 
>> 2)Use of normative language doesn't always seem quite appropriate,
>> especially SHALL. Benjamin already identified some cases in section 3.3.
>> 
>> Here is an additional one in sec 4.1:
>> "The adaptation layer for IPv6 over NFC SHALL support neighbor
>>   discovery, stateless address auto-configuration, header compression,
>>   and fragmentation & reassembly."
> 
> I will get rid of the "SHALL".
> 
>> 
>> Also this MAY in sec 5.2:
>> "In an isolated NFC-enabled device network,
>>   when two or more LRs MAY be connected with each other, and then they
>>   are acting like routers, the 6LR MUST ensure address collisions do
>>   not occur."
>> 
>> Please also check other occurrences.
> 
> I will change "MAY" with "are". And I will check the others as well.
> 
>> 
>> 3) I would have expected to see some discussion about the ability to
>> potentially connect devices over an IP-gateway device to the Internet that
>> were previously not designed to be connected to the Internet. However,
>> maybe that's asked too much as that is certainly something that needs to
>> be addressed by either a higher layer or the device system architecture as
>> a whole.
>> 
> 
> I don’t get your point about 3), but IPv6 over NFC is a just protocol and can be used for every NFC-enabled device (including IP-Gateway devices), which are connected to the Internet.

If the assumption is that any IPv6 over NFC is only send in secured networks, maybe the higher layers are not further protected, and therefore a gateway should probably not just take the IPv6 packet and send it out in the Internet as is. I wonder if that is something that should be further discussed or at least mentioned in the security consideration section.

Mirja