IETF Last Call Review of draft-ietf-savnet-intra-domain-problem-statement-21
review-ietf-savnet-intra-domain-problem-statement-21-opsdir-lc-xie-2026-03-06-00

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-savnet-intra-domain-problem-statement-21]

- Reviewer: [Chongfeng Xie]

- Review Date: [March 6, 2026]

- Intended Status: [Informational]

---

## Summary

- Has Nits: This document is basically ready for publication but has nits that
should be considered prior to publication.

This document provides a gap analysis of existing intra-domain source address
validation mechanisms, describes the fundamental problems, and defines the
basic requirements for technical improvements.

## General Operational Comments Alignment with RFC 5706bis

Provide an overview of the draft’s operational feasibility, readability, and
alignment with RFC5706bis guidelines. Example:

> Since this draft only identifies the problems and illustrates requirements of
SAV in Intra-domain Networks, I don't think a specific section of "Operational
Considerations" is needed.

---

## Minor Issues

List non-blocking but important clarifications (e.g., ambiguous terminology or
incomplete examples).

> In section 3.1, says "The main drawback of ACL-based SAV is its high
operational overhead.",   I think the the main drawback of ACL-based SAV is
that it is difficult to adapt to external changes in a timely manner, so I
think it can be changed.

> Strictly speaking, ACL is not an SAV mechanism because it cannot determine
the authenticity of the source address by itself, so I suggest to add the
following sentence at the end of section 3.2.
       "Since ACL can’t determine the authenticity of the source address of
       each packets by itself, it has very limited SAV capabilities in this
       case."

> Complexity issue should also be considered for designing new intra-domain SAV
mechanism, so I propose the followng text for section 5,

"Manageable complexity
The new intra-domain SAV mechanism SHOULD not add excessive complexity to
network management and operation, otherwise it can not be implemented in
practical networks."

> For section 5.5, since SAVNET itself is security matter, the current title,
i.e.,“Security” is too general, it is better to use a more accurate title, such
as“Vulnerability Prevention”.

---

## Nits

> In section 6, "informational requirements"--->"requirements"

> Section 1: “access-network” -> “access network”

> "AS" and "domain" are both used in the following sentence, I guess they refer
to the same thing, and suggest to replace "domain" with "AS".
    “At external interfaces facing external ASes: Prevent those ASes from
    injecting packets with internal-use-only source addresses into the domain”

No other issues or nits found.

Thank you.

Best regards
Chongfeng