Document: draft-ietf-6man-ipv6-neighbor-discovery-yang-08
Title: YANG Data Model for IPv6 Neighbor Discovery
Reviewer: Carlos Pignataro
Review result: Ready with Issues

I am an assigned INT directorate reviewer for this document. These
comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat them like any
other Last Call comments. Details on the INT Directorate:
https://datatracker.ietf.org/group/intdir/about/.

Summary: A well-bounded YANG module filling a real gap in ND
configuration/management left uncovered by ietf-ip and
ietf-ipv6-router-advertisements. Appendix B's coverage table is
particularly useful. The comments below are all narrow and
self-contained.


Major:

1) Sec Cons seems to omit enhanced-dad/auto-resolve from the
writable-node sensitivity list. It's config tru e and triggers automated
blocking of host nodes on a detected duplicate --> a plausible attack
vector. It is mentioend in the readable-node para, but has higher risk.

Inclusive language:

- Sec 5: "man-in-the-middle attacks" --> flagged in IETF terminology
  guidance as gendered and imprecise; suggest "on-path attacker" or
  "adversary-in-the-middle" (also more accurate to the actual threat
  model here). No other instances of exclusionary terminology found.


Minor:

3) Sec 5 cites RFC 4252 (SSH Authentication Protocol) for the secure
transport layer; I believe that ought to be RFC 6242 (NETCONF over SSH)
and/or RFC 4253 (SSH Transport).

4) Appendix A's XML example uses "<n>eth0</n>"; the ietf-interfaces
key leaf is "name" (the JSON example right below it gets this right).


Nits:

- Sec 1.1: "term is defined" -> "terms are defined" (two items follow).
- Sec 1 vs Sec 2: "out of scope of" vs "outside the scope of" --
  pick one.
- Sec 2: "ietf-ip"[RFC8344] -- missing space before citation.
- Sec 2.1: "for IPv6 ND protocol" -> "for the IPv6 ND protocol".
- Sec 2.1: "each type of IPv6 ND messages" -- number mismatch.
- Sec 2.3/2.4: "configurations of"/for" -> singular "configuration".
- proxy-na leaf description is missing its subject ("Controls whether
  proxies for..." -> "Controls whether the router proxies for...").
- redirect / enhanced-dad "enable" leaf descriptions missing an
  article ("sending of" / "Enhanced DAD algorithm").
- auto-resolve leaf: "NS(DAD)" -> "NS (DAD)" for consistency with
  Sec 2.4 prose.
- Appendix A: "setting the leaf as N" -> "setting the leaf to N"
  (three instances).
- Module revision date (2026-04-20); consider a new revision statement.

I hope these comments are clear nad useful!

Best,

Carlos.