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