Subject: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

From: Shane Kerr <[email-masked]>
Date: Thu, 17 Dec 2015 02:07:54 +0100

Hello,

I have updated the DNS over HTTP review document that I sent some days
ago. Thanks to Jinmei for reading it.

As I mentioned before, if there is interest then my co-authors and I
are happy to try to get the working group to adopt the document. If
there is not interest, then we are happy to go forward with an
individual submission.

If I don't hear any positive support over the next week or two then
that is a pretty clear sign that the working group has little
interest. :)

Cheers,

--
Shane

Subject: New Version Notification for draft-shane-review-dns-over-http-01.txt
From: [email-masked] (by way of Shane Kerr <[email-masked]>)
To: "Shane Kerr" <[email-masked]>, "Runxia Wan" <[email-masked]>, "Linjian Song" <[email-masked]>, "Davey Song" <[email-masked]>
Date: Wed, 16 Dec 2015 16:58:41 -0800

A new version of I-D, draft-shane-review-dns-over-http-01.txt
has been successfully submitted by Shane Kerr and posted to the
IETF repository.

Name:		draft-shane-review-dns-over-http
Revision:	01
Title:		A review of implementation DNS over port 80/443
Document date:	2015-12-16
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-shane-review-dns-over-http-01.txt
Status:         https://datatracker.ietf.org/doc/draft-shane-review-dns-over-http/
Htmlized:       https://tools.ietf.org/html/draft-shane-review-dns-over-http-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-shane-review-dns-over-http-01

Abstract:
   The default DNS transport uses UDP on port 53.  There are many
   motivations why users or operators may prefer to avoid sending DNS
   traffic in this way.  A common solution is to use port 80 or 443;
   with plain TCP, TLS-encrypted TCP, or full HTTP(S).  This memo
   reviews the possible approaches and delivers some useful information
   for developers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: George Michaelson <[email-masked]>
Date: Thu, 17 Dec 2015 11:57:55 +1000

Given a conversation about DNS over DTLS, DNS over TCP, I think a body of
work exploring the simple mapping over HTTP/HTTPS makes perfect sense and
is more about the DNS than its about the underlying transport.

So I'm in support, adopt.

-George

On Thu, Dec 17, 2015 at 11:07 AM, Shane Kerr <[email-masked]>
wrote:

> ---------- Forwarded message ----------
> From: "by way of Shane Kerr <[email-masked]>" <[email-masked]
> >
> To: Shane Kerr <[email-masked]>, Runxia Wan <[email-masked]>,
> Linjian Song <[email-masked]>
> Cc:
> URL:
> https://www.ietf.org/internet-drafts/draft-shane-review-dns-over-http-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-shane-review-dns-over-http/
> Htmlized:
> https://tools.ietf.org/html/draft-shane-review-dns-over-http-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-shane-review-dns-over-http-01
>
> Abstract:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 16 Dec 2015 21:08:03 -0500

> that is a pretty clear sign that the working group has little

Hi, Shane:

Given BCP 188 ("Pervasive Monitoring Is a Widespread Attack on Privacy"
and "The IETF Will Work to Mitigate Pervasive Monitoring"), I'm a bit
disappointed that "HTTPS" is spelled "HTTP(S)" in your document :-) If
you're going to go to the trouble of defining a new transport for DNS,
what's the rationale for allowing the transport to permit plaintext?

-- 
Robert Edmonds

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Dec 2015 19:50:01 -0800

> what's the rationale for allowing the transport to permit plaintext?

as the author of the first prototype, let me say that the client side proxy's only knowledge of 
its server side proxy is its IP address, whereas SSL needs a host name. i'd be happy to have all 
that specified by people who understand it, alone with client-side certs and server-side SSL 
ACL's. but i'll still likely use raw HTTP in some situations, so that should also be specified, even 
if explicitly discommended by the final published document.

-- 
P. Vixie

---

From: Shumon Huque <[email-masked]>
Date: Wed, 16 Dec 2015 23:11:00 -0500

On Wed, Dec 16, 2015 at 10:50 PM, Paul Vixie <[email-masked]> wrote:

> as the author of the first prototype, let me say that the client side
> proxy's only knowledge of its server side proxy is its IP address, whereas
> SSL needs a host name. i'd be happy to have all that specified by people
> who understand it, alone with client-side certs and server-side SSL ACL's.
> but i'll still likely use raw HTTP in some situations, so that should also
> be specified, even if explicitly discommended by the final published
> document.
>
>
>

Paul,

SSL (Actually "TLS", since no-one should use SSL any more) doesn't *need* a
hostname. TLS supports many identity forms that aren't hostnames. It's
perfectly possible to establish a TLS session with the client knowing only
the IP address of the server, and with some preconfigured knowledge of the
server, the client can even establish an' authenticated' TLS session.
However, there may be reasons to use hostnames (e.g. to allow more
recognizable associations of the DNS server's identity for users). Many
such details are being written up by some folks involved in the DNS over
(D)TLS efforts in a companion document. You could consider reusing that
work.

Shumon.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Dec 2015 23:14:38 -0500 (EST)

On Wed, 16 Dec 2015, Paul Vixie wrote:

> as the author of the first prototype, let me say that the client side proxy's only knowledge of its server
> side proxy is its IP address, whereas SSL needs a host name. i'd be happy to have all that specified by
> people who understand it, alone with client-side certs and server-side SSL ACL's. but i'll still likely use
> raw HTTP in some situations, so that should also be specified, even if explicitly discommended by the final
> published document.

So raw DNS on a port other than 53 is not something that would need a
big new RFC. And we have dprive doing DNS over TLS.

If TLS is just to break through broken or blocked port 53, we don't need
an HTTP(S) RESTful interface. Raw DNS in TLS would work fine. Same for
raw DNS on port non-53.

So what is the use case for the REST interface?

And yes, I'm a little prejudiced in trying to not add port 80/443 as
another encapsulation layer underneath the internet.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Dec 2015 20:36 -0800

On Wednesday, December 16, 2015 11:14:38 PM Paul Wouters wrote:
> > proxy's only knowledge of its server side proxy is its IP address,
> > whereas SSL needs a host name. i'd be happy to have all that specified by
> > people who understand it, alone with client-side certs and server-side
> > SSL ACL's. but i'll still likely use raw HTTP in some situations, so that
> > should also be specified, even if explicitly discommended by the final
> > published document.
> 
> big new RFC.

i disagree, because:

> And we have dprive doing DNS over TLS.

...the coffee shops i access the internet are going to block DTLS by default, without ever even 
knowing what it was.

> an HTTP(S) RESTful interface. Raw DNS in TLS would work fine. Same for

i disagree, because the web server in question may have other duties. i don't want to burn a 
whole IP address for this service. so we demux on the /proxy_dns URI.

> So what is the use case for the REST interface?

it's more general: could be used for server-to-server traffic, UPDATE, etc.

> another encapsulation layer underneath the internet.

this is the new era of "anything goes" for DNS protocol development. as with client subnet, no 
matter how bad an idea is, if someone is already doing it, then the ietf documents that use.

-- 
P. Vixie

---

From: Shane Kerr <[email-masked]>
Date: Thu, 17 Dec 2015 21:06:23 +0100

Robert,

At 2015-12-16 21:08:03 -0500

> what's the rationale for allowing the transport to permit plaintext?

I'm happy to add strong language documenting the pitfalls of insecure
channels to the DNS over HTTP survey draft.

Just to be clear, this document is a descriptive document, intended to
be informational. It does not describe the details of any protocols,
and steers clear of BCP 14/RFC 2119 words that indicate requirements.

We (BII and Paul Vixie) are going to submit a separate draft with a
protocol specification covering the HTTP-over-DNS protocol that Paul
developed and we implemented an inter-operating proxy for. That SHALL
include requirements and SHALL use RFC 2119 language. There we SHOULD
consider TLS-secured sessions only. ;)

Cheers,

--
Shane

---

From: "Mark Delany" <[email-masked]>
Date: 17 Dec 2015 20:20:24 +0000

It might be obvious to most, but should there be a section on
out-of-order processing of requests?

That the request pipeline order doesn't necesarily match the response
pipeline order is particularly unexpected in some protocols (and
likely non-compliant), such as HTTP < 2.0

Mark.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 17 Dec 2015 19:20:35 -0800

> likely non-compliant), such as HTTP < 2.0

i think this is opaque to the dns-over-http specification. that is, while http may under 
its covers do all kinds of asynchronous things, perhaps even using udp, or multiple 
parallel tcp sessions, or out of order processing... from the point of view of a dns-over-
http proxy, it makes POST requests, it receives POST responses to those requests.

--
P Vixie

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 17 Dec 2015 23:53:15 -0500

On 12/16/15 11:36 PM, Paul Vixie wrote:

>
> this is the new era of "anything goes" for DNS protocol development. as
> with client subnet, no matter how bad an idea is, if someone is already
> doing it, then the ietf documents that use.
>

Paul,

The idea is to document deviations to the DNS protocol that are being 
deployed publicly, focusing on their behavior in an operational context. 
  It is not attempting to claim that document is some protocol change. 
The same will go for DNS over HTTP as we start to see it being deployed 
more and more.

Shane's document is attempting to document variations in 
implementations. That's good - he mentioned one or two I had forgotten 
about.  Will the working group adopt it is another question for another day.

tim

---

From: "Mark Delany" <[email-masked]>
Date: 18 Dec 2015 17:56:19 +0000

On 17Dec15, Paul Vixie allegedly wrote:

> its covers do all kinds of asynchronous things

I may not be being very clear or I may misunderstand. As far as
implementation is concerned you are of course correct. As far as the
semantics of the order of responses over HTTP, not so much.

What I was getting at is that a dns-over-http client can pipeline send
request id=1 then request id=2 and get back pipelined response id=2
then response id=1 over a single connection:

Client                    Server
 Request id=1  ---->
 Request id=2  ---->

.. time passes

             <---- Response id=2
             <---- Response id=1

That is, a dns-over-http client has to do more elaborate
request/response matching with id (+query RR) rather than rely on
submit order for matching.

This re-ordering of responses is not allowed in regular HTTP 1.* and
would almost certainly break common HTTP clients that expect pipeline
order to be maintained.

I'm not saying this is good or bad, just saying it's an important
topic for any dns-over-*stream* protocol to discuss. Least surprise
and all that.

Mark.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Dec 2015 13:07:33 -0500

> matter how bad an idea is, if someone is already doing it, then the ietf documents that use.

I am getting a little tired of this description.  If it's "anything
goes" then we can just give up and go home.

Some people don't like client subnet.  I'm not too convinced that the
architectural arguments against it are so good, but that's a different
debate.

I'm much more concerned about snide remarks dismissing the serious
efforts of people as "anything goes".  I think it's unfair, I think it
pretends access to a trancendental goodness that (I am prepared to say
_a priori_) no participant here has, and I think it needlessly
disparages the good faith efforts of many people to make the Internet
better in an environment where we don't all agree about what "better"
is.  I think many of us stand improvement (I here include myself) at
making our arguments less charged.

Best regards,

A (speaking, as usual, for myself only)

-- 
Andrew Sullivan
[email-masked]

---

From: joel jaeggli <[email-masked]>
Date: Sun, 20 Dec 2015 08:13:42 -0800

> making our arguments less charged.

I think we dramatically better off, if we are willing to critically
consider the implications of proposals someplace and expose the record
of that, and I don't have a better location on offer then here.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 20 Dec 2015 12:40:04 -0500

> of that, and I don't have a better location on offer then here.

I completely agree.  But if we're going to do that, calling an
approach we don't like names adds nothing to the debate.  For
instance, I think there have been serious arguments against some
techniques, and I think those are useful contributions.  I'd be the
last person to say, "Don't criticise."  But such critiques need to
come with well-developed arguments.

In this case, for instance, one party suggested that there were
technical reasons not to use http(s) as a new encapsulation, and the
retort was (in effect) that someone's going to do this and hey,
anything goes so we must write it down.  That's not much of an
argument, and it's abusive of the efforts in the WG as well.  Hence my
objection.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Dec 2015 10:31:34 -0800

> of that, and I don't have a better location on offer then here.

i was not trying to stifle discussion. what a wg chair told me was that the essence of a dnsop 
rfc was, "if you're trying to accomplish thing X, here's one way to do it." sadly for me, because 
of the ietf's imprimatur, such specifications will be used in industry as if they were 
recommendations.

in the specific example of edns client subnet, i have previously supplied extensive technical 
argument against the systemic costs of expanding the Q-tuple in this way. those arguments 
did not find consensus in the WG, and are not reflected in the draft. see also 
"afasterinetnet.com".

-- 
P. Vixie

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Dec 2015 12:19:47 -0800

On Friday, December 18, 2015 05:56:19 PM Mark Delany wrote:
> > i think this is opaque to the dns-over-http specification. that is, while
> > http may under its covers do all kinds of asynchronous things
> 

http reordering would be handled at the http layer. for example, in libcurl. if the http protocol 
agent decides to transmit multiple outstanding queries on a single tcp socket, then it will use 
its own methods to match up the eventual responses to the then-outstanding requests. 

while the following internet draft is expired, it explains these issues well, including the 
background, and the relationship to persistent connections:

https://tools.ietf.org/html/draft-mogul-http-ooo-00

however, i think that while pipelining is standardized...

https://en.wikipedia.org/wiki/HTTP_pipelining

...the responses will be in order, unless you open multiple TCP sessions.

> topic for any dns-over-*stream* protocol to discuss. Least surprise

any discussion of out-of-order HTTP responses would have to explain how to match up 
responses with requests, as mogul's expired draft does above. since DNS-over-HTTP does not 
call for out-of-order HTTP responses, it does not have to explain how to match up responses 
with requests.

-- 
P. Vixie

---

From: "Mark Delany" <[email-masked]>
Date: 20 Dec 2015 20:49:33 +0000

On 20Dec15, Paul Vixie allegedly wrote:

> since DNS-over-HTTP does not call for out-of-order HTTP responses

But at least according to dpriv:

    "Since pipelined responses can arrive out-of-order, clients MUST
    match responses to outstanding queries using the ID field, query
    name, type, and class."

And since shane-review states:

    "This memo reviews the possible approaches..."

I take it to mean that shane-review could encompass implementations
like dpriv that imply or propose out-of-order. If that is the case
then I would think that those semantic variations should at least be
highlighted in shane-review.

Mark.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Dec 2015 13:30:13 -0800

>     match responses to outstanding queries using the ID field, query

that's for tcp/53 service. dns-over-http is a tcp/53 responder, not a tcp initiator. only a tcp/53 
initiator has to concern itself with out of order responses.

> like dpriv that imply or propose out-of-order. If that is the case ...

no.

-- 
P. Vixie

---

From: "Mark Delany" <[email-masked]>
Date: 20 Dec 2015 22:03:58 +0000

> > like dpriv that imply or propose out-of-order. If that is the case ...

Then I'd like to suggest a "yes" for this document.

Pipeline stalling due to forced in-order queries/responses is quite a
performance limitation and some implementations could readily provide
out-of-order.

Mark.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 20 Dec 2015 14:34:11 -0800

> performance limitation and some implementations could readily provide

this document proposes that http be used to proxy dns. dns already allows out of order 
response processing, and tcp/53 initators already have to cope with out of order responses 
when they occur.

what, precisely, do you think that a document that only describes HTTP initiators which are 
also DNS (tcp/53 and udp/53) responders, has to say about the possibility of future out-of-
order HTTP processing?

to me, that's future work. meaning, any HTTP initiator who wants out of order response 
processing will have to negotiate for it (see mogul's 2001 RID draft) and will then have new 
responsibilities for matching up the out of order HTTP responses with then-outstanding HTTP 
requests.

i can't imagine what to say about it in today's world which allows pipelining in HTTP. please 
suggest text?

-- 
P Vixie

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 20 Dec 2015 19:34:54 -0500

On 12/20/15 1:31 PM, Paul Vixie wrote:
> i was not trying to stifle discussion. what a wg chair told me was that
> the essence of a dnsop rfc was, "if you're trying to accomplish thing X,
> here's one way to do it." sadly for me, because of the ietf's
> imprimatur, such specifications will be used in industry as if they were
> recommendations.
>
>
>
> in the specific example of edns client subnet, i have previously
> supplied extensive technical argument against the systemic costs of
> expanding the Q-tuple in this way. those arguments did not find
> consensus in the WG, and are not reflected in the draft. see also
> "afasterinetnet.com".
>

the edns-client-subnet is a very specific edge case - it has 
security/privacy issues, it's done poorly, and even the current authors 
want to fix what is there.

In the shepherd document I wrote the following:

	"There are security issues with this version, as raised by
	various people.  They are correct, and the intent is not to
	correct the security flaws with this document, but to describe
	how this option behaves currently.  It is suggested a new
	version will be worked on in a year which addresses the
	security issues, and addresses other issues about this option."

While you are right that such specifications may be used in industry as 
recommendations, having several large vendors deploying something has 
the same effect. My current employer was convinced that client-subnet 
was already a 'standard' and wanted to know why didn't everyone support 
it.  Educating employers have always been the rock some of us push 
uphill every day.

tim

---

From: Tony Finch <[email-masked]>
Date: Mon, 21 Dec 2015 13:13:10 +0000

Paul Vixie <[email-masked]> wrote:
>
> any HTTP initiator who wants out of order response processing will have
> to negotiate for it (see mogul's 2001 RID draft) and will then have new
> responsibilities for matching up the out of order HTTP responses with
> then-outstanding HTTP requests.

The current way to deal with out-of-order responses and head-of-line
blocking in HTTP is HTTP/2.

If you do DNS over HTTP then there has to be an exact correspondence
between HTTP requests and responses and DNS requests and responses -
anything else would be madness. This implies that DNS over HTTP/1 only
supports in-order pipelined queries and responses in each connection; to
avoid head-of-line blocking you need either multiple connections or
HTTP/2.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames, Dover: Southwest 6 to gale 8, occasionally severe gale 9.
Rough or very rough. Rain or showers. Good, occasionally poor.

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 21 Dec 2015 08:18:40 -0800

> avoid head-of-line blocking you need either multiple connections or

+1. If the authors of the document want to keep using HTTP 1.1 and thus 
lose the ability to do out-of-order responses, that's fine, but they 
have to be explicit about it.

As to the question in the Subject of this thread: I'm in favor of doing 
this in the DNSOP WG if the result will use modern IETF standards like 
HTTP/2 and TLS.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Dec 2015 14:25:37 -0800

> blocking in HTTP is HTTP/2.

since http/2 is a completely new protocol, i think that's a strange way to say it. as you point 
out below, existing HTTP initiators accomplish out-of-order processing by using multiple 
parallel HTTP/1.1 TCP sessions. how the HTTP asynchrony is achieved is beyond the scope 
of an HTTP application spec such as DNS-over-HTTP. i will suggest some text below.

> avoid head-of-line blocking you need either multiple connections or

by all means let us add text to the effect that "HTTP/1.1 or later can be used, with the DNS-
over-HTTP initiator having the responsibility to discover what HTTP protocol version the 
responder supports, and to speak that protocol version correctly -- for example, if an HTTP 
protocol version supports multiple outstanding requests and out of order responses, then 
the DNS-over-HTTP initiator is required to match inbound HTTP responses with outstanding 
DNS requests."

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Dec 2015 11:00:22 +0000

Paul Vixie <[email-masked]> wrote:
> since http/2 is a completely new protocol, i think that's a strange way
> to say it.

Not completely - it has the same message semantics, they "just" changed
how the messages are transported.

So another way of phrasing my previous message is that DNS-over-HTTP ought
to be "just" a mapping from DNS messages to HTTP messages.

* for varying difficulties of "just"

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle: South veering southwest 6 to gale 8, increasing severe gale 9 at
times, perhaps storm 10 later. Rough or very rough, becoming high or very
high. Rain then thundery showers. Good, occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Dec 2015 19:58:07 -0800

> to be "just" a mapping from DNS messages to HTTP messages.

i agree. the only specification matter is the transform between message formats. there's no 
reason to talk about transport at all. 

-- 
P Vixie

---

From: George Michaelson <[email-masked]>
Date: Wed, 23 Dec 2015 15:13:04 +1000

I'd be interested in the cache effects. If the TTL is mapped into cache
age, then there is potential for CDN distribution to work more better
gooder.

More for entertainment value, since label compression is totally bogus,
like carrying forward ASCII only standards documents I mean who does that
.. ok sorry But really, if we didn't do label compression, and we did do
UTF-8 instead of punycode, would we still be DNS?

-G

On Wed, Dec 23, 2015 at 1:58 PM, Paul Vixie <[email-masked]> wrote:

> i agree. the only specification matter is the transform between message
> formats. there's no reason to talk about transport at all.
>
>
>
> --
>
> P Vixie
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Dec 2015 21:15:31 -0800

> age, then there is potential for CDN distribution to work more better

for that, you need a RESTful/JSON interface. the method+URI is a cache key.

-- 
P. Vixie

---

From: George Michaelson <[email-masked]>
Date: Wed, 23 Dec 2015 15:20:05 +1000

I think the REST/JSON conversation is worth having too! Didn't Jay Daley
submit some ideas on that a while back?

-G

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Dec 2015 21:21:52 -0800

On Wednesday, December 23, 2015 03:20:05 PM George 
> submit some ideas on that a while back?

https://datatracker.ietf.org/doc/draft-bortzmeyer-dns-json/history/

-- 
P. Vixie

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Dec 2015 00:28:01 -0500

If you want to do this...

Why not just do Web Sockets and run plain old DNS over TCP. Its not
going to be tremendously fast but it is the shortest distance between
two points and there would be almost no new code needed.

---

From: George Michaelson <[email-masked]>
Date: Wed, 23 Dec 2015 15:32:14 +1000

https://www.ietf.org/mail-archive/web/dnsop/current/msg10479.html

et seq.

-G

On Wed, Dec 23, 2015 at 3:21 PM, Paul Vixie <[email-masked]> wrote:

> On Wednesday, December 23, 2015 03:20:05 PM George Michaelson wrote:
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Dec 2015 23:56:16 -0800

> two points and there would be almost no new code needed.

i think the goal is to get the web caching/proxy system to be able to cache dns results. 
using REST, this could be done. using websockets, not so much.

but as a broader matter, you make a good point. ws and wss (websockets and secure 
websockets) would be a fine transport for dns-over-tcp in general, since it already has 
connection persistency, which is otherwise something that tcp/53 speakers will have to 
negotiate.

-- 
P Vixie

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 23 Dec 2015 07:35:01 -0800

> reason to talk about transport at all.

-1. The IETF has a decade-old rule that you cannot just say "send stuff 
over HTTP" without considering the HTTP-specific semantics. If you want 
this to be an IETF WG document, you have to do things the IETF way.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Dec 2015 15:42:18 +0000

Paul Hoffman <[email-masked]> wrote:
> > i agree. the only specification matter is the transform between
> > message formats. there's no reason to talk about transport at all.
>
> -1. The IETF has a decade-old rule that you cannot just say "send stuff over
> HTTP" without considering the HTTP-specific semantics.

Isn't that what mapping from DNS messages to HTTP messages means? I
completely agree that the spec must to consider the HTTP-specific
semantics and Paul's comments about cache-friendliness [1] imply the same,
so I think you are disagreeing with something we didn't intend to say.

[1] http://www.ietf.org/mail-archive/web/dnsop/current/msg16330.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest Faeroes, Southeast Iceland: Westerly 7 to severe gale 9, becoming
cyclonic gale 8 to storm 10 later. Very rough or high. Rain or wintry showers.
Good, occasionally poor.