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

[최영환 <[e-mail]>]

Dear Wesley Eddy,

Thanks for your comments.
I have done my best to give answers for your comments.

Please find the answers inline bellows:

Best regards,
Younghwan Choi

-----Original Message-----
From: Wesley Eddy <[e-mail]> 
Sent: Tuesday, December 18, 2018 2:26 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Tsvart last call review of draft-ietf-6lo-nfc-12

Reviewer: Wesley Eddy
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC [e-mail] if you reply to or forward this review.

The use cases for this are not described well.  For instance, section 3.1 talks about sharing contact information and files with a touch between devices, but then subsequently talks about sending over the Internet.  It doesn't follow logically that sharing data locally with a peer on the link somehow requires

IPv6 connectivity to the Internet.  This section mentions "card emulation, peer-to-peer, and reader/writer" modes of operation for NFC, but not which ones might be relevant for running IPv6 over top of, or how they would differ in usage.  There seems to be an implicit assumption that the passive end of an NFC connection might want to communicate with the Internet, but why this would ever be the case is not discussed.  This would be relevant to understanding how transport and applications are implemented on the passive devices, for instance.

YH >> Section 3 describes overviews of NFC, and IPv6-over-NFC is operated on only peer-to-peer mode of NFC link layer in section 3.1. The peer-to-peer mode only enable to bi-directionally send packets between two NFC devices. This means the other modes (card emulation and reader/writer) cannot be useful for IPv6 packet transmission. If three or more devices are connected, intermediate device forwards IP packets for next hop. 

Section 3.2 leaves out a lot of details about how the link operates.  For instance, it mentions connectionless and connection-oriented exchanges without much clarity on what they would be relevant for for IPv6 transport, and also mentions the "symmetry procedure" without explaining what that is or why it is important.  It does not mention how the data rates are selected and controlled or might vary, which would be relevant to transport protocols.

YH >> This section only mentions packet transmission in NFC link layer, so the connection-oriented and connection-less transport are both just for NFC link layer. This is not for IPv6 transport protocols. NFC link layer has two transmission modes i.e., connection-oriented and connection-less mode. NFC link layer can use one of them according to connection environments. This is depends on NFC link layer protocols. This is just information to describe details of protocol formats of NFC L2 packets. If the term "transport" used in section 3.2 makes something complicated and misunderstanding, it can be changed with "transmission" for clarification.

Section 3.4 seems to be saying that the default MTU for NFC is 128 bytes, which would not be sufficient for IPv6.  If I'm understanding correctly, this section should really be saying that an implementation MUST utilize the MIUX NFC extension in order to provide a suitable MTU relevant for IPv6.  Instead, the document seems to indicate that it's okay to go with the 128 byte default? 
Section 4.8 later on seems to be more clear about this and makes it seem like the implementer has a choice to either (1) use MIUX to support at least 1280 byte MTUs, or (2) use the FAR functionality to achieve the same.  Stating this more clearly and consistently across the document is needed.

YH >> It is true that the default MTU of NFC is 128 bytes. However, NFC link layer has a variable MTU option (for MTU extension) when making connections. And also, the extension can cover 1280 byte of IPv6 packet. This document does not recommend FAR as default by using the MTU extension.  This also mentions in section 4.8. If the key word, "default MTU of NFC" makes it misunderstanding in section 3.2,  I would get rids of the key word, "default MTU of NFC" in section 3.2 because IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is NOT RECOMMENDED.

Some questions not addressed:

(1) Are there relations that need to be considered between IP header bits like the DSCP or ECN signalling relevant to NFC links, or is it expected that NFC links/hosts would not be able to utilize these meaningfully?

YH >> I think NFC is not able to utilize those meaningfully.

(2) How are upper layers made aware of the MTU supported on the link if it could established via either MIUX or FAR?  TCP and other protocols need the correct information in order to send packets properly.

YH >> I think this is not quite easy to answer from the perspective of  IPv6-over-NFC protocol. This can be resolved as an implementation issue I believe.

(3) The data rate ranges are mentioned, but not whether IP over NFC links would be expected to have some type of delays or variation in delays associated with them or typical frame loss rates, etc. that might be of interest in properly configuring transport protocols.  One could imagine this might be the case with passive targets.

YH >> I think this is not also easy to consider the variation in delays or frame loss rates, but I also have tested with my test-bed for this at the beginning stage. During the tests, the date rate with NFC was not quite fast. This is because the two devices are nearly touched, but there was some frame loss rarely. It is assumed that the NFC devices communicate each other within the 10cm distance (this means nearly touched), so there is no problem I believe.

YH >> Thanks again.