On Mon, Jan 9, 2017 at 4:43 AM, Ray Bellis wrote:
> I've submitted a -01 revision to address most of the feedback received
> so far.
I have some minor comments on this version.
- Section 3.1
IP Version: The IP protocol version number used by the client, as
defined in the IANA IP Version Number Registry [IANA-IP].
Implementations MUST support IPv4 (4) and IPv6 (6).
I suspect "IANA-IP" is defined as a 4-bit field simply because the
version field of the IPv4 (and therefore IPv6) header is 4 bits.
But I don't think this specification necessarily has to inherit the
restriction, and while it's probably quite unlikely to see the need
for more than 15 values, I also don't see why we have to be more
future proof (at least we know "IPv10" is coming, right? :-).
Although there's an unused 4 more bits, I think it's even better to
have a 16-bit field and use address family numbers:
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
- Section 3.2
Proxies MUST append this option to each request packet received
before sending it to the intended DNS server.
This MUST sounds too strong to me as a general requirement. Unless
the upstream server needs the information provided in this option,
there should be no interoperability problem even without this
option.
- Section 3.3
When this option is received from a white-listed client the DNS
server MUST (SHOULD?) use the address from the option contained
therein in preference to the client's source IP address for any data
processing logic that would otherwise depend on the latter.
I think this paragraph needs some more clarification. I can easily
imagine the server has an ACL that limits acceptable clients to
those proxies. But in that case the server should actually "use"
the client's source IP address. It's not a critical problem of the
specification, but I think it's better to clarify the intended
context to avoid such confusion of readers.
--
JINMEI, Tatuya
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop