Hi All, On 10/6/14 12:17 PM, Tim Wicinski wrote: > > Our thought process (or perhaps mine) was that it's so easy to offer to > solve everything and you end up solving nothing. > > I've been reticent to put forth the qname-minimisation work in DNSOP not > because I don't think it belongs there, but the time spent on the > editorial minutia of the DNSOP rechartering left me a bit bewildered. > > I suspect the chairs should just ask our Glorious AD for advice.
I am not sure if I qualify as the Glorious AD mentioned above, but... I think the QNAME minimization approach is something that should be pursued. The proposed charter for DPRIVE would put it as a follow-on work item so that the focus can be on the client <-> iterative resolve problem. I could see one of three options for progressing the qname work... 1) Wait for the re-charter of DPRIVE 2) Ping Joel about getting it done in DNSOP 3) Ask for AD sponsorship Regards, Brian > > tim > > On 10/6/14 11:26 AM, Olafur Gudmundsson wrote: >> >> On Oct 6, 2014, at 8:44 AM, Stephane Bortzmeyer <[email protected]> >> wrote: >> >>> [Keep [email protected] in the loop only if it is substantive comments on >>> the WG creation, please] >>> >>> On Fri, Oct 03, 2014 at 10:38:35AM -0700, >>> The IESG <[email protected]> wrote >>> a message of 68 lines which said: >>> >>>> The primary focus of this Working Group is to develop mechanisms >>>> that provide confidentiality between DNS Clients and Iterative >>>> Resolvers, >>> >>> I do not see why the group is limited to this point. 1) Some technques >>> (such as hop-to-hop encryption) work exactly the same for this case >>> and the case of resolvers<->authoritative. 2) The problem of data >>> gathering by authoritative name servers is as serious as the problem >>> of sniffing by third parties between a stub client and a resolver, and >>> should be addressed at the same level. >>> >>> >> >> Well different techniques might be “better” in the two cases, i.e. >> connection from client to Recursive resolver >> may only be kept open for a short time while the connection from >> Recursive Resolver to a BIG DNS data provider >> might be always-on. >> So I think the charter is right in saying “will focus on last mile” >> and check if that solution will scale to other cases. >> >> Olafur >> >> _______________________________________________ >> dns-privacy mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dns-privacy >> > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
