Last Call Review of draft-ietf-6lo-nfc-12
review-ietf-6lo-nfc-12-tsvart-lc-eddy-2018-12-17-00

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.