Re: [DNSOP] Localhost - more reliable options?

2017-08-18 Thread Ted Lemon
El 17 ag 2017, a les 23:19, Brian Dickson va escriure: > Use DNSSEC, and use something other than "localhost." > Does the host know its own name(s)? Depending on the context, the host likely doesn't have a name. If it does have a name, PKI works, so there's no need for some sort of ad-hoc tru

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

2017-08-18 Thread Petr Špaček
Hello Ted and dnsop, I'm trying really hard to find out why we do not understand each other so I dug into to dnsop archives and draft-bellis-dnsop-session-signal-00 to see if my questions were already answered somewhere. Hopefully I have better understanding and will focus on technical questions.

Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

2017-08-18 Thread Lanlan Pan
Thanks a lot for your pertinent comments, :-) Ted Lemon 于2017年8月17日周四 下午9:56写道: > El 17 ag 2017, a les 0:09, Lanlan Pan va escriure: > > We can use SWILD to optimize it, not need to detecting, just remove items > which SWILD marked, to save cost. > > > So, can you talk about how your proposal sa

Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

2017-08-18 Thread Lanlan Pan
Thanks a lot for your detail analysis, :-) Ralf Weber 于2017年8月17日周四 下午11:16写道: > Moin! > > On 17 Aug 2017, at 0:09, Lanlan Pan wrote: > > Yes, I agree, in fact the *online cache rate* is small (0.12% queries), > LRU > > & TTL works fine. > > SWILD not save many online cache size, because of the q

Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

2017-08-18 Thread Ted Lemon
El 18 ag 2017, a les 11:33, Lanlan Pan va escriure: > So, can you talk about how your proposal saves cost over using a heuristic? > It can be used with cache aging heuristic. > Heuristic read in aaa/bbb/ccc.foo.com , expire and move > out; then read in xxx/yyy/zzz.foo.com

Re: [DNSOP] Localhost - more reliable options?

2017-08-18 Thread Richard Barnes
Sorry, but point of order: We have a solution that entails a minimal change from the current state of the art and minimal incremental security risk. Let's not re-open fundamental questions, please. On Thu, Aug 17, 2017 at 6:22 PM, Brian Dickson < brian.peter.dick...@gmail.com> wrote: > The discus

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

2017-08-18 Thread Ted Lemon
El 18 ag 2017, a les 11:12, Petr Špaček va escriure: > My objections are in the end about engineering costs, which was nicely > summarized by Paul Vixie in another thread (about SWILD, but applicable > to session signaling as well): > https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

2017-08-18 Thread Tom Pusateri
> On Aug 18, 2017, at 11:12 AM, Petr Špaček wrote: > > We can certainly call TLVs "extension" but renaming it does not remove > the fundamental problem: > TLVs are largely incompatible with the code we already have widely > implemented and deployed everywhere in all the DNS implementations and >