Re: [6lo] Warren Kumari's No Objection on draft-ietf-6lo-nfc-13: (with COMMENT)

Warren Kumari <warren@kumari.net> Mon, 10 June 2019 20:41 UTC

Return-Path: <warren@kumari.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 DFFE8120106 for <6lo@ietfa.amsl.com>; Mon, 10 Jun 2019 13:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 Bo_j4TAxLZv4 for <6lo@ietfa.amsl.com>; Mon, 10 Jun 2019 13:41:20 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 BC0901200F1 for <6lo@ietf.org>; Mon, 10 Jun 2019 13:41:20 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id j19so11928819qtr.12 for <6lo@ietf.org>; Mon, 10 Jun 2019 13:41:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=68w/kifGpTgHaNGc3JZW9kUdi1IG8JU8vQtFNQSRlpw=; b=WNM/4f8ZMgwpPdciIIqz7c4y0B1zQ1qyevkYojHZIbtkiSl9Oq7b/VvDYfwyHygjrD xy3GUpH49oECloQYXJxf5dZXMojh8TWu4bAT1ZpvgiefELoNwWbjZEoIbK6Pv17HS9Yc gWTMp8UDbZqt3d8LjfVXDs+Vq//RzGxXnodpoLTdaitDd+gUh9xcPwINTeOsylHjOTsF ZqzgSZ556aR/CtDDlLcKX7jRbuD/VzSGkWnpFNlzJHTwSF35iooTnK7Beyo8LrzkucPO Hrd0DT5DGmXkWMOrK6aZi7KzYF5ULM8YEi4Ja6EEpifrs8HkvOSCinW0MJtRMN8S657N QEug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=68w/kifGpTgHaNGc3JZW9kUdi1IG8JU8vQtFNQSRlpw=; b=JHWA1fUkAX/KefH3NAFI6SaKItrd6/1HqJnUpJv/j6tqTd58u3VfAcWJCT9kdKOiWj pavn/2XobB5UVI3MfKm3v+0syOPTdHTdDsYxQrxUxyQgcrWuyG9WWLy2EFdy4cEIK+yO Q2PAwYr8jYGgvxH43KIoG53d0MxEXn/jD6WX5EMXH7LlULg8U6t4wS44kgNGIfst6mVX IlQa4dLZ6ofaiU3ZW2e/MUZmxgPTKGyY8eKxWB6a5MPhjJKBiYxaIeAoVCHRylKh1fun jNIk7cwhqlAcQ2RKoCqEWMW9nRs+tLPIvTSD6VGB7I14OOQTvGjIbUI8ey9r9WtDhDjg 7fVA==
X-Gm-Message-State: APjAAAWiXxt53ARVAqE+CdHZDGWTIM8AttIxTc5Q76lHNNO7OU7TOFlP j78cXj7KsEQ6lHKXHLpxQThal4VpSf/tcnL/7NRmjA==
X-Google-Smtp-Source: APXvYqz1Msz0msqO9CFG8sFSj/bbYraOy1faRQUoKJs0B6jTykVklHPOnvAQc0zxoAi/GbHiZJqHWZqxJxmGAf8adxA=
X-Received: by 2002:ac8:2d81:: with SMTP id p1mr59883525qta.279.1560199279434; Mon, 10 Jun 2019 13:41:19 -0700 (PDT)
MIME-Version: 1.0
References: <155255185094.2671.15731799736877181880.idtracker@ietfa.amsl.com> <B2C0C4C29044814AB285BBB7C754D9249AC9F1E9@SMTP2.etri.info>
In-Reply-To: <B2C0C4C29044814AB285BBB7C754D9249AC9F1E9@SMTP2.etri.info>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 10 Jun 2019 16:40:43 -0400
Message-ID: <CAHw9_i+qhBLfUJxovPrzaiyNTZT=Yeiy4LMB6yJjESz2t3ezZw@mail.gmail.com>
To: 최영환 <yhc@etri.re.kr>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-6lo-nfc@ietf.org" <draft-ietf-6lo-nfc@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, Samita Chakrabarti <samitac.ietf@gmail.com>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "bill.wu@huawei.com" <bill.wu@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/iazuYWkflsDQR2XBEib3rOKrjuQ>
Subject: Re: [6lo] Warren Kumari'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: Mon, 10 Jun 2019 20:41:23 -0000

On Fri, Jun 7, 2019 at 3:59 AM 최영환 <yhc@etri.re.kr> wrote:
>
> Hello Warren and all,
>
> Thanks for your valuable reviews.
> Please find my answers inline.
>
> BRs,
> Younghwan Choi
>
> > -----Original Message-----
> > From: Warren Kumari via Datatracker <noreply@ietf.org>
> > Sent: Thursday, March 14, 2019 5:24 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;
> > bill.wu@huawei.com
> > Subject: Warren Kumari's No Objection on draft-ietf-6lo-nfc-13: (with
> > COMMENT)
> >
> > Warren Kumari 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:
> > ----------------------------------------------------------------------
> >
> > I apologize - I've read the document, but it doesn't seem like it
> > contains enough information to allow a full implementation.
> >
> > The document keeps talking about the fact that the range is limited to
> > 10cm, and makes some security assertions from this - from the little
> > that I understand about this technology (and I wasn't able to follow
> > all the references), ISO 15693 tags using NDEF are now part of the NFC
> > specification - these  work up to 1M. I have no idea if this protocol
> > is supposed to work over that, but if so, 1M is greater than 10cm.
>
> You are right. Normally, NFC applications says communications with less than 10cm or single touch between two NFC devices, but I also know 1M range is available technically. But, 1M, I think, is also very short distance. Either 10cm distance or 1M distance of NFC is ok for IPv6 over NFC. Even though 1M is used for IPv6 over NFC, nothing of this document needs to change. Only some more explanations about the maximum 1M distance of NFC can be put if it is ok.
>

Yup.

> >
> > Also, I see you did respond to the OpsDir review (
> > https://datatracker.ietf.org/doc/review-ietf-6lo-nfc-12-opsdir-lc-wu-
> > 2018-12-19/
> > -- thank you very much, Qin) , but there are things in these which
> > don't seem fully addressed. As an example, Qin asked: ----  Section 3.4 said ”
> > the MTU size in NFC LLCP MUST be calculated from the MIU
> >    value as follows:
> >                              MIU = 128 + MIUX.”
> > Can you provide formula to calculate MTU from MIU? Not clear how MTU
> > is related to MIU? ---
>
> It would be "MTU = MIU = 128 + MIUX."
>

Sorry, that comment was from Qin - the formula should be added to the document.

> >
> > You responded: "YH >> Actually, MIU is the same as MTU. Specifications
> > in NFC forum use 'MIU', and we use 'MTU'. But these two has the same
> > meaning."
> >
> > I read version 13 of this document and had the exact same question --
> > how do I calculate the MTU from the MIU? If they really are the same
> > thing (which I'm not sure they are), the document should state that,
> > so readers can more easily implement.
> >
>
> This document uses the two terms, "MIU" and "MTU". Actually, technical meaning of the two terms is the same. NFC spec says it as MIU. IETF says it as MTU. So, I mentioned this one in section 3.4. If more explanations about MIU for clarification, I will put the explanations about relationships between the two terms.

Yes please -- simply clarifying that the terms mean the same thing
will address the issue.

Thanks,
W


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf