Hi Stephane, > On Jun 6, 2017, at 1:48 PM, Stephane Bortzmeyer <[email protected]> wrote: > > On Tue, May 09, 2017 at 08:43:15PM -0700, > Suresh Krishnan <[email protected]> wrote > a message of 37 lines which said: > >> I do have a concern regarding section 7.3 as it is not clear what >> really is being requested on the DHCP front here. While using an IP >> address or an FQDN are generally both possible choices while >> providing configuration options using DHCP, the use of FQDNs for >> acquiring trusted DNS servers seems problematic. We have spent a >> great deal of effort writing up some of the potential issues in >> Section 8 of RFC7227. > > It seems there was no reply to this DISCUSS?
Yes. There was no response to this DISCUSS. > If so, let me give my > opinion: I disagree with the DISCUSS. Not sure what you are disagreeing with. Are you saying this text is clear about what is needed from the eventual DHCP option(s)? > Section 7.3 is just here to lay > down some paths toward a future and possible DHCP extension. What is(are) the paths? If it was clear, I wouldn’t really be asking. > It does > not attempt to standardize one. It does not request anything from the > current DHCP servers. What does this text mean? "However when using a Strict profile the DHCP servers used as sources of authentication domain names MUST be considered secure and trustworthy. This document does not attempt to describe secured and trusted relationships to DHCP servers." The strict profile requires the DHCP server to be “secure and trustworthy” but declines to define what it means by “secure and trusted”. So I cannot tell if it requires anything from current DHCP servers or not. > > Mentioning section 8 of RFC 7227 could help, but this section does not > discuss the DNS-specific issues (such as the fact we need both IP > address and name of the DNS resolver, which RFC 7227 frame it as an > exclusive choice). > > Possible solution if it is absolutely necessary to clear the DISCUSS: > moving section 7.3 to an appendix to make clear it is not part of the > DNS-over-TLS profiles definition. If the text is taken out, I will certainly clear. Thanks Suresh _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
