Subject: moving forward on draft-lear-httpbis-svcinfo-rr

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Feb 2013 10:04:23 +0100

Hi everyone,

At the interim meeting we discussed this draft in several different
contexts.  Here is my understanding of what people would like to see,
going forward:

1.  Change the InstanceId to be something mnemonic instead of a number,
so that services can have names.
2.  Combine transport protocol and version information into a profile
3.  Add a text field that can provide browser hints.

I have no issues with the first two.  There were two examples given for
the 3rd: browser hints and BDP.  I think we decided that BDP wouldn't
work well, so do people agree that browser hints are appropriate for
DNS?  If so, what's a good example?

Thanks,

Eliot

---

From: Roberto Peon <[email-masked]>
Date: Tue, 5 Feb 2013 13:06:15 -0800

I don't remember BDP being one of these, though we did have discussion that
talked about BDP in relation to some of the settings.
These were more along the lines of max-concurrent-streams,
max-compressor-state-size, and various other HTTP/2 specific settings that
the client should know about/respect.

-=R

---

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Feb 2013 22:14:00 +0100

On 2/5/13 10:06 PM, Roberto Peon wrote:
> I don't remember BDP being one of these, though we did have discussion
> that talked about BDP in relation to some of the settings.
> max-compressor-state-size, and various other HTTP/2 specific settings
> that the client should know about/respect.

Ok, next question: given that we're mandating a settings frame as part
of connection initialization (at least I think we agreed on that), does
putting this stuff in DNS save anything?

Eliot

---

From: Roberto Peon <[email-masked]>
Date: Tue, 5 Feb 2013 13:17:51 -0800

It will in certain use-cases, e.g. restarting a browser with many open
tabs, using a webapp or native application accessing a remote site, or when
a service is experiencing heavy load (it may decrease the max compression
state size), etc.
-=R

On Tue, Feb 5, 2013 at 1:14 PM, Eliot Lear <[email-masked]> wrote:

> Ok, next question: given that we're mandating a settings frame as part of
> connection initialization (at least I think we agreed on that), does

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 6 Feb 2013 06:27:28 +0900

My comment on those was that many of the initial SETTINGS defaults are
there for safety reasons (don't DoS servers). We'd have to sign the
records in order to allow stuff like max-concurrent-streams, otherwise
attackers can use it to increase load on servers. The advantage of
allowing these is avoiding the roundtrip to get a SETTINGS from the
server. This might allow stuff like immediately having higher
parallelism, rather than the default 100 streams.

If we stuff SETTINGS into the DNS record, we'd have to keep in mind
TTL. Either the record would need to include TTL info for the
SETTINGS, or it'd have to be coupled with the record's TTL, which I
think is probably undesirable.

On Wed, Feb 6, 2013 at 6:14 AM, Eliot Lear <[email-masked]> wrote:
> connection initialization (at least I think we agreed on that), does putting
> this stuff in DNS save anything?
>
> Eliot
>

On Wed, Feb 6, 2013 at 6:14 AM, Eliot Lear <[email-masked]> wrote:
> connection initialization (at least I think we agreed on that), does putting
> this stuff in DNS save anything?
>
> Eliot
>

---

From: James M Snell <[email-masked]>
Date: Tue, 5 Feb 2013 13:33:47 -0800

I suspect that several of the settings (compression state, flow control,
etc) are simply going to be too dynamic for us to rely on DNS.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 Feb 2013 08:56:45 +1100

... and looking at Browser Hints (or at least the cut-down revision that I haven't submitted yet), there's not an obvious win (yet).

How about we punt on this aspect of the record for now? Maybe leave an opaque blob in the record for (potential) later use?

Cheers,

On 06/02/2013, at 8:33 AM, James M Snell <[email-masked]> wrote:

> I suspect that several of the settings (compression state, flow control, etc) are simply going to be too dynamic for us to rely on DNS. 
> 
> 
> It will in certain use-cases, e.g. restarting a browser with many open tabs, using a webapp or native application accessing a remote site, or when a service is experiencing heavy load (it may decrease the max compression state size), etc.
> -=R
> 
> 
>> I don't remember BDP being one of these, though we did have discussion that talked about BDP in relation to some of the settings.
>> These were more along the lines of max-concurrent-streams, max-compressor-state-size, and various other HTTP/2 specific settings that the client should know about/respect.
> 
> Ok, next question: given that we're mandating a settings frame as part of connection initialization (at least I think we agreed on that), does putting this stuff in DNS save anything?
> 
> Eliot
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Roberto Peon <[email-masked]>
Date: Tue, 5 Feb 2013 13:58:51 -0800

What he said :)
-=R

On Tue, Feb 5, 2013 at 1:56 PM, Mark Nottingham <[email-masked]> wrote:

> ... and looking at Browser Hints (or at least the cut-down revision that I
> haven't submitted yet), there's not an obvious win (yet).
>
> How about we punt on this aspect of the record for now? Maybe leave an
> opaque blob in the record for (potential) later use?
>
> Cheers,
>
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 06 Feb 2013 09:32:58 +0900

First, what others (e.g. Mark) said. Second, some details below.

> think is probably undesirable.

I think you mean that you want the SETTINGs in the DNS record to have a 
shorter TTL than the record itself. But that couldn't possibly work. The 
browser would understand the SETTINGs and would poll DNS with an 
interval corresponding to the higher SETTINGs TTL, but DNS caches would 
only use the lower DNS record TTL and therefore wouldn't get updated.

Regards,   Martin.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 5 Feb 2013 16:35:11 -0800

I think he means that whomever put the data in there could a time/date
beyond which that field was considered stale and shouldn't be interpreted
by clients.
This wouldn't be necessary if we could trust DNS down through to the client
to actually follow TTL, but.. fact is, we can't.

-=R

On Tue, Feb 5, 2013 at 4:32 PM, "Martin J. Dürst" <[email-masked]>wrote:

> browser would understand the SETTINGs and would poll DNS with an interval
> corresponding to the higher SETTINGs TTL, but DNS caches would only use the
> lower DNS record TTL and therefore wouldn't get updated.
>
> Regards,   Martin.
>

---

From: Mike Belshe <[email-masked]>
Date: Sun, 10 Feb 2013 13:56:37 -0800

I am sorry if this sounds too negative.

But personally, I don't think this proposal is a good avenue to take at
all.  Further, I don't believe there will be any significant
implementations of it.  I heard similar comments from others offline, but
I'll let them speak up here.

I would propose:
   a) Find out if there is really any support for this approach from
implementors
   b) If so, have at it!
   c) If not, let's table it and move on

Mike

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Feb 2013 16:17:06 +1100

We heard strong interest from at least Patrick, IIRC. I'm sure he'll correct me if I got that wrong.

To be clear - we're NOT planning on implementing this first, nor blocking on it. However, as discussed in Tokyo, it's worth doing in a background thread, because (as Eliot pointed out there), sometimes getting DNS things moving takes a while.

Eliot - a major portion of the conversation was about whether this would be in a new record type vs. in a TXT record. Do you plan to address that in your next draft? 

Cheers,

On 11/02/2013, at 8:56 AM, Mike Belshe <[email-masked]> wrote:

> But personally, I don't think this proposal is a good avenue to take at all.  Further, I don't believe there will be any significant implementations of it.  I heard similar comments from others offline, but I'll let them speak up here.
> 
> I would propose:
>    a) Find out if there is really any support for this approach from implementors
>    b) If so, have at it!

---

From: Eliot Lear <[email-masked]>
Date: Mon, 11 Feb 2013 16:25:02 +0100

[Note I'm on vacation and avoiding the computer]

> Eliot - a major portion of the conversation was about whether this would be in a new record type vs. in a TXT record. Do you plan to address that in your next draft? 

I think the conversation was about whether to a use a text formed record
rather than a binary encoded one.  Using TXT wouldn't be a good idea for
any number of reasons.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 Feb 2013 10:54:04 -0500

We really should not be using TXT here because any record that is specific
to a protocol needs to have a prefix so that a query can be made for just
the records relevant to that protocol. Otherwise the DNS UDP response limit
is quickly exceeded.

I much prefer to go for a text encoded tag value pair approach for
application level attributes because that allows the same syntax to be used
in the HTTP (or whatever) header and the DNS record.

More generally though, I think that if we are going to introduce a new
record it should be a record that allows for more than just HTTP version
agility which is essentially one bit of information. Making a UDP round
trip for a single bit of information seems excessive.

I would rather see any DNS work as being an application layer proposal that
should support all application transports and in particular allow
negotiation between HTTP, HTTPS and COAP transports.

On Mon, Feb 11, 2013 at 10:25 AM, Eliot Lear <[email-masked]> wrote:

> > Eliot - a major portion of the conversation was about whether this would
> be in a new record type vs. in a TXT record. Do you plan to address that in
> your next draft?
> >
>

-- 
Website: http://hallambaker.com/

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Feb 2013 14:43:27 -0800

I'm not saying that it's a good design, but...

DKIM uses an underscore prefixed sub-domain and TXT.

On 11 February 2013 07:54, Phillip Hallam-Baker <[email-masked]> wrote:
> agility which is essentially one bit of information. Making a UDP round trip
> for a single bit of information seems excessive.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 Feb 2013 18:20:55 -0500

Actually,

> DKIM uses an underscore prefixed sub-domain and TXT.

And is subject to huge problems with wildcarding as a result.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Feb 2013 07:38:23 +0100

> DKIM uses an underscore prefixed sub-domain and TXT.

That's right.  There's a practice of doing just that, and so long as we
are sending out multiple queries, and we are not attempting to add
indirection a'la SRV (which requires that you wait for a complete
response), we could play that game too.  But it does mean that even with
signed records we are forever more sending out multiple queries.  There
are many tricks we can play when the QNAME is the same.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Feb 2013 07:40:14 +0100

On 2/12/13 12:20 AM, Phillip Hallam-Baker wrote:
> Actually, 
>
> On Mon, Feb 11, 2013 at 5:43 PM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>

Well, there are a few issues, one of which has to do with the nature of
mail and the desire to state policies for an entire enterprise, which is
not something that can easily be done in any event, because zone cuts
are hidden from the client.  But I don't think that these issues are in
play here.