Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. 

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.


- Document: draft-ietf-6man-ipv6-neighbor-discovery-yang-08

- Reviewer: Tina Tsou

- Review Date: 2026-09-09

- Intended Status: Proposed Standard

 
---

## Summary 

The document defines a useful YANG model for configuring and monitoring IPv6 Neighbor Discovery. I believe it has several operational issues that should be clarified before publication.

- Has Issues: I have some minor concerns about this document that I think should be resolved before publication.

Major comments

1. The redirect leaf defaults to false, while RFC 4861 Section 8.2 says that a router SHOULD send Redirect messages when the specified conditions apply. Please either align the default with RFC 4861 or document the operational and security rationale for choosing a different default.

2. The proxy-na leaf only enables or disables proxy Neighbor Advertisement. It does not identify the addresses or prefixes for which the device will proxy. Please clarify how proxy targets are selected, whether that configuration is intentionally outside this module, and what enabling the leaf does when no targets are configured.

3. The enhanced-dad/auto-resolve action is appropriate only for the trust model described in RFC 7527 Section 5. Please clarify the prerequisites, the scope and duration of blocking, and how service is restored. The Security Considerations should also explicitly discuss unauthorized or mistaken changes to enhanced-dad/enable and auto-resolve, since these actions could disrupt legitimate hosts.

Minor comment

The ND statistics use counter64, but the model does not identify when those counters may reset or which discontinuity indicator applies. Please define a local discontinuity timestamp or explicitly state whether the interface statistics discontinuity time applies.

Regards,
Tina Tsou