Re: [DNSOP] Followup Discussion on TCP keepalive proposals

Paul Vixie wrote: > > Tony Finch > > Saturday, January 24, 2015 5:09 PM > > > > Sorry, I was being too terse. I meant extra latency due to the time > > taken to transmit all that redundant data. > > isn't that what "transport encoding" of "deflate" is meant for? That doesn'

Re: [DNSOP] Complying with draft-grothoff-iesg-special-use-p2p-names

Hi, "For every complex problem there is a simple, efficient solution which is wrong". And that seems to be the case for my suggestion for compliance. Persons wiser than me have suggested that the real solution is that which the overlay community (tor, i2p, gnunet etc.) have been working on: usin

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

Paul Vixie wrote: > > the installed initiator base does not use pipelining, ever. adns has done since 1999. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet, Irish Sea: Northwest backing southwest 4 or 5, occasionally 6 at first in Irish Sea. Slight or moderate in Irish Sea, otherw

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Tony Finch > Monday, January 26, 2015 6:58 AM > > adns has done since 1999. in glibc, adns provides the gethostby*() interface and similar, but also offers its own asynch API. i believe that most apps in the world use the latter, which is synchronous. are you saying that

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

> Tony Finch > Monday, January 26, 2015 1:42 AM > > ["transport encoding" of "deflate"] doesn't help with HTTP's header > overhead, nor will it help with > expansion due to textual instead of binary crypto blobs. makes sense. -- Paul Vixie ___

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

Paul Vixie wrote: > > > adns has done since 1999. > > in glibc, adns provides the gethostby*() interface and similar, No, adns has nothing to do with the glibc resolver. > are you saying that some important apps use the former, or are you > saying that adns has a socket pool shared amongst multi

[DNSOP] Document Action: 'DNSSEC Key Rollover Timing Considerations' to Informational RFC (draft-ietf-dnsop-dnssec-key-timing-06.txt)

The IESG has approved the following document: - 'DNSSEC Key Rollover Timing Considerations' (draft-ietf-dnsop-dnssec-key-timing-06.txt) as Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Joel Jaeggli and Benoit Clai

Re: [DNSOP] DNSKEY RRset size and the root

On Fri, Jan 23, 2015 at 10:12 AM, Nicholas Weaver wrote: > >> On Jan 23, 2015, at 10:01 AM, Paul Hoffman wrote: >> >> What is the problem with #2? IP fragmentation happens, and The Internet is >> expected to work with it. That is, of what possible value is "inform their >> customers"? > > The I

[DNSOP] ID Tracker State Update Notice:

IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnso

[DNSOP] ID Tracker State Update Notice:

IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] ID Tracker State Update Notice:

IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSKEY RRset size and the root

In message , Liang Zhu writes: > On Fri, Jan 23, 2015 at 10:12 AM, Nicholas Weaver > wrote: > > > >> On Jan 23, 2015, at 10:01 AM, Paul Hoffman wrote: > >> > >> What is the problem with #2? IP fragmentation happens, and The Internet is > >> expected to work with it. That is, of what possible