Communicating Proxy Configurations in Provisioning Domains
draft-ietf-intarea-proxy-config-14

[Ballot comment]
Hi all,

The discussion revealed that the intended applicability scope is even more than I got when first reviewing the document. This claims to cover discovery of any proxy (including proxies that are widely deployed out there such SIP proxies and for which there are alrady plenty discovery mechanisms). I’m concerned as this is adding duplicated functionality, not backed by real operational problems/needs. I’m more concerned that we are adding a duplicated mechanism for the discovery of these mechanisms using a tool that is not deployed today (PvD).

Cheers,
Med

(*) My previous ballot: https://mailarchive.ietf.org/arch/msg/int-area/hwQi9ThqisyEAANJJHx6ywCGSUw/

[Ballot comment]
Thank you authors for the revisions. I appreciate the elimination of two of the three conditions (especially user permission), and your explanation of what you meant by configuration. I notice the new text also narrows the enterprise case in description to its intended limited use case with managed endpoints and networks. With this in place, any further changes I would ask for would be preference only.

With this out of the way, I return to my position on the rest of the document: highly valuable for addressing a long-running problem space in configuring proxies.

[Ballot discuss]
Thank you for your work Dragana, Tommy, and Yaroslav. I do think this is an important document and want to see it progress, as it will provide a solution to a long-deficient problem space. However, after lots of re-reading, I do not think it is ready for publication in its current state. Like Mahesh, I am not comfortable with Section 5.

My review procrastination paid off, as I am balloting in response to your on-list response to Mahesh to provide specific guidance to hopefully accelerate the discussion: no, at least for me, declaring automatic use out of scope does not help because the approaches to manual use don't alleviate the lack of experience or analysis for a Proposed Standard:

1) Not explicit configuration (of the proxy specifically I assume is what this means, then discovery wasn't needed),

2) Not policy (config to generally opt into automatically using discovered proxies I assume is what this means, which is exactly against the MUST with no explanation as to why that would be acceptable),

3) Not user permission (what average user understands the implications of what they are approving if we as the SDO publishing the document do not).

I believe at this moment that the best course of action would be to keep this document as PS and drop discovery from network PvDs altogether and leaving for a second document to either be Experimental or do the needed leg work to threat model. The easiest way I can see to do that is to boil down Section 5 to something like this:

>  [PVDDATA] defines how PvD Additional Information is discovered based
>  on network advertisements using Router Advertisements [RFC4861].  A
>  network defining its configuration via PvD information could
>  theoretically include the proxies key (Section 3). However, doing so
>  to inform clients of a list of proxies available on the network is
>  beyond the scope of this document.  Client systems MUST NOT use such
>  proxy information unless doing so as defined by another standard.

Even the hint that this could be used to filter from an already configured list of proxies... do we fully understand the security properties of that either? Sure, it doesn't change destinations to an untrusted one, but if there were N proxies pre-defined out of band for a large set of clients, and a malicious PvD convinces them to all use only 1 of the N, have we introduced a lower barrier-to-entry DDoS attack vector? Hence I think this mechanism just needs to be removed with no suggestions about potential uses.

Alternatively, we "do it right" so that this document can define proper security considerations and trust model with good normative guidance for doing local network discovery (which I think should happen!). I think this will take far longer than warrants holding up the rest of this document, which I think could be published then become a clean normative dependency of a new draft that did nothing but local network discovery. said new draft could reference this document heavily, and could rapidly publish as an Experiment if deployment for data analysis is preferred over more document drafting.

Another alternative of course is to downgrade this entire document to Experimental. I think that would be a waste of the rest of the document which, modulo other more minor changes, seems to be PS material.

I'm open to other suggestions of course. Just trying to be verbose and carry this topic forward from the last review/response on the same topic.

[Ballot comment]
Minor typo, in two places in Section 1.1: s/Javascript/JavaScript/

In Section 3.2:

>  A proprietary key MUST contain at least one underscore character
>  ("_").  The right-most underscore serves as a separator between a
>  vendor-specific namespace and the key name, i.e. the string to the
>  right of the right-most underscore is the key name and the string
>  left from the underscore specifies the vendor-specific namespace.

The final use of "underscore" is missing the "right-most" modifier needed since multiple underscores are possible.

[Ballot discuss]
I believe the following are straightforward to address.

Section 3.1
"Extensions to proxy types that use the same HTTP Upgrade Tokens ought to be covered by the same protocol value"

s/ought/SHOULD, and add conditions under which is it acceptable to do otherwise.


"Proxies with identifier keys are expected to accept only traffic matching rules in the proxy-match array and SHOULD NOT be used if they are not included in the proxy-match array."

The meaning of this sentence is not clear to me. Proxies are the subject of the first part, but traffic appears to be the subject of the second part? Perhaps it could be reworded as follows:

"Proxies with identifier keys are expected to accept only traffic that matches the rules in the proxy-match array and SHOULD NOT accept traffic that does not not match the rules in the proxy-match array."

or

"Proxies with identifier keys are expected to accept only traffic that matches the rules in the proxy-match array. Client SHOULD NOT use proxies for traffic that does not match the rules in the proxy-match array."

Justification for these being SHOULD NOT rather than MUST NOT is needed as well.


Section 4.2
"If earliest matching rule has empty array of proxies client SHOULD NOT send matching traffic to any proxy defined in this PvD."

s/proxies client/proxies, a client

Justification for this being a SHOULD NOT rather than a MUST NOT is needed as well.

[Ballot comment]
I have some non-blocking COMMENTS that I would like the authors to consider as well.

Section 2.
The term "PvD Additional Information" is used here. I eventually realized it is defined  RFC 8801 and is short for "Provisioning Domain Additional Information". It would be helpful to expand the information in Section 1 to make this association clear.


"A new Sequence Number for that PvD is received in a Router Advertisement (RA)"
A reference to [PVDDATA] would be helpful here.

Section 3.1
"The value of the mandatory key is an array of keys that the client must understand and process to be able to use the proxy."

s/must/MUST

NITS
Section 1.
"which can include proxy configuration details Section 2 of [PVD]."

s/details Section 2/details, per Section 2

Section 4.2
"If a matching rule contains more than one identifier the client MUST treat the array as an ordered list"

s/identifier the client/identifier, the client

[Ballot comment]
# IESG review of draft-ietf-intarea-proxy-config-11

CC @MikeBishop

## Comments

### Section 3, paragraph 3
```
    client can attempt to fetch the PvD information from the well-known
    URI to learn the list of complete URIs that support non-default
```
Consider making "the well-known URI" less ambiguous. "...can attempt to fetch
the PvD information from the '/.well-known/pvd' path on the configured proxy to
learn..."

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2.1, paragraph 2
```
-    Presence of this SvcParamKey, named pvd indicates that the proxy host
+    Presence of this SvcParamKey, named pvd, indicates that the proxy host
+                                          +
```

#### Section 3.1, paragraph 13
```
-    The value of identifier key is a string that can be used to refer to
+    The value of the identifier key is a string that can be used to refer to
+                ++++
```

[Ballot discuss]
Hi Tommy, Dragana, and Yaroslav,

Thank you for the effort put into this document.

Please find some points for discussion below:

# IETF LC Comments

Unless I’m mistaken, there was no discussion/follow-up to the comments received during IETF LC.

I have delayed my review with the hope to see a new version.

# Applicability Scope & Target Deployment

I appreciate that the document includes the following:

  Additionally, this document outlines how these mechanisms might be
  used to discover proxies associated with a network (Section 5).
  However, this approach is not described for the purpose of generic
  proxy discovery, and requires careful security considerations for
  clients to limit usage to trusted scenarios.

However, it is not clear the target protocols and the conditions under which this can be used.

The examples are more about HTTP, but still there is no explicit discussion about target deployment. Please consider clarifying the scope and target deployment.

# Partial Solution

CURRENT:
  The mechanisms defined in this document are intended to offer a
  standard alternative that works for URI-based proxies and avoids
  dependencies on executing Javascript scripts, which are prone to
  implementation-specific inconsistencies and can open up security
  vulnerabilities.

However, the alternative design proposed in this document does only provide a partial solution as it relies on RFC 8801. This can be seen as encouraging fragmented solutions with the inherit implications on deployment (including selection when several mechanisms as supported by a client: which one has higher priority, etc.).

The document lacks a discussion about operational constraints/limits, including a discussion about how IPv4/IPv6 feature parity can be provided.

# DNS Dependency

CURRENT:
  Presence of this SvcParamKey, named pvd indicates that the proxy host
  supports PvD discovery via the well-known PvD URI ".well-known/pvd"
  defined in Section 4.1 of [PVDDATA].  The presence of this key in an
  HTTPS or SVCB record signals that the proxy's PvD Additional
  Information can be fetched using the "https" scheme from the proxy
  host on port 443 using the well-known path.  The presentation and
  wire-format values for pvd SvcParamKey MUST be empty.

How this works for private proxies for which there is no record in the public DNS? Wouldn’t this be problematic especially in cases where resolvers supplied by the PvD access network are not used to resolve the name?

Unless I’m missing something the usefulness of these attributes depends on the underlying setup. These assumptions (and implications) should be described.

# CIDR

CURRENT:
  The subnets array includes IPv4 and IPv6 address literals, as well as
  IPv4 and IPv6 address subnets written using CIDR notation [CIDR].

CIDR is normative for subnet attribute. Please move that ref to Normative.

# Inappropriate Uses of Key Words

Several parts of IANA section include normative language such as in:

CURRENT:
  New assignments in the "Proxy Information PvD Keys" registry will be
  administered by IANA through Expert Review [RFC8126].  Experts are
  requested to ensure that defined keys do not overlap in names or
  semantics, do not contain an underscore character ("_") in the names
  (since underscores are reserved for vendor-specific keys), and have
  clear format definitions.  The reference and notes fields MAY be
  empty.

The use of key words is not compliant with https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/. Please fix. Thanks.

[Ballot comment]
# Upgrade

CURRENT:
  Using this mechanism a client can learn that a legacy insecure HTTP
  proxy that the client is configured with is also accessible using
  HTTPS.

Can’t this be done by leveraging existing SVCB records (i.e., without the pvd keys)?

# Mixing Protocol and Operational considerations

There are several places where deployment considerations are mixed with protocol matters. For example,

CURRENT:
  Note that all proxies that are co-located on the same host share the
  same PvD Additional Information.  Proxy deployments that need
  separate PvD configuration properties MUST use different hosts.

Better to have these grouped into a dedicated Operational Considerations section.

# Mandatory keys

CURRENT:
  PvD Additional Information is required to contain the "identifier",
  "expires", and "prefixes" keys. 

Please consider citing rfc8801#section-4.3

# Discovering proxies from network PvDs

## I suggest to place this section under an Operational Considerations Section.

## BTW, can this part be expanded to elaborate which specific aspects need more exploration and how the lack thereof is a hinderance for deployment:

CURRENT:
  Further security and experience considerations are needed for these
  cases.

## Please consider reminding that OSP cons in rfc8801#section-5 apply.

# [IANA_PVD] and [IANA_SVCB]

CURRENT:
  This document registers two new keys in the "Additional Information
  PvD Keys" registry [IANA_PVD].

  ..
  IANA is requested to add a new entry to the "DNS SVCB Service
  Parameter Keys (SvcParamKeys)" registry [IANA_SVCB]:

I think both should be listed as Informative, not Normative.

Cheers,
Med

[Ballot discuss]
Section 3.1, paragraph 5
>      +===============+===========+===============+===================+
>      | Proxy        | Proxy    | Reference    | Notes            |
>      | Protocol      | Location  |              |                  |
>      |              | Format    |              |                  |
>      +===============+===========+===============+===================+
>      | socks5        | host:port | [SOCKSv5]    |                  |
>      +---------------+-----------+---------------+-------------------+
>      | http-connect  | host:port | Section 9.3.6 | Standard CONNECT  |
>      |              |          | of [HTTP]    | method, using    |
>      |              |          |              | unencrypted HTTP  |
>      |              |          |              | to the proxy      |
>      +---------------+-----------+---------------+-------------------+
>      | https-connect | host:port | Section 9.3.6 | Standard CONNECT  |
>      |              |          | of [HTTP]    | method, using    |
>      |              |          |              | TLS-protected    |
>      |              |          |              | HTTP to the proxy |
>      +---------------+-----------+---------------+-------------------+
>      | connect-udp  | URI      | [CONNECT-UDP] |                  |
>      |              | template  |              |                  |
>      +---------------+-----------+---------------+-------------------+
>      | connect-ip    | URI      | [CONNECT-IP]  |                  |
>      |              | template  |              |                  |
>      +---------------+-----------+---------------+-------------------+
>      | connect-tcp  | URI      | [CONNECT-TCP] |                  |
>      |              | template  |              |                  |
>      +---------------+-----------+---------------+-------------------+
>
>            Table 2: Initial PvD Proxy Protocol Registry Contents

This table includes connect-tcp with a reference to draft-ietf-httpbis-connect-tcp.
The Shepherd's writeup notes that the draft shows "Revised-ID needed" status.
This document's IANA registrations will create a permanent registry entry citing
an I-D that may not be published as an RFC by the time this document is.
The registry will then permanently point to a document in an uncertain state.

Can the authors/AD confirm CONNECT-TCP will be published concurrently or has
resolved its "Revised I-D needed" status?

Section 5, paragraph 2
>    Further security and experience considerations are needed for these
>    cases.

This is an explicit acknowledgment in a Standards Track document that a
defined mechanism is underspecified from a security standpoint. The proxy
discovery via network PvDs path is included in scope (it is one of the
three numbered mechanisms in the Introduction), yet it has no completed
security analysis. A MUST NOT against autonomous use is present
(Section 5, paragraph 2), but without the security considerations that
would inform when this mechanism is safe to enable at all, the mechanism
is effectively undefined for deployment.

The authors should either: (a) complete the security considerations for
Section 5, or (b) explicitly move Section 5 to an informational/future-work
section and remove it from the scope of the Standards Track normative text.

[Ballot comment]
Section 3, paragraph 0
>    This document defines a new PvD Additional Information key, proxies,
>    that is an array of dictionaries, where each dictionary in the array
>    defines a single proxy that is available as part of the PvD (see
>    Section 7.1).  Each proxy is defined by a proxy protocol and a proxy
>    location (i.e., a hostname and port or a URI template [URITEMPLATE]),
>    along with other optional keys.

The top-level PvD key that lists proxy definitions is named proxies.
The key within each destination rule that references proxy identifiersis also
named proxies (Section 4). These are two different keys in two different contexts —
one is an array of proxy dictionaries, the other is an array of identifier strings —
but they share the same JSON key name. The examples require careful reading to
distinguish them, and the GenArt reviewer flagged general terminology clarity issues.
A name like proxy-ids or proxy-refs for the destination rule key would remove this
ambiguity.

Section 4.2, paragraph 1
>    The destination rules can be used to determine which traffic can be
>    sent through proxies, and which specific set of proxies to use for
>    any particular connection.  By evaluating the rules in order, a
>    consistent behavior for usage can be achieved.

This section describes the priority ordering and matching semantics,
but does so in prose across several paragraphs. For a mechanism intended
to influence traffic routing decisions in security-sensitive contexts,
a step-by-step normative algorithm (even if presented as a numbered list)
would improve interoperability and reduce implementation divergence.
The current prose leaves edge cases implicit.

[Ballot comment]
Thanks to Chris Lonvick for their secdir review.  It would be good if that review was considered (I see no response on the list).

I support Chris Inacio's Discuss - especially about including RFC 8801 in Sec Considerations.

Section 5:  What does this mean?  "Further security and experience considerations are needed for these cases."

Privacy Considerations:  RFC 8801 has quite a robust Privacy Consideration section.  Does any of that apply here?

Section 8.1, Normative References:  Classically, references to IANA registries are Informative. [IANA_PVD] and [IANA_SVCB]

[Ballot discuss]
* First one is focused on the lack of quote/brackets/something that separates the names of keys in the text from the surrounding exposition.  It makes various parts of the document nigh impossible to read without 2-3 takes, unnecessarily. 
* The SECURITY CONSIDERATIONS must at least include reference / inclusion of the SECURITY CONSIDERATIONS of RFC8801 which has a much better discussion of protection of RAs, 802.1x, etc.
* Can you address the resource exhaustion issue?  Is that a SECURITY CONSIDERATION addition possibly or is there a sane constraint on the number of proxies that might be defined; what is a practical limit to send to a client to process?

[Ballot comment]
* I wonder about this paragraph:
  > Using this mechanism a client can learn that a legacy insecure HTTP
  >  proxy that the client is configured with is also accessible using
  >  HTTPS.  In this way, clients can upgrade to a more secure connection
  >  to the proxy.
  >
  how would that work?  by definitiion the client is accessing an unverified/**insecure** resource - should the client bother to trust that insecure proxy to direct it to a “secure” proxy?  It can’t be both insecure and trustworthy, can it?
* WPAD (while non-stanard, although supported very widely) has multiple mechanisms to find the PAC, according to RFC3040, (the text in the draft doesn’t make it seem that way):
  * DHCP (mentioned here)
  * SLP
  * “Well Known Alias” in DNS A record
  * DNS SRV record
  * “service: URLs” in DNS TXT records
* As mentioned in the GENART review is the “well-known” address “/.well-known/…” and not “.well-known” per [PVDDATA]?
* Section 2.1
  > Presence of this SvcParamKey, named pvd indicates that the proxy host
  >  supports PvD discovery via the well-known PvD URI ".well-known/pvd"
  >  defined in Section 4.1 of [PVDDATA].
  * Is “pvd” the key in the above?  Should it be quoted?
* Section 3
  > This document defines a new PvD Additional Information key, proxies,
  >  that is an array of dictionaries, where each dictionary in the array
  >  defines a single proxy that is available as part of the PvD (see
  >  Section 7.1).
  * this is slightly more clear than the key presented in 2.1, but a consistent style (quotes, some other marks, commas) would make this easier and more clear to read
  * I know that “proxies” is the key here
  * then the following paragraph is soooo overloaded with proxy/proxies that it seems dangerous:
  > When a PvD that contains the proxies key is fetched from a known
  >  proxy using the method described in Section 2, the proxies array
  >  describes equivalent proxies (potentially supporting other protocols)
  >  that can be used in addition to the known proxy.
* Section 3.1
  > The value of the mandatory key is an array of keys that the client
  >  must understand and process to be able to use the proxy.  A client
  >  that does not understand a key from the array or cannot fully process
  >  the value of a key from the array MUST ignore the entire proxy
  >  dictionary.
  * I didn’t understand this paragraph at all until I understood “mandatory” here is the name of a key, not a required to exist key.  You must fix that.
* Section 3.1
  * Is there a limit to how big a proxy dictionary can be presented / created?
  * If I create 10 billion entries with “identifier”s that will *never* be used, is that a problem?
* Section 4.1
  > For example, "1024-2048"
  >    matches all ports from 1024 to 2048, including the 1024 and 2048.  If
  >    ports key is not present, all ports are assumed to match.  The array
  >    may contain individual port numbers (such as "80") or inclusive
  >    ranges of ports.  For example, "1024-2048" matches all ports from
  >    1024 to 2048, including the 1024 and 2048.
  * this is repetitive and can be reduced.
* Do proprietary keys require anything more than an underscore “_”?  Is just simply having “_” valid?  Is the requirement at least one UTF-8 character before and after the “_”?


* NITS
  * with the proxy to optimize their proxy usage, such knowing
    that a proxy is configured
    …usage, such _as_ knowing that…

[Ballot comment]
Thanks for this draft - which ought to prove very useful.

NiTs:
I expected a sentence to explain  “.well-known”: e.g., “The .well-known directory, or specifically the .well-known URI prefix, is defined by the Internet Engineering Task Force (IETF) in RFC 8615”

Section 1: After “(Section 2)” insert a period, to be consistent with other items in the list. (Similarly please check other lists for the same issue. In section 3.1, only one item has punctuation after the list item and uses a comma. See also the list in section 4.4)

Many thanks for the TSVART Revoew.Please note and respond to the review.

[Ballot comment]
Thanks for this draft - which ought to prove very useful.

NiTs:
I expected a sentence to explain  “.well-known”: e.g., “The .well-known directory, or specifically the .well-known URI prefix, is defined by the Internet Engineering Task Force (IETF) in RFC 8615”

Section 1: After “(Section 2)” insert a period, to be consistent with other items in the list. (Similarly please check other lists for the same issue. In section 3.1, only one item has punctuation after the list item and uses a comma. See also the list in section 4.4)

I am also waiting for tsvart review, which may update my position.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-intarea-proxy-config-11. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are five actions which we must complete.

First, in the Additional Information PvD Keys registry in the Provisioning Domains (PvDs) registry group located at:

https://www.iana.org/assignments/pvds/

two new registrations are to be made as follows:

JSON Key: proxies
Description: Array of proxy dictionaries associated with this PvD
Type: Array of dictionaries
Example: [
{
"protocol": "connect-udp",
"proxy": "https://proxy.example.org/masque{?target_host,target_port}"
}
]
Reference: [ RFC-to-be ]

JSON Key: proxy-match
Description: Array of proxy match rules, as dictionaries, associated with entries in the proxies array.
Type: Array of dictionaries
Example: [
{
"domains": [ "*.internal.example.org" ],
"proxies": [ "default_proxy" ]
}
]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the Proxy Information PvD Keys registry. The new registry will be located in the Provisioning Domains (PvDs) registry group located at:

https://www.iana.org/assignments/pvds/

The new registry will be managed via Expert Review as defined by [RFC8126].

There are initial registrations in the new registry as follows:

JSON Key Optional Description Type Example
protocol No The protocol used to communicate with the proxy String "connect-udp"
proxy No String containing the URI template or host and port of the proxy, depending on the format defined by the protocol String "https://example.org:4443/masque/{?target_host,target_port}"
mandatory Yes An array of optional keys that client must understand and process to use this proxy Array of Strings ["example_key"]
alpn Yes An array of Application-Layer Protocol Negotiation protocol identifiers Array of Strings ["h3","h2"]
identifier Yes A string used to refer to the proxy, which can be referenced by other dictionaries, such as entries in proxy-match String "udp-proxy"

Each of these five registrations will have a reference of [ RFC-to-be ].

Third, a new registry is to be created called the Proxy Protocol PvD Values registry. The new registry will be located in the Provisioning Domains (PvDs) registry group located at:

https://www.iana.org/assignments/pvds/

The new registry will be managed via Expert Review as defined by [RFC8126].

There are initial registrations in the new registry as follows:

Proxy Protocol Proxy Location Format Reference Notes
socks5 host:port [SOCKSv5]
http-connect host:port [RFC9110,Section 9.3.6] Standard CONNECT method, using unencrypted HTTP to the proxy
https-connect host:port [RFC9110,Section 9.3.6] Standard CONNECT method, using TLS-protected HTTP to the proxy
connect-udp URI template [RFC9298]
connect-ip URI template [RFC9484]
connect-tcp URI template [CONNECT-TCP]

Fourth, a new registry is to be created called the Proxy Destination Rule PvD Keys registry. The new registry will be located in the Provisioning Domains (PvDs) registry group located at:

https://www.iana.org/assignments/pvds/

The new registry will be managed via Expert Review as defined by [RFC8126].

There are initial registrations in the new registry as follows:

JSON Key Optional Description Type Example
proxies No An array of strings that match identifier values from the top-level proxies array Array of Strings ["tcp-proxy", "udp-proxy"]
domains Yes An array of FQDNs and wildcard DNS domains Array of Strings ["www.example.com", "*.internal.example.com"]
subnets Yes An array of IPv4 and IPv6 addresses and subnets Array of Strings ["2001:db8::1", "192.0.2.0/24"]
ports Yes An array of TCP and UDP port ranges Array of Strings ["80", "443", "1024-65535"]

Each of these four registrations will have a reference of [ RFC-to-be ].

Fifth, in the DNS SVCB Service Parameter Keys (SvcParamKeys) registry in the DNS Service Bindings (SVCB) registry group located at:

https://www.iana.org/assignments/dns-svcb/

a single new registration will be made as follows:

Number: [ TBD-at-Registration ]
Name: pvd
Meaning: PvD configuration is available at the well-known path
Change Controller: IETF
Reference: [ RFC-to-be; Section 2.1 ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-03-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-intarea-proxy-config@ietf.org, evyncke@cisco.com, int-area@ietf.org, intarea-chairs@ietf.org, marcus.ihlar@ericsson.com, meral.shirazipour@ericsson.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Communicating Proxy Configurations in Provisioning Domains) to Proposed Standard


The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document: - 'Communicating Proxy
Configurations in Provisioning Domains'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-03-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a mechanism for accessing provisioning domain
  information associated with a proxy, such as other proxy URIs that
  support different protocols and information about which destinations
  are accessible using a proxy.

Discussion Venues

  This note is to be removed before publishing as an RFC.

  Source for this draft and an issue tracker can be found at
  https://github.com/tfpauly/privacy-proxy.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-intarea-proxy-config/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is relatively broad consensus. However, due to the nature of the working group
several people also remain silent.
It should be noted that some reviews of version-09 are still outstanding at the time
of editing this writeup. While these reviewers are positive to progressing this draft
they provide valuable feedback that should be addressed prior to that.

https://mailarchive.ietf.org/arch/msg/int-area/eeKJThJERbakBgSgPIpQLWEo8hE/
https://mailarchive.ietf.org/arch/msg/int-area/0sStVJ_mGVu4XygRhEJZi-nQ6ZY/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

I did not notice anything particularly controversial, beyond regular technical
feedback.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

Not to my knowledge.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

From last call discussion:
"Apple has an implementation of both client and server side.
Few other vendors have implementations of the server side."

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document reuses and extends several technologies. Some are defined in intarea
such as Provisioning Domains, PvD Additional Information format.
It is tightly related to technologies developed in the Masque and HTTP working groups,
(CONNECT, connect-X ..)and there has been some cross-posting to the masque-wg mailing
list and presentations at Masque WG sessions. There have not been any directorate reviews
though. 

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
n/a

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
n/a
8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
n/a

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all, except for the last point. As stated above, there are a couple of
outstanding reviews that should be addressed first prior to handing off to the
responsible AD. If the authors feel that they're already addressed it would be
good to see some indication of that on the mailing list.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document touches upon several expert topics, but there is mostly standard
use.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This seems correct since it builds upon well-specified technologies
and has normative requirements for interoperability.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All authors have indicated that they are not aware of any undisclosed IPRs.
Public mailing-list call is ongoing until February 6.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID-nits:
identified the use of the IPv4 string 192.168.0.0 and suggests to change it to the
192.0.2.0/24 ranges.
The table in section 3.1 is too wide in the rendered txt.

Additional nits:

The term Proxy Definition is used a few times in the document, but it's
only implicitly introduced in section 3, and it's used interchangeably
with the term proxy dictionary. 

Section 3:
Paragraph 2 refers to the proxies list. The previous section defines
it as an array which seems to be the correct JSON terminology.

Section 3.1 last paragraph has a somewhat clunky sentence:
"Identifier values MAY be duplicated across different proxy dictionaries in the
proxies array, which indicates that all references from other dictionaries to a
particular identifier value apply to all matching proxies."

I'd suggest something more compact e.g.,:
"Identifier values MAY be duplicated across different proxy dictionaries in the proxies array.
References to a particular identifier apply to the set of proxies sharing that identifier."



15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
None that I have identified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
no.
17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
no
18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There is a normative reference to draft-ietf-httpbis-connect-tcp. That draft
has been through WGLC in HTTPbis once and its current state is Revised-ID needed.
A new version was recently published.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Registers two new entries in the "Additional Information PvD Keys" registry.
The registry is clearly identified. The registrations are consistent with the
text in the body.

Registers one new entry in "DNS SVCB Service Parameter Keys (SvcParamKeys)".
The registry is clearly identified and the registration is consistent with the
text in the body (section 2.1).

Two new registries are requested: "Proxy Protocol PvD Values" &
"Proxy Destination Rule PvD Keys". Both are appropriately named and have initial
contents specified. Both require expert review for assignments.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

"Proxy Protocol PvD Values", "Proxy Destination Rule PvD Keys".
Clear instructions to designated expert in both cases.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is relatively broad consensus. However, due to the nature of the working group
several people also remain silent.
It should be noted that some reviews of version-09 are still outstanding at the time
of editing this writeup. While these reviewers are positive to progressing this draft
they provide valuable feedback that should be addressed prior to that.

https://mailarchive.ietf.org/arch/msg/int-area/eeKJThJERbakBgSgPIpQLWEo8hE/
https://mailarchive.ietf.org/arch/msg/int-area/0sStVJ_mGVu4XygRhEJZi-nQ6ZY/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

I did not notice anything particularly controversial, beyond regular technical
feedback.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

Not to my knowledge.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

From last call discussion:
"Apple has an implementation of both client and server side.
Few other vendors have implementations of the server side."

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document reuses and extends several technologies. Some are defined in intarea
such as Provisioning Domains, PvD Additional Information format.
It is tightly related to technologies developed in the Masque and HTTP working groups,
(CONNECT, connect-X ..)and there has been some cross-posting to the masque-wg mailing
list and presentations at Masque WG sessions. There have not been any directorate reviews
though. 

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
n/a

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
n/a
8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
n/a

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all, except for the last point. As stated above, there are a couple of
outstanding reviews that should be addressed first prior to handing off to the
responsible AD. If the authors feel that they're already addressed it would be
good to see some indication of that on the mailing list.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document touches upon several expert topics, but there is mostly standard
use.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This seems correct since it builds upon well-specified technologies
and has normative requirements for interoperability.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All authors have indicated that they are not aware of any undisclosed IPRs.
Public mailing-list call is ongoing until February 6.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID-nits:
identified the use of the IPv4 string 192.168.0.0 and suggests to change it to the
192.0.2.0/24 ranges.
The table in section 3.1 is too wide in the rendered txt.

Additional nits:

The term Proxy Definition is used a few times in the document, but it's
only implicitly introduced in section 3, and it's used interchangeably
with the term proxy dictionary. 

Section 3:
Paragraph 2 refers to the proxies list. The previous section defines
it as an array which seems to be the correct JSON terminology.

Section 3.1 last paragraph has a somewhat clunky sentence:
"Identifier values MAY be duplicated across different proxy dictionaries in the
proxies array, which indicates that all references from other dictionaries to a
particular identifier value apply to all matching proxies."

I'd suggest something more compact e.g.,:
"Identifier values MAY be duplicated across different proxy dictionaries in the proxies array.
References to a particular identifier apply to the set of proxies sharing that identifier."



15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Registers two new entries in the "Additional Information PvD Keys" registry.
The registry is clearly identified. The registrations are consistent with the
text in the body.

Registers one new entry in "DNS SVCB Service Parameter Keys (SvcParamKeys)".
The registry is clearly identified and the registration is consistent with the
text in the body (section 2.1).

Two new registries are requested: "Proxy Protocol PvD Values" &
"Proxy Destination Rule PvD Keys". Both are appropriately named and have initial
contents specified. Both require expert review for assignments.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

"Proxy Protocol PvD Values", "Proxy Destination Rule PvD Keys".
Clear instructions to designated expert in both cases.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is relatively broad consensus. However, due to the nature of the working group
several people also remain silent.
It should be noted that some reviews of version-09 are still outstanding at the time
of editing this writeup. While these reviewers are positive to progressing this draft
they provide valuable feedback that should be addressed prior to that.

https://mailarchive.ietf.org/arch/msg/int-area/eeKJThJERbakBgSgPIpQLWEo8hE/
https://mailarchive.ietf.org/arch/msg/int-area/0sStVJ_mGVu4XygRhEJZi-nQ6ZY/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

I did not notice anything particularly controversial, beyond regular technical
feedback.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

Not to my knowledge.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Pending.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document reuses and extends several technologies. Some are defined in intarea
such as Provisioning Domains, PvD Additional Information format.
It is tightly related to technologies developed in the Masque and HTTP working groups,
(CONNECT, connect-X ..)and there has been some cross-posting to the masque-wg mailing
list and presentations at Masque WG sessions. There have not been any directorate reviews
though. 

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
n/a

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
n/a
8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
n/a

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all, except for the last point. As stated above, there are a couple of
outstanding reviews that should be addressed first prior to handing off to the
responsible AD. If the authors feel that they're already addressed it would be
good to see some indication of that on the mailing list.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document touches upon several expert topics, but there is mostly standard
use.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This seems correct since it builds upon well-specified technologies
and has normative requirements for interoperability.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All authors have indicated that they are not aware of any undisclosed IPRs.
Public mailing-list call is ongoing until February 6.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID-nits:
identified the use of the IPv4 string 192.168.0.0 and suggests to change it to the
192.0.2.0/24 ranges.
The table in section 3.1 is too wide in the rendered txt.

Additional nits:

The term Proxy Definition is used a few times in the document, but it's
only implicitly introduced in section 3, and it's used interchangeably
with the term proxy dictionary. 

Section 3:
Paragraph 2 refers to the proxies list. The previous section defines
it as an array which seems to be the correct JSON terminology.

Section 3.1 last paragraph has a somewhat clunky sentence:
"Identifier values MAY be duplicated across different proxy dictionaries in the
proxies array, which indicates that all references from other dictionaries to a
particular identifier value apply to all matching proxies."

I'd suggest something more compact e.g.,:
"Identifier values MAY be duplicated across different proxy dictionaries in the proxies array.
References to a particular identifier apply to the set of proxies sharing that identifier."



15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Registers two new entries in the "Additional Information PvD Keys" registry.
The registry is clearly identified. The registrations are consistent with the
text in the body.

Registers one new entry in "DNS SVCB Service Parameter Keys (SvcParamKeys)".
The registry is clearly identified and the registration is consistent with the
text in the body (section 2.1).

Two new registries are requested: "Proxy Protocol PvD Values" &
"Proxy Destination Rule PvD Keys". Both are appropriately named and have initial
contents specified. Both require expert review for assignments.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

"Proxy Protocol PvD Values", "Proxy Destination Rule PvD Keys".
Clear instructions to designated expert in both cases.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/