Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

dougb> The other problem is that this feature is only really useful in dougb> the DNSSEC ramp-up period. Sure, mistakes are more common now, dougb> software is immature, etc. etc. But if DNSSEC is successful, the dougb> software will get better (it already is a lot better than even a dougb> few ye

Re: [DNSOP] New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

On Sat, Oct 25, 2014 at 9:50 PM, Paul Hoffman wrote: > On Oct 25, 2014, at 6:43 PM, Olafur Gudmundsson wrote: >> We want humans in the loop, I would love to see a twitter feed when ever >> Comcast does a Negative Trust Anchor. > > Like https://twitter.com/ComcastDNS, for example? Either things h

Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

On Sat, Oct 25, 2014 at 3:30 PM, Paul Ebersman wrote: > > dougb> It's not just a philosophical objection, it's an operational > dougb> one. When DNSSEC fails for a domain there are 2 main > dougb> reasons. Operator error, and an actual MITM or similar attack. If > dougb> the operators of validatin

Re: [DNSOP] New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

On Oct 25, 2014, at 6:43 PM, Olafur Gudmundsson wrote: > We want humans in the loop, I would love to see a twitter feed when ever > Comcast does a Negative Trust Anchor. Like https://twitter.com/ComcastDNS, for example? Either things haven't been failing much lately, or they're not updating it

Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

On Oct 25, 2014, at 8:30 PM, Paul Ebersman wrote: > > dougb> It's not just a philosophical objection, it's an operational > dougb> one. When DNSSEC fails for a domain there are 2 main > dougb> reasons. Operator error, and an actual MITM or similar attack. If > dougb> the operators of validating

[DNSOP] Simplified proposal on helping recursives with long round trip times to the root: draft-wkumari-dnsop-root-loopback

Greetings again. Thank you to the people who gave us feedback on our earlier draft (draft-wkumari-dnsop-dist-root) saying that it needed a better defined use case and less grandiose claims of helping where it didn't really. Instead of continuing on that draft, we started a new one with has the n

Re: [DNSOP] [dns-privacy] Qname minimization IPR

> Warren Kumari > Saturday, October 25, 2014 2:10 PM > > > On Sat, Oct 25, 2014 at 2:27 PM, Paul Vixie > wrote: > > > >> Paul Hoffman >> Saturday, October 25, 2014 11:06 AM >> >> 1) It is a patent appl

Re: [DNSOP] [dns-privacy] Qname minimization IPR

On Sat, Oct 25, 2014 at 2:27 PM, Paul Vixie wrote: > > > Paul Hoffman > Saturday, October 25, 2014 11:06 AM > > 1) It is a patent application, not a patent. > 2) The application was filed by Verisign, not Google. > > --Paul Hoffman > > > thanks. however, i was told google also has one on Q-M.

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-dns-qname-minimisation

All The call period ended earlier this week. The only outspoken nay was Peter Koch. His reasons may prove to be true, as many have said. But the consensus is to adopt the work, and see where it takes us. The new version has been submitted in the document list. Based on the discussion, I'v

Re: [DNSOP] Possible slower response with minimization

On Sat, Oct 25, 2014 at 06:05:16PM +0200, Stephane Bortzmeyer wrote a message of 24 lines which said: > > Right, NXDOMAIN returned by some broken implementation to > > empty non-terminals MUST NOT be interpreted that the > > terminals does not exist. > > Full agreement again Paul Vixie was

Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

dougb> It's not just a philosophical objection, it's an operational dougb> one. When DNSSEC fails for a domain there are 2 main dougb> reasons. Operator error, and an actual MITM or similar attack. If dougb> the operators of validating resolvers simply turn off validation dougb> for domains that s

Re: [DNSOP] [dns-privacy] Qname minimization IPR

> Paul Hoffman > Saturday, October 25, 2014 11:06 AM > > 1) It is a patent application, not a patent. > 2) The application was filed by Verisign, not Google. > > --Paul Hoffman thanks. however, i was told google also has one on Q-M. that's the one i thought this th

Re: [DNSOP] Possible slower response with minimization

> Stephane Bortzmeyer > Saturday, October 25, 2014 9:05 AM > On Tue, Oct 21, 2014 at 02:14:49PM +0900, > Masataka Ohta wrote > a message of 27 lines which said: > > >> Right, NXDOMAIN returned by some broken implementation to >> empty non-terminals MUST NOT be inter

Re: [DNSOP] [dns-privacy] Qname minimization IPR

On Oct 25, 2014, at 10:53 AM, Paul Vixie wrote: >> http://www.google.com/patents/EP266A1?cl=en >> > > importantly, google's policy is to use patents only in defense. i've > requested that they make that explicit in the case of this particula

Re: [DNSOP] [dns-privacy] Qname minimization IPR

Paul, It is a VeriSign patent, its just being shown on the Google patent serach engine On Sat, Oct 25, 2014 at 1:53 PM, Paul Vixie wrote: > > > Stephane Bortzmeyer > Saturday, October 25, 2014 2:24 AM > [Copy to dnsop since the qname minimisation draft is now a WG item at > dnsop.] > > On T

Re: [DNSOP] [dns-privacy] Qname minimization IPR

> Stephane Bortzmeyer > Saturday, October 25, 2014 2:24 AM > [Copy to dnsop since the qname minimisation draft is now a WG item at > dnsop.] > > On Thu, Oct 23, 2014 at 10:21:57AM -0700, > David Conrad wrote > > http://www.google.com/patents/EP266A1?cl=en importan

Re: [DNSOP] [dns-privacy] Qname minimization IPR

> On Oct 25, 2014, at 2:03 PM, Phillip Hallam-Baker > wrote: > > The claims are broad, not specific to one field of use. > > But there isn't a patent yet and they may have been waiting to file after > grant. > > It is possible for someone other than the IPR holder to file but best if its >

Re: [DNSOP] Possible slower response with minimization

On Tue, Oct 21, 2014 at 02:14:49PM +0900, Masataka Ohta wrote a message of 27 lines which said: > As the choice between privacy and latency is on resolver side, > moderate latency is not harmful. I fully agree. Qname minimisation is an _unilateral_ decision. Any resolver can make its own trad

Re: [DNSOP] [dns-privacy] Qname minimization IPR

The claims are broad, not specific to one field of use. But there isn't a patent yet and they may have been waiting to file after grant. It is possible for someone other than the IPR holder to file but best if its the IPR holder. The mere existence of a patent does not necessarily mean an intent

Re: [DNSOP] Possible slower response with minimization

On Mon, Oct 20, 2014 at 05:26:29PM -0400, Phillip Hallam-Baker wrote a message of 74 lines which said: > If we are going there, I would want to know how common the > configurations are. Yes, actual numbers seen from a real resolver would be useful. > Outside this list how common are hierarch

Re: [DNSOP] Possible slower response with minimization

On Mon, Oct 20, 2014 at 05:03:19PM -0400, Bob Harold wrote a message of 135 lines which said: > With minimization: Besides the fact that it is true only for a cold cache (as mentioned by others in this thread), it depends on how minimisation is implemented. One possible way is "aggressive min

Re: [DNSOP] [dns-privacy] Qname minimization IPR

On 25/10/14 15:56, Ted Lemon wrote: > And also if anyone from Verisign is participating, they are required to > disclose, Well, only if they think that the IPR is relevant. Their claims (I've not read 'em) could after all be unrelated to the draft, e.g. if they've only claimed some madly compli

Re: [DNSOP] [dns-privacy] Qname minimization IPR

On Oct 25, 2014, at 5:24 AM, Stephane Bortzmeyer wrote: > Back to IETF issues: can someone who have read RFC 3979 more > thoroughly than me tell me if, as the draft author, I'm supposed to > file the IPR disclosure or is it up to Verisign employees? You should, not must, file a third-party disclo

Re: [DNSOP] New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

Doug, On Oct 24, 2014, at 3:06 PM, Doug Barton wrote: >> I know that there will be some philosophical objections / discussions on >> this... > > It's not just a philosophical objection, it's an operational one. When DNSSEC > fails for a domain there are 2 main reasons. Operator error, and an a

Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

On 10/24/14, 6:06 PM, "Doug Barton" wrote: >But worse yet, in the operator error case you make such errors painless. >Instead, if they are painful (as in, screw up DNSSEC and you go off line) >then it leads to more people taking DNSSEC seriously, and doing it right. >Of course I realize that the

Re: [DNSOP] [dns-privacy] Qname minimization IPR

[Copy to dnsop since the qname minimisation draft is now a WG item at dnsop.] On Thu, Oct 23, 2014 at 10:21:57AM -0700, David Conrad wrote a message of 56 lines which said: > http://www.google.com/patents/EP266A1?cl=en Well, some resolvers (the programs which will have to implement qname