Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

On Mon, Jul 11, 2016 at 3:33 PM, Tony Finch wrote: > > Warren Kumari wrote: >> >> Hmmm... I think that this sounds reasonable, possibly with a minor tweak. >> Initially the EXTRA RR was never intended to be something that could >> be queried - the EXTRA (nee

Re: [DNSOP] draft-wkumari-dnsop-multiple-responses-03

On Mon, Jul 11, 2016 at 10:01 AM, John Dickinson wrote: > Hi, > > A couple of nits > > EXTRA is spelt in at least 3 different ways. Yup. English is an evolving language -- it was just evolving faster in this doc than elsewhere :-) Fixed in Github version (to be posted once the

Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

On Thu, Jul 7, 2016 at 5:32 AM, Tony Finch wrote: > Regarding the format of EXTRA RRs, it's better to use a list of RRs rather > than a list embedded in one RR. And a single label isn't enough, e.g. > TLSA. > > So I suggest the presentation format should be like > > EXTRA

Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

Warren Kumari wrote: > > Hmmm... I think that this sounds reasonable, possibly with a > minor tweak. > Initially the EXTRA RR was never intended to be something that could > be queried - the EXTRA (nee ADDitional) record only existed to allow > copying from the master to the

Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

UDP+cookies could work for you? -G On Mon, Jul 11, 2016 at 10:19 PM, Ray Bellis wrote: > > > On 11/07/2016 07:13, George Michaelson wrote: > >> Things like client capability signalling, I suspect are in a harder >> bucket. I won't say intractably hard, but last time I floated

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

>Please review this draft to see if you think it is suitable for adoption >by DNSOP, and comments to the list, clearly stating your view. Yes, we should adopt it. It needs some work, but what draft doesn't. >Please also indicate if you are willing to contribute text, review, etc. Yes. My

[DNSOP] The DNSOP WG has placed draft-bellis-dnsop-session-signal in state "Candidate for WG Adoption"

The DNSOP WG has placed draft-bellis-dnsop-session-signal in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/ ___ DNSOP mailing list

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

One thing I think has always been bugging me about DNS over HTTP is the appalling performance we will likely see in a lot of cases. Even small latencies in normal DNS lookups cause major impact on page load times on complex pages with resources from many servers, and adding HTTP overhead to

[DNSOP] Call for Adoption: draft-song-dns-wireformat-http

This starts an official Call for Adoption for draft-song-dns-wireformat-http The draft is available here: https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list,

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

>So I suggest some thought should be given to reducing round-trips by >allowing for multiple DNS request payloads in a single HTTP request >message, and multiple DNS response payloads in an HTTP response message. Don't you get this automatically if it's treated as a TCP DNS connection? You

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

On Mon, Jul 11, 2016 at 10:06 PM, John Levine wrote: >>So I suggest some thought should be given to reducing round-trips by >>allowing for multiple DNS request payloads in a single HTTP request >>message, and multiple DNS response payloads in an HTTP response message. > > Don't

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

Don't you get this automatically if it's treated as a TCP DNS connection? You stuff a bunch of requests down the pipe, and you get back a bunch of responses. See RFC 7766. You get queueing for free, but not pipelining and out-of-order responses, that has to be defined. RFC 7766 says you

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

I guess presuming that the back end will use TCP for DNS you could do this, but I would imagine that's not always the case? If it doesn't, there's a lot of queries that will fail, particularly with DNSSEC included. See RFC 7766. R's, John ___

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

for a web to DNS proxy to decide to send a reply back, it would need to consider it complete? Or are you proposing that the http server would start streaming back the payload as it received the (possibly out of order) replies? Maybe instead should use WebSockets -- Original Message

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

for a web to DNS proxy to decide to send a reply back, it would need to consider it complete? Or are you proposing that the http server would start streaming back the payload as it received the (possibly out of order) replies? I was thinking that the proxy would get all the queries from the

Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

IETF Secretariat wrote: > The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ Hi, I've read the -03 version of

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

RFC 7766 is about DNS/TCP not about DNS/HTTP, the order of processing has to be determined by the wrapping protocol. You would get it for free if this draft was about TCP over HTTP or HTTP over DNS/TCP, but it's not. Marek On Mon, Jul 11, 2016 at 10:32 PM, John R Levine wrote:

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

On Mon, Jul 11, 2016 at 10:39 PM, John R Levine wrote: >> for a web to DNS proxy to decide to send a reply back, it would need to >> consider it complete? >> >> Or are you proposing that the http server would start streaming back the >> payload as it received the (possibly out of

Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

Thats good to know Mark. I took a dark view of change in DNS, but I do recall believing that for some problems, with tractable volumes of change-effectors, you can move on them. So, thanks for pushing: it helps. Things like client capability signalling, I suspect are in a harder bucket. I won't

[DNSOP] draft-wkumari-dnsop-multiple-responses-03

Hi, A couple of nits EXTRA is spelt in at least 3 different ways. The example in 5.1 introduces the AAA RR type without definition :) Section 2 paragraph 1: I think that more recent examples of the background regarding trust of additional records could be found. IMHO section 8 item 2 should be

Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

On 11/07/2016 07:13, George Michaelson wrote: > Things like client capability signalling, I suspect are in a harder > bucket. I won't say intractably hard, but last time I floated > capability flagging, I got pretty strong pushback. I think capability flagging is difficult in a stateless

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-02.txt

On Fri, Jul 8, 2016 at 6:36 PM, Paul Hoffman wrote: > Greetings again; I'm the new co-author on this draft. Based on the WG > discussion where a bunch of us wanted to use EDNS0 and a bunch of us wanted > to use queries, the authors tentatively decided that the best way to

Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-01.txt

On Fri, Jul 8, 2016 at 5:20 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : DNS Terminology > Authors