[6lo] Éric Vyncke's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS and COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Mon, 12 December 2022 10:15 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E335C151713; Mon, 12 Dec 2022 02:15:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-nfc@ietf.org, 6lo-chairs@ietf.org, 6lo@ietf.org, Samita Chakrabarti <samitac.ietf@gmail.com>, Carles Gomez <carlesgo@entel.upc.edu>, carlesgo@entel.upc.edu, pthubert@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 9.2.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <167084015037.45648.17136765707622403481@ietfa.amsl.com>
Date: Mon, 12 Dec 2022 02:15:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/plJVoupDzqryxS93tYY8Wbyr5-8>
Subject: [6lo] Éric Vyncke's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2022 10:15:50 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-6lo-nfc-19: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-6lo-nfc-19
CC @evyncke

Thank you for the work put into this document. It could indeed be useful and it
would deserve a high quality specification.

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Carles Gomez for the shepherd's detailed write-up including
the WG consensus *and* the justification of the intended status. But, the
write-up is incorrect about the downward reference as
https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ indicates RFC
3756 is a downref...

Please note that Pascal Thubert is the Internet directorate reviewer (at my
request) and you may want to consider this int-dir reviews as well when Pascal
will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/reviewrequest/16761/

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

### Tagging of references

I have not checked all references, but at least RFC 3633 should not be
normative but only informative.

Moreover, RFC3633 is obsoleted by RFC 8415 for 4 years.

### Section 3.4

As far as I understand the document and its relationship with NFC standards,
then it is not up to the IETF to use normative language around MIUX (specified
by NFC), so, the "MUST" below should rather be "is". ```
   When the MIUX parameter is used, the TLV Type field MUST be 0x02 and
   the TLV Length field MUST be 0x02.  The MIUX parameter MUST be
   encoded into the least significant 11 bits of the TLV Value field.
   The unused bits in the TLV Value field MUST be set to zero by the
   sender and ignored by the receiver.
```

The "MUST" in `The MIUX value MUST be 0x480 to support the IPv6 MTU requirement
(of 1280 bytes).` is of course fine.

Finally, please add a normative reference to RFC 8200.

### Section 4.2

Is this section normative ? There is no BCP14 words in it.

If normative, then how is Network_ID derived from any NFC parameter?

### Section 4.3

While not really a DISCUSS point, what is the link between DHCP-PD and a LLA ?
Remove the part about getting a prefix.

What is a `secured and stable IID` ? Do the authors mean a 'random and stable
IID'?

### Section 4.4 and 5

In section 4.4: `NFC supports mesh topologies but ...`

In section 5: `An NFC link does not support a star topology or mesh network
topology`

So, is mesh supported or not ?

### Section 4.5

Is this section normative ? There is no BCP14 terms.

Is there a IANA registry for "Dispatch" values ? If so, then please add a
reference. It *seems* that the length is 1 octet, please specify the length of
the value.

### Section 4.6

Possibly due to my ignorance of RFC 6282, but this document refers to TCP
(section 4.1) while RFC 6282 only compresses UDP ?

Is `6-bit NFC link-layer` the same as the `6-bit SSAP` discussed before ? I
guess so but I should not guess but be sure.

### Section 4.8

Is this section normative about multicast replication ?

### Section 5.1

```
   Two or more 6LNs may be connected with a 6LBR, but each connection
   uses a different subnet.
```
Unsure whether 'subnet' means 'IPv6 prefix' or 'link' ?

`the 6LBR MUST ensure address collisions do not occur` how can this goal be
achieved.


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


## COMMENTS

### Shepherd write-up

The write-up is incorrect about the downward reference as
https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ indicates RFC
3756 is a downref... Unsure whether this reference to RFC 3756 should be
normative though.

### IEEE 802.15.4

Should there be an informative reference to IEEE Std 802.15.4 ?

### Section 1

`NFC is often regarded as a secure communications technology, due to its very
short transmission range.` More explanations or even a reference would be
welcome.

### Section 3.2

Should 'reliable' be qualified ? E.g., does it mean no packet loss ?

```
   The LLCP to IPv6 protocol
   binding MUST transfer the Source Service Access Point (SSAP) and
   Destination Service Access Point (DSAP) value to the IPv6 over NFC
   protocol.
```
Should this be "to the IPv6 over NFS adaptation later" ?

### Section 4.4

There is text for "For sending Router Solicitations and processing Router
Advertisements" but what about "receiving RS and sending RA" ?

## NITS

### kbit/s or kbps

Select one unit and keep using it rather than changing during the document.

### Hexadecimal presentation

Most IETF drafts use 0x3f rather than 3Fh (really cosmetic). Section 3.4 uses
0x02. Suggest to be consistent.

### Section 4.2

I do not see the value of figure 2. Consider removing it.

### Section 4.3

Please use RFC 5952 for IPv6 address format.

## 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