This email triggers a WGLC for the “Communicating Proxy Configurations in Provisioning Domains<https://datatracker.ietf.org/doc/draft-ietf-intarea-proxy-config/>”<http://domains%3Chttps//datatracker.ietf.org/doc/draft-ietf-intarea-proxy-config/%3E%E2%80%9D> draft. This document went through multiple revisions and the chairs and authors believe it is now ready for WGLC.
Please (re)-review the draft and send your comments and feedback to Intarea ML. The overall approach seems reasonable to me. I have included below some questions about specific areas that may need clarification or appear to be incorrect. When the proxy field is hostname:port, can an IP address be used? For IPv6, should the address use [ipv6]:port like with a URI or just IPv6:port? I didn't see IPv6 mentioned in the referenced HTTP spec section, although maybe it's actually transitively specified. Regardless, is it worth calling out explicitly whether or not IP addresses are OK and if so whether the [] is required here? The value of identifier key is a string that can be used to refer to a particular proxy from other dictionaries, specifically those defined in Section 4. It is unclear whether an entry with an identifier is allowed to be used even if there is no relevant proxy-match. E.g., is the intent something like "Proxies with an identifier key SHOULD only be used when a proxy-match applies"? Or is it meant to be more vague in some way? proxy-match.domains: The examples lack trailing ".". Are these to be interpreted using the client's default DNS suffixes or be treated as absolute domain names regardless? Comma-separated port list may contain individual port numbers... The explicit mention of "comma" makes me think that ["80,443,12345"] might be supported in addition to a standard JSON list ["80","443","12345"]. Multiple rules can match for the same destination, in which case all are considered to be accessible through the matching proxies in case the sets of proxies are different. I'm confused. This seems to suggest that the client can/should continue looking for more matches after making a match, but that conflicts with the "first match" rule proposed just before. Are there some cases where clients can/should continue looking for rule matches? If so, when is that OK to do? Is this just a matter of preference levels, except for empty proxy sets, which always mean "stop here"? On a related note, what if I have a proxy-match none of whose proxy identifiers apply to the protocol, e.g., a TCP connection but the identified proxy only has "connect-udp"? Should the client consider that "not a match" and continue looking for more rules? Or stop and declare no proxy available? traffic that matches the rule needs to match at one of the entries in Typo? => "at least one of" Clients that encounter a proprietary key they do not recognize MUST ignore the entire destination rule in which the key appears. I'm curious why one uses mandatory while the other assumes all keys are mandatory. Example #1: Would it be helpful to add a note that domains outside of *.internal.example.com would not use these proxies at all? I see that's explicitly covered in example #2, so that may be sufficient... In this case, the client would not send to the proxies any TCP traffic that is not destined to hosts matching "*.intranet.example.org", 192.168.0.0/16 or 2001:DB8::/32. Typo? => Either "that is destined" or "the client would only send" (The stated logic appears to be backwards.) -- Phil Lisiecki Akamai Technologies
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
