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
tsv-art@ietf.org 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.

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.

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.

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?

(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.

(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.