Re: [6lo] Iotdir early review of draft-ietf-6lo-nfc-10

최영환 <yhc@etri.re.kr> Thu, 27 September 2018 06:17 UTC

From: 최영환 <yhc@etri.re.kr>
To: Brian Haberman <brian@innovationslab.net>, "Iot-dir@ietf.org" <Iot-dir@ietf.org>
CC: "draft-ietf-6lo-nfc.all@ietf.org" <draft-ietf-6lo-nfc.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Iotdir early review of draft-ietf-6lo-nfc-10
Thread-Index: AQHUVOh/RVaKXiuL4E2cdv27CmwH+6UDhV7w
Date: Thu, 27 Sep 2018 06:10:40 +0000
Message-ID: <B2C0C4C29044814AB285BBB7C754D9249ABC2E64@SMTP2.etri.info>
References: <153789105259.5074.14953032121235364816@ietfa.amsl.com>
In-Reply-To: <153789105259.5074.14953032121235364816@ietfa.amsl.com>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/w2h4T2-CCEDQCFsdPITWHefgi0k>
Subject: Re: [6lo] Iotdir early review of draft-ietf-6lo-nfc-10
Precedence: list

Dear Brian Haberman,

Thanks for your value comments.
I answered inline bellows.

I produced the next draft (-11) in terms of your comments.
I believe the next draft (-11) is more improved thanks to you.

Best regards,
Younghwan Choi

-----Original Message-----
From: Brian Haberman <brian@innovationslab.net> 
Sent: Wednesday, September 26, 2018 12:58 AM
To: Iot-dir@ietf.org
Cc: draft-ietf-6lo-nfc.all@ietf.org; ietf@ietf.org; 6lo@ietf.org
Subject: Iotdir early review of draft-ietf-6lo-nfc-10

Reviewer: Brian Haberman
Review result: On the Right Track

* Section 3.4 mentions the use of both UI PDUs and I PDUs to carry IPv6 packets. However, Section 3.2 only mentions the use of I PDUs for carrying IPv6 packets. This seems to be a discrepancy that needs to be cleared up.

>> I also mentioned "an Unnumbered Information as well as I PDU" in Section 3.2

* Section 3.4 has the formula MIU = 128 + MIUX. Should MIU be MTU?
Additionally, the use of MIUX is only stated as a SHOULD. If the MIU is 128 and the minimum IPv6 MTU is 1280, shouldn't the use of MIUX be a MUST? The text in Section 4.8 seems to mandate the use of MIUX (i.e., "MUST be configured with an equivalent MIU size to fit the MTU of IPv6 packet"). Given that Section 3.2 says that the NFC LLCP does not fragment/reassemble, I am not sure how NFC can support a minimum IPv6 MTU without MIUX. If it can, can you specify a scenario where the lack of the MIUX is not a problem?

>> LLCP does not support FAR by itself. So, this draft recommend to use MIUX to cover the 1280 byte ipv6 packet as mention in section 4.8, but IPv6-over-NFC MUST support FAR with default MIU (128 bytes) with lack of the MIUX. To fully specify this point, I changed from SHOULD to MUST for the use of MIUX in Section 3.2. I also mentioned the scenario for the lack of MIUX in section 4.8 (Fragmentation and Reassembly).

* Section 4.3 says to use RFC 7217 for generating IIDs. Given the small size of the NFC address space, should there be some guidance on how the Network_ID parameter of f() can be used to increase the randomness of the generated IID?

>> Yes, I think it's a good comment that I didn't catch. In a case of IEEE802.11, Network_ID could be SSID. In addition, the Network_ID is an optional parameter. If Network_ID is certainly required for NFC RID, another generated random number as a nonce could be used as Network_ID. But, there is not any more extra information of NFC devices for Network_ID. I don't think the use of Network_ID is surely necessary in the NFC device case to increase the randomness of the generated IID. Anyhow, according to your comment, I mentioned the use of Network_ID to increase the randomness of the generated IID in section 4.3

* Section 4.3 refers to RFC 7136, which says that the 'u' bit is meaningless unless the IID comes from an IEEE MAC address. However, the text then says that the 'u' bit of the generated IID MUST be set to 0. Why?

>> I thought 'u' is 0 because the IID of NFC generated is global. But, I agree 'u' bit is meaningless for NFC devices. I got rid of the sentence. Thanks.

* Section 4.5 seems incomplete. Is IPv6-over-NFC only viable in the mesh-under topology? Are there 6LBR <--> 6LBR scenarios in NFC that need to be described?

>> IPv6-over-NFC is viable in route-over topology but not mesh-under. I am not sure whether 6LBR <-> 6LBR scenarios in NFC need to be described or not. But, the second scenario covers 6LR <-> 6LR as well as 6LN <-> 6LN in section 4.5. So, I additionally mentioned "6LR <-> 6LR" in the second scenario in section 4.5

* I don't see any technical benefits in Section 5 as it does not specify any interoperability details.

>> I additionally mentioned technical details of IPv6-over-NFC functionalities in two cases in section 5 as you commented. For example, multicasting, address collision, and so on.

* I don't see where anything from RFC 4944 is used in this document. The only text that refers to 4944 says to not use the FAR procedure from 4944. Either the reference should be removed or this document should specify which parts of
4944 should be applied.

>> I put the reference of RFC4944 for FAR regarding my second answer in section 4.8

[6lo] Iotdir early review of draft-ietf-6lo-nfc-10 Brian Haberman
Re: [6lo] Iotdir early review of draft-ietf-6lo-n… 최영환
Re: [6lo] Iotdir early review of draft-ietf-6lo-n… 최영환