[6lo] John Scudder's Abstain on draft-ietf-6lo-nfc-19: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-6lo-nfc-19: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# John Scudder, RTG AD, comments for draft-ietf-6lo-nfc-19
CC @jgscudder

This document seems promising and needed, but as noted below, I think it still
needs work before it should advance. I support Lars's DISCUSS -- as noted
below, lack of the foundational Normative reference prevented me from being
able to complete a meaningful review of this document. I notice this point was
raised in a DISCUSS by Eric Rescorla in 2019, I'm surprised it hasn't been
addressed. I do see in the shepherd write-up that "Access to the NFC spec has
been available for those that have needed it" but regrettably, it's not clear
how this is accomplished.

## COMMENTS

### General

I agree with Warren's observation that "it doesn't seem like [the document]
contains enough information to allow a full implementation". Addressing the
specific comments below would be helpful, but not sufficient to address that
concern, but lacking the [LLCP-1.4] spec it's difficult to be more specific.
Because I feel unable to properly evaluate the document's fitness, I'm
balloting ABSTAIN.

The shepherd write-up tells us that "An implementation of 6lo-NFC exists and
they participated on a 6lo plugtests". I can only guess that the implementors
benefit from being experts who know what to read between the lines, whereas
reviewers such as myself can read only what's written in the document.

### Section 3.2, remove "such as"

"The LLC contains three components, such as Link Management,
Connection-oriented Transmission, and Connectionless Transmission."

The "such as" seems wrong here. I guess you mean "namely", or you could just
remove "such as" and not replace it with anything.

### Section 3.4, "transported to an I PDU"

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

Do you mean "... and transported in an I PDU of LLCP *to* the NFC-enabled peer
device"?

### Section 3.4, mystery bits 1011

Figure 2 shows a field, labeled "1011", occupying bits 16 through 21. It's not
clear what this means. It's not discussed in the text. One might imagine it's
just a field value mandated by [LLCP-1.4], but in that case one would imagine
it would depict a 6-bit string, since the field it's occupying is six bits.
What is going on there? I would refer to [LLCP-1.4] to try to find out, but as
mentioned, it isn't available for review.

What's more, the labeling appears to conflict with the text that says "the
unused bits in the TLV Value field MUST be set to zero".

### Section 3.4, how to fit eleven bits into a ten bit field

Still in Figure 2, we see the rightmost field labeled 0x0~0x7FF, and the
paragraph following agrees that the field "MUST be encoded into the least
significant 11 bits". But the ruler at the top shows the field extending from
bit 22 to bit 31, a field of only 10 bits.

My guess is you drew the ruler wrong, and it was supposed to start at bit 21?
But that would still leave the previous "1011" question open.

### Section 3.4, MUST be 0x480

"The MIUX value MUST be 0x480 to support the IPv6 MTU requirement (of 1280
bytes)" unambiguously mandates that MIUX must be exactly 0x480, no more and no
less. I understand the "no less" part, as noted in the quote this is needed to
support a 1280 byte MTU. However, IPv6 doesn't forbid offering a larger value
than 1280.

I'm guessing you left out an "at least", as in "MUST be at least 0x480". If you
really intend to mandate that packets shall be no larger than 1280, please say
why?

### Section 4.3 et seq, 6LBR, 6LR, 6LM

Please expand 6LBR, 6LR, 6LM on first use.

### Section 4.4, bullet 2 is hard to understand

I gave up trying to understand what this bullet means, I'm afraid I can't even
hazard a guess at a rewrite. :-(

## NITS

### Section 7

"(i.e., ad-hoc mode and authenticated mode"
                                          ^ does the missing closing
                                          parenthesis go here?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments