IETF Last Call Review of draft-ietf-intarea-proxy-config-13
review-ietf-intarea-proxy-config-13-opsdir-lc-ceccarelli-2026-05-11-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-intarea-proxy-config-13

- Reviewer: Daniele Ceccarelli

- Review Date: 10/05/2026

- Intended Status: Standards Track

---

## Summary

Choose one:

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

## General Operational Comments Alignment with RFC 5706bis

A few minor operational observations:

- The document correctly emphasizes that locally configured policy takes
precedence over dynamically learned policy. This is important to avoid
unintended proxy expansion in managed environments. - The recommendation to
ignore the entire proxy configuration when resource limits are exceeded is
operationally safe. Maybe, just a nice to have, implementations may benefit
from additional guidance regarding logging and telemetry visibility when such
conditions occur. - Large rule sets and frequent provisioning domain updates
may create operational scaling considerations on constrained devices. The
current text acknowledges this appropriately. - The requirement to use
different hosts for distinct PvD configuration domains is operationally
reasonable and avoids ambiguous policy association.

Also some nits:
- Terminology: The draft sometimes alternates between “proxy configuration”,
“proxy policy”, and “proxy information”. A slightly more consistent terminology
could improve readability. - One additional enterprise example could help
operational understanding.

And few typos:
- Section 2.1: “To allow clients to determine whether PvD Additional
Information is a DNS record...” Maybe something is missing? - Section 4:
“...with a set with exceptions to bypass:” Maybe "with a set of ?"

Thanks
Daniele