Re: [6lo] Review of draft-ietf-6lo-nfc-16

최영환 <yhc@etri.re.kr> Tue, 11 August 2020 07:53 UTC

Return-Path: <yhc@etri.re.kr>
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 701AC3A0DF6 for <6lo@ietfa.amsl.com>; Tue, 11 Aug 2020 00:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dooray.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 4xaRVZ9jg2k9 for <6lo@ietfa.amsl.com>; Tue, 11 Aug 2020 00:52:58 -0700 (PDT)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7863A0DEC for <6lo@ietf.org>; Tue, 11 Aug 2020 00:52:57 -0700 (PDT)
Received: from unknown (HELO send002-relay.gov-dooray.com) (211.180.235.153) by 129.254.9.16 with ESMTP; 11 Aug 2020 16:52:50 +0900
X-Original-SENDERIP: 211.180.235.153
X-Original-MAILFROM: yhc@etri.re.kr
X-Original-RCPTTO: 6lo@ietf.org
Received: from [10.162.225.103] (HELO send001.gov-dooray.com) ([10.162.225.103]) by send002-relay.gov-dooray.com with SMTP id 7135327d5f324e56; Tue, 11 Aug 2020 16:52:54 +0900
DKIM-Signature: a=rsa-sha256; b=z6ne8+hAFH9aRsxcwBBEYk2jLQAzD6e8SNoP0e78lKEKD3gZ6T4G1umVXsCBCm3AilM1CwnfSC oyNi3U7CVHJabdBTZKtGV4pJJ3B1E+0bbbZ7r35JafqiiwOx61ibPbv0/xihJlMP6+lP5Yz0c+N+ wAYBSbsxu2aL0YHhsPROjV3xIYMDuOoSzK65PfpRBx606QqnbwlJgN+VIhKJjECLLhq86MWiV+/q MVCmAHrZIzdZLuDEpH5FwYjqFmh6NWM85gT3ZER/Ll0lkVACaRI6E1FN/PMN02fcWB9eki6ol7+p 6RKz3WdV2Z0jO0a6+eerUzZQdFtq7br2fA2nhnkg==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=MraM3VzlwDTsxJ5eb6u19+i4XqivOA7ekbIKfCz/kW0=; h=From:To:Subject:Message-ID;
From: =?UTF-8?B?7LWc7JiB7ZmY?= <yhc@etri.re.kr>
To: draft-ietf-6lo-nfc.authors@ietf.org, Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Cc: 6lo@ietf.org
Message-ID: <lc7kgazqu861.lc7kgazqyvix.g1@dooray.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_121399_693074848.1597132373404"
X-Dsn-Request: true
Importance: Normal
X-Priority: Normal
X-MSMail-Priority: Normal
Date: Tue, 11 Aug 2020 16:52:54 +0900 (KST)
Sender: yhc@etri.re.kr
References: <62cb4013dcad8b3b055c0d147dfee1ea.squirrel@webmail.entel.upc.edu>
In-Reply-To: <62cb4013dcad8b3b055c0d147dfee1ea.squirrel@webmail.entel.upc.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Qo2LDh6abmu8Mh8WdHF6bVOGhLA>
Subject: Re: [6lo] Review of draft-ietf-6lo-nfc-16
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: Tue, 11 Aug 2020 07:53:01 -0000

Dear Carles,

Thanks for your comments and PROPOSED. 
I've reflected them except No. 37, "Section 5.2. Please indicate the subnet model."

I've produced new version of the draft as the attachment, but I have not submit the new document in IETF yet because of the comment 37.

Actually, I need some more clarification about your comment 37. 
You mean that the figure needs a kind of "a dotted box" or something for the subnet model ?
I would like to ask to how to indicate subnet model in Figure 11.? 

If you give me some more explanation about the "subnet model", I will reflect it in the figure.
After resolving the comment 37, I will submit -17 in IETF.

Best regards,
Younghwan
--------------------------------------------------
최 영 환  공학박사/선임연구원
YOUNGHWAN CHOI, Ph.D./Senior Researcher
ETRI 표준연구본부 지능정보표준연구실
(34129) 대전시 유성구 가정로 218
Tel +82-42-860-1429, Fax +82-42-860-5404 
Email  yhc@etri.re.kr

-----Original Message-----
From:  "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
To:      <draft-ietf-6lo-nfc.authors@ietf.org>rg>; 
Cc:      <6lo@ietf.org>rg>; 
Sent:  2020-08-07 (금) 15:05:02 (UTC+09:00)
Subject: Review of draft-ietf-6lo-nfc-16

Dear authors of draft-ietf-6lo-nfc,

Thanks for updating the draft and producing revision -16.

In my opinion, the document has improved. I checked the document again,
and I have another round of comments. Perhaps just one more iteration to
address this round of comments might suffice to proceed to the next step.

Please find below my comments on -16.

Cheers,

Carles (shepherd of draft-ietf-6lo-nfc)

---------------------------------------------------------------------------


1.- Section 3.1, 2nd line: s/enables/allows (this is to avoid repeating
the same term so quickly in the text).

>> Changed.

2.- Section 3.1, 1st paragraph:

CURRENT:
information and share files, so that users of NFC-enabled devices can
quickly share contact information and other files with a touch. The other
two modes does not support two-way communications between two devices.
Therefore, the peer mode is used for ipv6-over-nfc.

PROPOSED:
information bidirectionally. The other two modes do not support two-way
communications between two devices. Therefore, the peer-to-peer mode is
used for IPv6 over NFC.

>> I like your PROPOSED. Changed.

3.- Section 3.2 title: s/Stacks/Stack

>> Changed.

4.- Section 3.2, 1st paragraph:

CURRENT:
The peer-to-peer mode is made in Activities Digital Protocol in NFC
Physical Lay. The NFC Logical Link consists of

PROPOSED:
The peer-to-peer mode is offered by the Activities Digital Protocol at the
NFC Physical Layer. The NFC Logical Link Layer consists of

>> I've changed the CURRENT with your PROPOSED.

5.- Section 3.2, 2nd sentence: does this sentence apply always, or only
when IPv6 is used over NFC?  If the latter, then some proposed text is as
follows:
"The NFC Logical Link Layer comprises the Logical Link Control Protocol
(LLCP), and when IPv6 is used over NFC, it also includes an IPv6-LLCP
Binding"

>> The latter is right, and I've changed it with your PROPOSED.

6.- Section 3.2, 2nd paragraph. Please stick to one term for the whole
document ("Connection-less" and "Connectionless" are both used in the
paragraph).

>> It goes with "Connectionless" only..

7.- Section 3.2, last paragraph, 2nd sentence:

   s/LLCP/The LLCP  (first "LLCP" instance)
   s/LLCP/the LLCP  (second "LLCP" instance)

>> Changed.

8.- Section 3.2, last paragraph:

CURRENT:
The LLCP to IPv6 protocol binding MUST transfer the SSAP and DSAP value to
the IPv6 over NFC protocol. SSAP stands for Source Service Access Point,
which is a 6-bit value meaning a kind of Logical Link Control (LLC)
address

PROPOSED:
The LLCP to IPv6 protocol binding MUST transfer the Source Service Access
Point (SSAP) and Destination Service Access Point (DSAP) value
to the IPv6 over NFC protocol. SSAP is a Logical Link Control (LLC)
address of the source NFC-enabled device with a size of 6 bits.

>> Changed with your PROPOSED.

9.- Section 3.3: s/Logical Link Control Protocol/LLCP

>> Changed.

10.- Section 3.4, 1st paragraph: there may be a bit of confusion regarding
the concepts of I PDU and UI PDU. In previous sections, there seem to be
the I field of a PDU and the UI field of a PDU. However, it seems like now
there is a definition of two different types of PDUs (I PDU and UI PDU).
Are
"I PDU" and "UI PDU" different and exclusive types of PDU? Can a given PDU
carry an I field and a UI field?

>> The message format of I PDU has a sequence field which containing two types of sequence numbers. But, UI PDU does not have such a field.
The other fields between i PDU and UI PDU are the same except the sequence field. UI PDU is used for data transmission without prior establishment of a data link connection. 

Clarifications are needed regarding these terms.

>> I think it would be better to remove UI PDU in the sentence in order to avoid confusion. 
>> CHANGED1: (section 3.2: Last Paragraph, 1st sentence)
  "In order to send an IPv6 packet over NFC, the packet MUST be passed
   down to the LLCP layer of NFC and carried by an Information Field in an LLCP Protocol Data Unit
   (I PDU)."
>> CHANGED2: (section 3.4: 1st paragraph, 1st sentence)
 "As mentioned in Section 3.2, when an IPv6 packet is transmitted, the
   packet MUST be passed down to LLCP of NFC and transported to an I PDU of LLCP of the NFC-enabled peer
   device."

11.- Section 3.4, 2nd paragraph. Only "I PDU" is mentioned here. What
about UI PDUs?

>> I remove "UI PDUs".

12.- Section 3.4, last paragraph. If the maximum possible value of the TLV
Value field is 0x7FF, wouldn't the maximum possible value of the LLCP MTU
be 2175 bytes instead of 2176?

>> "2175 bytes" is right. Thanks. Changed. 

13.- Section 3.4, last paragraph:

CURRENT:
If fragmentation functionality is not used at the
adaptation layer between IPv6 and NFC, the MIUX value MUST be 0x480 to
support the IPv6 MTU requirement (of 1280 bytes).

PROPOSED:
The MIUX value MUST be 0x480 to support the IPv6 MTU requirement (of 1280
bytes).

>> Changed.

14.- Section 4, 1st paragraph:
CURRENT:
NFC technology also has considerations and requirements

PROPOSED:
NFC technology has requirements

>> Changed.

15.- Section 4, 1st paragraph:
CURRENT:
reducing overhead which can be applied to NFC

PROPOSED:
reducing the overhead of IPv6 over NFC

>> Changed.

16.- Section 4, 1st paragraph: s/see Section 4.2/see Section 4.2 and
Section 4.3.

>> Changed.

17.- Section 4.1 title: s/Stacks/Stack

>> Changed.

18.- Section 4.1: s/Figure 3 illustrates IPv6 over NFC/Figure 3
illustrates the IPv6 over NFC protocol stack

>> Changed.

19.- Figure 3. (Just a suggestion.) Perhaps close the upper part of the
figure, i.e. adding a horizontal line closing the box for "Upper Layer
Protocols"?

>> Reflected.

20.- Figure 3: in Figure 1 there is the term "NFC Logical Link Layer". Is
this the same as "NFC Link Layer"? If yes, please stick to the same term
in both figures.

>> Reflected.

21.- Section 4.2, 3rd paragraph: s/the algorithm, F()/the F() algorithm

>> Changed.

22.- Section 4.2, 3rd paragraph: s/easy and short/short and easy

>> Changed.

23.- Section 4.2, 3rd paragraph: s/The F() can provide/The F() algorithm
can provide

>> Changed.

24.- Section 4.3, 1st sentence: s/appending the IID, to/appending the IID to

>> Changed.

25.- Section 4.3, last sentence: s/IIDs/IID

>> Changed.

26.- Section 4.4. When mentioning RFC 6775, you may probably want to cite
RFC 8505. Likewise, the ARO is now an Extended Address Registration Option
(EARO), as per RFC 8505.

>> I've changed it with "EARO [RFC8505]"

27.- Section 4.4, 2nd bullet: remove "(e.g., isolated network)". Note that
two NFC devices might still talk to each other (point-to-point topology),
but one of them may be connected to the Internet.

>> Removed. and I put "Two NFC devices might still talk to each other (point-to-point topology),
but one of them may be connected to the Internet." after the sentence.

28.- Section 4.4, 2nd bullet: s / play a router for 6LR/6LBR / may act as
routers

>> Changed.

29.- Section 4.5, 1st paragraph: s/6LoWPAN_IPHC/LOWPAN_IPHC compressed
IPv6 header (see section 4.6)

30.- Section 4.7:

CURRENT:
IPv6-over-NFC SHOULD NOT use fragmentation and reassembly (FAR) for the
payloads 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.

PROPOSED:
IPv6-over-NFC MUST NOT use fragmentation and reassembly (FAR) at the
adaptation layer for the payloads as discussed in Section 3.4. The NFC
link connection for IPv6 over NFC MUST be configured with an equivalent
MIU size to support the IPv6 MTU requirement (of 1280 bytes). To this end,
the MIUX value is 0x480.

>> Changed with your PROPOSED.

31.- Section 5, 1st paragraph: s/in link layer/at the link layer

>> 

32.- Section 5.1 title: s/NFC-enabled Device Connected to the
Internet/NFC-enabled Device Network Connected to the Internet

33.- Section 5.1, 1st paragraph:

CURRENT:
Figure 10 illustrates an example of an NFC-enabled device network
connected to the Internet. The distance between 6LN and 6LBR is
typically 10 cm or less. If there is any laptop computers close to a
user, it will become a 6LBR. Additionally, when the user mounts an
NFC-enabled air interface adapter (e.g., portable NFC dongle) on the
close laptop PC, the user’s NFC-enabled device (6LN) can communicate
with the laptop PC (6LBR) within 10 cm distance.

PROPOSED:
Figure 10 illustrates an example of an NFC-enabled device network
connected to the Internet. The distance between 6LN and 6LBR is
typically 10 cm or less. For example, a laptop computer that is connected
to the Internet (e.g. via Wi-Fi, Ethernet, etc.) may also support NFC and
act as a 6LBR. Another NFC-enabled device may run as a 6LN and communicate
with the 6LBR, as long as both are within each other's range.

34.- Figure 10: please fix the couple of vertical lines that are shifted
to the right.

>> Fixed.

35.- Section 5.1, last paragraph: s/Two or more 6LNs are/Two or more 6LNs
may be

>> Changed.

36.- Section 5.2: is "transiently" the only case where a network may be
isolated? I.e. could such a network be *permanently* isolated?

>> Changed with "permanently"

37.- Section 5.2. Please indicate the subnet model.

>> I would like to ask how to indicate "the subnet model" in the Figure 11 ? 

38.- Section 7, 1st line:

CURRENT:
There are the intrinsic security properties of NFC due to its short
link range.

PROPOSED:
NFC is often considered to offer intrinsic security properties due to its
short link range.

>> Changed.

39.- Section 7, 2nd paragraph: does "Short Address" need to be capitalized
here?

>> No. Changed.