Éric Vyncke's No Objection on draft-ietf-6man-grand-05: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-6man-grand-05: No Objection

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


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



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

Thank you for the work put into this document. It is a VERY useful
specification! The doc is also easy to read.

Special thanks for the doc shepherd write-up about the WG process / consensus.

Other thanks to Carles Gomez for the IoT directorate review at:
https://mailarchive.ietf.org/arch/msg/iot-directorate/cKVAO13tZw-AHhOtW4-tJhr6_rM/
and to Jen for addressing Carles' comments. Even, if RFC 8505 could be another
solution if widely implemented (section 8.2).

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits. PLEASE act on my comment on section 6.1.2 (I was
about to raise a trivial-to-address DISCUSS).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
Just to be clear s/This document updates the Neighbor Discovery protocol/This
document updates the Neighbor Discovery protocol [RFC 4861]/

-- Section 2 --
In the 2. bullet, does the host need to also have the "default router
link-local" ? I would assume link-layer would be enough (no need to do NUD at
the beginning ?)

In the description, should the "host" rather be a "node" (i.e., possibly having
a router role) ?

Should "If the host sends multiple probes in parallel" be more detailed by
adding "to multiple destinations" ?

-- Section 4.1 --
The amount of mcast traffic is even reduced in the sense that less nodes are
receiving the NA/NS traffic (in this I-D only routers else all nodes).

-- Section 5.2 --
Humm I do not fully agree with the last part of the section "However most
likely those packets...address resolution is completed.". The optimistic DAD
node will indeed receive the already-queued packets so I do to really
understand the part "dropping subsequent packets" as those packets would have
been dropped anyway. Nothing dramatic but I wonder whether a rephrase would
help here.

-- Section 5.3 --

Should the 1. also includes NC entries that have expired ? Should
'communication' be qualified as on-link or not on-link ?

s/rightful owner/original owner/ because the first owner could actually be an
attacker ;-)

-- Section 5.3.2 --
s/The router receives the return traffic flows for both the rightful owner of
the duplicated address and the new host. /The router receives the return
traffic flows for the IPv6 addressed shared by the rightful owner of the
duplicated address and the new host. / ?

-- Section 6 --
This section is only about routers but the nodes behavior must also be changed
to send unsollicited NA. Where is it specified ?

-- Section 6.1.1 --
What should the router do if not discarding in "SHOULD be silently discarded."
(last sentence)

-- Section 6.1.2 --
A trivial DISCUSS level but trusting Jen to fix it: missing the end of the NEW
text as a line of dashes ;-)

How can a node execute "A node may also wish to notify its first-hop routers" ?

I wonder why some text is about "new global IPv6 address" in the replaced text
about for anycast. I can only guess that it is not applicable to anycast but to
all type of addresses. So, strongly suggest to move the part "A node may
also...to preferred" *before* the § about anycast.

-- Section 8.3 --
s/default router/first-hop routers/ ?

-- Section 8.6 --
I wonder how many of the enumerated drawbacks also apply to this
specification... (except for generating the ICMP echo reply). But, it has the
advantage of requiring only host changes.

-- Section 8.9 --
s/When a router receives a transit packet/When a router receives a transit
packet sourced by a on-link neighbor node/

-- Section 10 --
About "disclosed via DAD to all nodes anyway", actually DAD is sent to the
sollicited-node mcast address and not all nodes/routers.

== NITS ==

"Therefore", ".e.g.", "So", "Otherwise", and "However" are usually followed by
a comma as I learned from RFC Editor ;-)

s/can not/cannot/