Hi
This adoption period ended a week ago, and between the comments made
when the document was placed in the 'Candidate' phase and the actual
call, it has enough consensus to pass adoption.
One thing of Note: I'm going to begin some conversations with the
HTTPbis working group on this draft
> If this WG adopts the document and then says "but we want to use an older
> version of the HTTP protocol", we should expect a fair amount of push-back
> during IETF Last Call.
RFC7540 clearly states:
This specification is an alternative to, but does not obsolete, the
HTTP/1.1 message synt
Folks, this is a call for WG adoption, not a design exercise. If the WG
adopts the document, we will have plenty of opportunity to fine-tune or
make major changes. Such as:
On 12 Jul 2016, at 11:51, Shane Kerr wrote:
I recognize that HTTP/2 is definitely a better option because of
out-of-ord
Marek,
At 2016-07-11 22:26:00 -0500
Marek Vavruša wrote:
>
> You get queueing for free, but not pipelining and out-of-order
> responses, that has to be defined.
> The draft mentions this, but I think at this point it should just
> depend on HTTP/2,
> as it's the only way to get decent performanc
On Tue, Jul 12, 2016 at 11:03 AM, John R Levine wrote:
>>> The reason to use TCP framing is so that you can send multiple DNS
>>> requests
>>> in a single http request and get back multiple answers. Recent messages
>>> here suggest that's of considerable interest, and if you're only sending
>>> o
The reason to use TCP framing is so that you can send multiple DNS requests
in a single http request and get back multiple answers. Recent messages
here suggest that's of considerable interest, and if you're only sending one
request, the two bytes of TCP length are tiny compared to the http heade
Paul,
At 2016-07-12 07:00:17 -0400
Paul Wouters wrote:
> On Mon, 11 Jul 2016, Tim Wicinski wrote:
>
> > 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
> > DNSO
On Tue, Jul 12, 2016 at 8:45 AM, John R Levine wrote:
>>> My main suggestion is to lose the Proxy-DNS-Transport header and
>>> always have the request and response in TCP format.
>>
>>
>> The HTTP payload should always be unframed (like DNS over UDP) regardless
>> of the upstream DNS transport, si
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.
It's hard to believe we're reading the same draft. The one I'm reading is
abo
My main suggestion is to lose the Proxy-DNS-Transport header and
always have the request and response in TCP format.
The HTTP payload should always be unframed (like DNS over UDP) regardless
of the upstream DNS transport, since HTTP already provides content-length
framing so there's no need to r
On 12/07/2016 12:00, Paul Wouters wrote:
>
> I am very hesitant to accept any protocol-over-http wrapper, as it just
> moves the problem around and generate a new set of middleware boxes that
> mess with the data.
+lots
Ray
___
DNSOP mailing list
DN
On Mon, 11 Jul 2016, Tim Wicinski wrote:
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, clearly stating your view.
I am very hesitant to
Adrien de Croy wrote:
>
> 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?
In a good implementation the back-end DNS framing should be independent of
the HTTP framing.
Tony.
--
f.anthony.n.finchhttp://dotat.at/ -
Adrien de Croy 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.
Why not just specify that pipelined HTTP should be used w
John Levine wrote:
>
> My main suggestion is to lose the Proxy-DNS-Transport header and
> always have the request and response in TCP format.
The HTTP payload should always be unframed (like DNS over UDP) regardless
of the upstream DNS transport, since HTTP already provides content-length
framing
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 order) replies?
>
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:
>>> Don't you get
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 D
--
From: "John R Levine"
To: "Marek Vavruša"
Cc: "dnsop"
Sent: 12/07/2016 3:32:51 p.m.
Subject: 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 bunc
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
___
DNSO
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 shou
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 you get this automa
evine"
To: "dnsop@ietf.org"
Cc: "adr...@qbik.com"
Sent: 12/07/2016 3:06:24 p.m.
Subject: 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
>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 stuf
--
From: "Tim Wicinski"
To: "dnsop"
Sent: 12/07/2016 10:33:14 a.m.
Subject: [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.or
>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 main
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, clearl
27 matches
Mail list logo
