Document: draft-ietf-intarea-proxy-config Title: Communicating Proxy Configurations in Provisioning Domains Reviewer: Daniele Ceccarelli Review result: Has Nits
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 _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
