On Mon, Jan 9, 2017 at 4:43 AM, Ray Bellis <r...@isc.org> 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
