IETF
ohttp
ohttp@jabber.ietf.org
Wednesday, July 28, 2021< ^ >
Room Configuration
Room Occupants

GMT+0
[00:00:04] <Watson Ladd_web_318> deployed now vs. yet to be designed maters a lot.
[00:00:12] <Watson Ladd_web_318> @sftcd: inherent tradeoffs
[00:00:20] <dkg> aiui, defense against a global passive adversary is out of scope for Tor because Tor wants to prioritize usability
[00:00:21] <Watson Ladd_web_318> mixnets work for email, maybe
[00:00:28] <Jonathan Hoyland_web_493> @sftcd It would be nice to have such a protocol to exist, but this protocol isn't trying to be that protocol.
[00:00:32] Kazunori Fujiwara_web_845 joins the room
[00:00:38] <sftcd> there is a real caveat wrt standardising Tor - they cannot afford to spend the cycles we do on changes
[00:00:57] John Preuß Mattsson_web_479 leaves the room
[00:00:58] Roman Danyliw_web_682 leaves the room
[00:01:01] John Preuß Mattsson_web_988 joins the room
[00:01:05] Roman Danyliw_web_849 joins the room
[00:01:06] Lixia Zhang_web_711 leaves the room
[00:01:09] <dkg> and defense against a global passive adversary is likely to introduce unbearable latency
[00:01:14] <Matthew Finkel_web_244> Tor, as defined, does not protect against a GPA...yes, as dkg said. A mixnet is an alternative design that does try protecting against that adversary.
[00:01:17] <sftcd> @jonathan: sure, my question is whether we'd be better off with a more generic target and not a "just these few not that well-defined use-cases" approach we have here
[00:01:26] <Matthew Finkel_web_244> But this is not related to OHTTP
[00:01:30] <Jonathan Hoyland_web_493> @dkg s/likely/mathematically guaranteed/
[00:01:35] Paul Wouters_web_769 leaves the room
[00:01:46] <Chris Lemmons_web_804> It sounds like a lot of the discussion boils down to "OHTTP doesn't solve this problem that OHTTP doesn'try to solve".
[00:01:48] <sftcd> IMO these are related things - we only have so many cycles to spend on improving stuff
[00:01:53] <Watson Ladd_web_318> what's the benefit of standardization for Tor?
[00:01:54] <dkg> mathematically guaranteed seems pretty likely :P
[00:01:57] Christian Amsüss_web_790 leaves the room
[00:01:57] <Jason Livingood_web_872> Is the GPA a commercial entity or governmental or both?
[00:01:57] <Sean Turner_web_433> The OHTTP working group will include an applicability statement that documents the limitations of this design and any usage constraints that are necessary to ensure that the protocol is secure. The working group will consider the operational impact as part of the protocol design and document operational considerations.
[00:02:04] <Eliot Lear_web_684> @stephen you have to start with at least some specific worked examples; and to be fair to Martin, he has done so at least in broad strokes.
[00:02:43] <Zaheduzzaman Sarker_web_668> +1 to spell out this is not for general browsing
[00:02:46] <sftcd> @Eliot: i'm not trying to attack or be unfair (and might well be supportive of ohttp) but it seems correct to express the directional concern at a BoF
[00:02:57] <Jonathan Hoyland_web_493> @dkg See https://petsymposium.org/2020/files/papers/issue3/popets-2020-0056.pdf and https://freedom.cs.purdue.edu/assets/beyond-mix-nets.pdf for example.
[00:02:58] <ekr@jabber.org> It is not technically possible to use it for general browsing.
[00:02:59] <kaduk@jabber.org/barnowl> > protocol is secure
Sean, what does "secure" mean?
[00:03:30] <sftcd> no evil bit:-)
[00:03:30] whalen@jabber.org leaves the room
[00:03:32] <Matthew Finkel_web_244> But, related to Tor, I'm actually supportive of using Tor *and* OHTTP because DNS support in Tor is complicated and not ideal.
[00:03:41] Rebecca Guthrie_web_636 joins the room
[00:03:47] <Martin Thomson_web_799> if the protocol is used outside of the imagined use cases... isn't that what success looks like?
[00:03:48] <Zaheduzzaman Sarker_web_668> the general browsing confusion may well be coming from the name of the potential working group
[00:03:50] Karen O'Donoghue_web_939 joins the room
[00:03:51] Nicklas Pousette_web_113 leaves the room
[00:04:02] Stephen Farrell_web_262 leaves the room
[00:04:06] Stephen Farrell_web_919 joins the room
[00:04:23] <Shivan Sahib_web_272> @Matthew supportive of using Tor and OHTTP or supportive of using Tor and ODoH in particular?
[00:04:24] <Eliot Lear_web_684> @Stephen, sorry- I didn't meant to imply that you were attacking.  Initially things were a bit vague.  The three use cases discussed are interesting, and I'm quite comfortable with two of them.  And that's probably worth exploring, perhaps in the WG.
[00:04:24] whalen@jabber.org joins the room
[00:04:32] <Jonathan Hoyland_web_493> @sftcd I agree this is the right place to discuss direction, but I think this is a protocol for protecting the client from the server, but not the client from a passive observer.
[00:04:34] Stephen McQuistin_web_981 joins the room
[00:04:37] <David Oliver_web_744> @zs absolutely. Outside this narrow group of engineers, and particularly in the human rights area, the name is very confusing
[00:04:39] <Watson Ladd_web_318> The whole point of permissionless innovation is that you don't need to ask permission.
[00:04:40] <Jari Arkko_web_522> Oh and I forgot to respond to Tommy. I do think that if we are creating a tech we need to handle the important aspects of that tech. We can't push off discovery or other important aspects to some future unspecified effort, that would just lead to nobody having discovery and further consolidation.
[00:04:59] Jay Daley_web_610 joins the room
[00:05:05] <sftcd> @jonathan: wouldn't Tor protect the client from the server as much as this? what's the diff/
[00:05:08] <Martin Thomson_web_799> Use cases and use case limitations are in the draft.  They are short enough.  Andrew C, did you want to open an issue on the draft, identifying what specifically should be added?
[00:05:11] <sftcd> @jonathan: wouldn't Tor protect the client from the server as much as this? what's the diff?
[00:05:17] <Sean Turner_web_433> @Andrew as far ops look in 5th para
[00:05:20] <Jonathan Hoyland_web_493> @sftcd TOR is much more expensive.
[00:05:27] <Matthew Finkel_web_244> @Shivan: using OHTTP for DNS queries. I like ODNS a little better, but I see some benefit in standardizing OHTTP in general
[00:05:40] <sftcd> @jonathan: yes, but that wasn't your question
[00:05:43] Florence D_web_145 leaves the room
[00:05:46] <sftcd> btw thanks for asking mine:-)
[00:05:47] Diego Lopez_web_276 leaves the room
[00:05:51] Diego Lopez_web_887 joins the room
[00:05:57] Florence D_web_104 joins the room
[00:06:08] Florence D_web_104 leaves the room
[00:06:12] Florence D_web_898 joins the room
[00:06:17] <Jonathan Hoyland_web_493> No worries, one upside of living alone is being able to come to the mic at 01:00am :P
[00:06:36] <Chris Lemmons_web_804> I'm not convinced discovery is necessary. There are other ways of deploying without discovery.
[00:06:44] <Alissa Cooper_web_751> wow, lazy!
[00:06:47] <Watson Ladd_web_318> wrt to discovery, what properties need to be discovered? how do you justify noncollusion and honesty?
[00:06:48] <Brendan Moran_web_255> @jonathan: Yup, it is complicated to come to the mic...
[00:07:02] <sftcd> @joanathan: I'm willing to swap my dishwashing duties if you do the "mic:" thing for me sometime:-)
[00:07:08] <Mark Nottingham_web_885> Making discovery a requirement is actively counter-productive
[00:07:12] <kaduk@jabber.org/barnowl> er, who/what is lazy?
[00:07:14] <Christopher Wood_web_401> +1 Mark
[00:07:17] <ekr@jabber.org> +1 Mark
[00:07:22] Tommy Jensen_web_527 leaves the room
[00:07:24] <Christopher Patton_web_151> +1 mark
[00:07:25] <Chris Lemmons_web_804> Discovery seems useful, but incredibly hard.
[00:07:29] Tommy Jensen_web_978 joins the room
[00:07:30] <Ted Hardie_web_425> I think this is a real red herring.
[00:07:30] <David Schinazi_web_243> +1 Mark
[00:07:33] <Chris Lemmons_web_804> +mark
[00:07:39] <Alissa Cooper_web_751> + Mark
[00:07:42] <Martin Thomson_web_799> The charter is clear: it permits discussion of discovery, but NOT blocking on discovery
[00:07:43] <Mark Nottingham_web_885> +1 Ted
[00:07:52] <Alissa Cooper_web_751> @ben: all of us, if I heard correctly
[00:07:55] <nygren> +1 Marj
[00:08:02] <Richard Barnes_web_481> Andrew just described a configuration requirement, not a discovery requirement
[00:08:03] <Watson Ladd_web_318> Discovery != configuration
[00:08:05] <nygren> er, +1 Mark
[00:08:10] <David Schinazi_web_243> "justify why not" makes no sense. You don't build things because people haven't explained why not, you build things when people explain why
[00:08:11] <Richard Barnes_web_481> lol jinx @Watson
[00:08:13] <Jonathan Hoyland_web_493> @Andrew one reason why not is because not every protocol has to be everything to everybody
[00:08:13] <Sean Turner_web_433> @kaduk I mean it's using HPKE :)
[00:08:17] <sftcd> yeah, discovery seems a bit of a red herring to me too (even though I'd prefer a more generic attempt)
[00:08:18] <kaduk@jabber.org/barnowl> Alissa: oh, you mean I'm supposed to be listening to the audio stream
and not just reading jabber? ;)
[00:08:20] Florence D_web_898 leaves the room
[00:08:29] Florence D_web_476 joins the room
[00:08:31] <Alissa Cooper_web_751> :-)
[00:08:42] <sftcd> repeated aside: I still miss watching the body-language of the people in the mic-line:-)
[00:08:49] <Mark Nottingham_web_885> heh
[00:08:59] <cabo> So switch on the videos?
[00:09:12] Daphanie Nisbeth_web_376 joins the room
[00:09:16] <Jonathan Hoyland_web_493> I miss watching people responding to jabber from the mic line by balancing on one foot and using the other leg as a laptop stand.
[00:09:16] <Jonathan Lennox_web_149> I miss the post-meeting photographs of the enormous mic lines at BoFs.
[00:09:17] <Jana Iyengar_web_431> @Stephen -- I totally don't
[00:09:19] <dkg> sftcd: you mean fiddling with their badge so that the scribe can't read their name?
[00:09:24] <Benjamin Schwartz_web_292> That ship sailed with IPSEC
[00:09:26] <Andrew Campling_web_920> @Watson and others: an open method to advertise and find proxies is more than just configuration
[00:09:40] <Watson Ladd_web_318> open method advertising what?
[00:09:42] <Jana Iyengar_web_431> ... and I really enjoy actually hearing folks talking into the mic and not at each other
[00:09:52] <Mark Nottingham_web_885> *mutters*
[00:10:06] <Richard Barnes_web_481> @Andrew - in other words, what is the *input* to the discovery process you envision?
[00:10:09] <Watson Ladd_web_318> like i'm not really getting the outcome you want: a giant list of available proxies i know nothing abnou?
[00:10:12] <Watson Ladd_web_318> *about?
[00:10:14] <sftcd> @jana: yeah but you're a purist,  whereas I'm easily amused:-)
[00:10:15] Roman Danyliw_web_849 leaves the room
[00:10:21] <Chris Lemmons_web_804> I miss hearing someone say something at the mic and seeing 20 people immediately get in line all at once to respond. :)
[00:10:37] <kaduk@jabber.org/barnowl> I think I just started typing what ekr said.
[00:10:43] Roman Danyliw_web_556 joins the room
[00:10:45] <Martin Thomson_web_799> In the DNS setting, discovery might make sense, but we should wait for ADD to produce an outcome we can rely on there.
[00:10:46] <Jonathan Hoyland_web_493> @Chris +100 :rolling_on_the_floor_laughing:
[00:11:02] <kaduk@jabber.org/barnowl> Namely, if you want "discovery", who is discovering what entity, and
how does that work and maintain the required trust properties across
parties?
[00:11:10] <Patrick Tarpey_web_364> put discovery in DHCP codes...
[00:11:27] <Patrick Tarpey_web_364> ;-)
[00:11:27] <Lucas Pardue_web_689> theres loads of HTTP proxy discovery and configuration mechanisms, some of these exist outside the IETF
[00:11:31] <Watson Ladd_web_318> Verizon advertises bad DNS servers
[00:11:34] <dkg> not just the proxy and the endpoint -- also *the relationship between* the proxy and the endpoint
[00:11:35] <Jason Livingood_web_872> For discovery, I hope to discover all the use cases. ;-)
[00:11:38] <Jana Iyengar_web_431> disovery is hard. HARD.
[00:11:43] <Jonathan Hoyland_web_493> You could discover legal agreements that provide non-collusion with endpoints :p
[00:11:44] <Richard Barnes_web_481> @Lucas - all of which post-date CONNET!
[00:11:55] Dan Druta_web_314 leaves the room
[00:12:05] <Tommy Jensen_web_978> @martin coming from ADD, I would say the work is orthogonal. Discovery of encrypted DNS advertised by a network or known resolver really doesn't have much to do with discovery of proxies for a known target. In the former, you WANT collusion. Here, we don't.
[00:12:18] <Andrew Campling_web_920> @MT: the current draft charter suggests discovery is optional but may need to be amended if that is the consensus of this BOF - or why have teh BOF?  
[00:12:25] Dan Druta_web_844 joins the room
[00:12:26] <Chris Lemmons_web_804> And it's worth noting that which proxy you trust can vary considerably for each endpoint.
[00:12:27] Daphanie Nisbeth_web_376 leaves the room
[00:12:32] Florence D_web_476 leaves the room
[00:12:35] <Watson Ladd_web_318> locks and laws both keep men honest, but with different effectiveness
[00:12:37] <sftcd> @ekr: I agree but for me an interesting question is whether it's better to attempt to ask people/clients to "trust" very specific proxies vs. generic ones
[00:12:47] Florence D_web_174 joins the room
[00:12:47] Mohit Sethi_web_408 leaves the room
[00:12:51] <Martin Thomson_web_799> Andrew C: I agree with the charter, not with your point.  Is that not how this works?
[00:13:00] <Andrew Campling_web_920> @TommJ +1 to this having different discovery requirements to ADD
[00:13:02] <Lucas Pardue_web_689> my favorite discovery mechanism is "as a colleague what the SOCKS server settings are"
[00:13:02] whalen@jabber.org leaves the room
[00:13:03] <dkg> Watson Ladd: and not just men
[00:13:06] <Glenn Deen_web_392> The trust model for this is inverted to the being followed in ADD
[00:13:13] <Richard Barnes_web_481> Queue is cut after Tommy J
[00:13:17] <Alexey Melnikov_web_872> End of the queue after Tommy Jensen
[00:13:39] <Tommy Jensen_web_978> @andrew, I don't think we do since I'm saying this charter has _no_ discovery requirements :)
[00:13:48] <Vittorio Bertola_web_262> In general, if the point is protecting the end-user's identity from the server, then the end-user should be able to choose the party they trust - not the server
[00:13:57] <Glenn Deen_web_392> this seems to be build anonymity through end to end trust?  Did I get that right?
[00:14:01] <Mark Nottingham_web_885> +1 Ted
[00:14:02] <dkg> +1 to Ted's summary
[00:14:03] <sftcd> "blinded queries" meaning "biinded queries using the correct HPKE public value"
[00:14:05] <ekr@jabber.org> Vittorio: again, that's an *application* question
[00:14:13] <Francois Ortolan_web_796> +1 Vittorio
[00:14:24] <Mark Nottingham_web_885> Using terms like "proxy" are confusing
[00:14:26] <Watson Ladd_web_318> how does discovery help that here?
[00:14:33] <Benjamin Schwartz_web_292> "Oblivious RPC"
[00:14:33] <Andrew Campling_web_920> @MT: You seemed to imply that we're stuck with the current charter text as written irrespective of this discussion.  Apologies if I misunderstood.  
[00:14:46] <Eliot Lear_web_684> Can we finally get a protocol/framework name called "Bruce"?
[00:14:52] <Vittorio Bertola_web_262> But if the protocol does not help the end-user to have as much choice as possible, then it's harder for the users to protect themselves
[00:14:54] <dkg> Benjamin Schwartz: but it's http-based RPC, so i think you want "oblivious HRPC"
[00:14:54] <Martin Thomson_web_799> Not at all, the point of this is flexible.
[00:14:57] <Lucy Lynch_web_628> who curates the trusted parties list?
[00:14:59] <kaduk@jabber.org/barnowl> > ask people/clients to "trust" ... [specific/generic proxies]
But the endpoint has to trust the proxy, too!  What if the
intersection of who the client trusts and who the endpoint trusts is
empty?
[00:15:03] <ekr@jabber.org> For instance, here is CheckList, which is the state of the art for blocklist: https://eprint.iacr.org/2021/345
[00:15:06] Jon Peterson_web_113 leaves the room
[00:15:07] <Carrick_web_582> @mnot: how is the term "proxy" confusing?
[00:15:10] <Mark Nottingham_web_885> Not RPC
[00:15:10] Jon Peterson_web_154 joins the room
[00:15:10] <Éric Vyncke_web_972> I like "oblivious RPC", clearer ;-)
[00:15:11] <ekr@jabber.org> "afe Browsing” blocklist, which all major browsers use to prevent web clients from visiting malware-hosting URLs. Today, lookups to this blocklist leak partial hashes of a subset of clients' visited URLs to Google's servers. We have modified Firefox to perform Safe-Browsing blocklist lookups via Checklist servers, which eliminates the leakage of partial URL hashes from the Firefox client to the blocklist servers. This privacy gain comes at the cost of increasing communication by a factor of 3.3×, and the server-side compute costs by 9.8×. Checklist reduces end-to-end server-side costs by 6.7×, compared to what would be possible with prior state-of-the-art two-server private information retrieval. "
[00:15:11] Éric Vyncke_web_972 leaves the room
[00:15:12] <Jonathan Hoyland_web_493> @sftcd Thinking on what you said, could you imagine a protocol framework that captured both this _and_ TOR.
[00:15:17] Éric Vyncke_web_273 joins the room
[00:15:22] <Mark Nottingham_web_885> @Carrick: because what's being defined is _not_ a HTTP proxy
[00:15:26] <Jason Weil_web_486> Is the goal here to trust one and only one entity?
[00:15:31] Nicolas Kuhn_web_682 leaves the room
[00:15:36] <Jonathan Hoyland_web_493> Given that the guarantees are somewhat similar in type, but different in degree.
[00:15:38] <Watson Ladd_web_318> endpoint doesn't need to trust the proxy necessarily. i have lots of applications where I don't care about submission spam, do want to anonymize
[00:15:50] <Mark Nottingham_web_885> There is a lot of history between HTTP and RPC. Don't. Go. There.
[00:15:52] <ekr@jabber.org> Oh, and also, CheckList is two-party PIR
[00:16:02] <ekr@jabber.org> So it has the same trust model
[00:16:04] <Lucas Pardue_web_689> fast oblivious messages over HTTP
[00:16:06] <dkg> mnot: i was punning on hrpc, not being serious
[00:16:20] <sftcd> @jonathan: I think one could define the mechanics, but it'd maybe fail in two respects 1) Tor has to change as censors do (meaning quickly) and 2) Tor doesn't scale that well
[00:16:23] <Watson Ladd_web_318> I wish we'd standardize a better RPC
[00:16:33] <Mark Nottingham_web_885> I don't
[00:16:35] <nygren> Oblivious Request Broker.   (no, not serious)
[00:16:46] <sftcd> corba!
[00:16:50] <Mark Nottingham_web_885> !!
[00:16:57] <Martin Thomson_web_799> +1 to what Ted says.  You can *sort of* read that from what I wrote in the charter, but we can try harder.
[00:17:02] <Lucas Pardue_web_689> :nauseated_face:
[00:17:04] <Martin Thomson_web_799> Wow, the 90s called.
[00:17:05] <Jari Arkko_web_522> I agree with Ted that clarity in the framing/use cases is useful. But I don't agree that it follows no discovery is needed. I think it is needed at least in some of the cases. DNS is likely one of those cases.
[00:17:22] <Watson Ladd_web_318> what does the user discover? giant list of ones around the world?
[00:17:24] Gustavo Lozano_web_316 joins the room
[00:17:30] <ekr@jabber.org> @Jari: once again, I call on you to describe any setting in which that would be useful
[00:17:37] Gustavo Lozano_web_316 leaves the room
[00:17:41] <ekr@jabber.org> And any entity who would want to consume it
[00:17:42] <Patrick Tarpey_web_364> reliance on two parties...
[00:17:50] <dkg> Jari: discovery *of* *what*?
[00:17:54] Stephan Emile_web_671 leaves the room
[00:17:54] <sftcd> is this a record for the longest virtual BoF mic-line?
[00:17:59] Kazunori Fujiwara_web_845 leaves the room
[00:18:11] <Spencer Dawkins_web_809> I have to ask. Martin seemed to be pretty much finished with A protocol, although maybe not the protocol everyone else would have ended up with. Is this turning into a discussion about chartering an OPS working group to worry about deployment issues, because the protocol, and specification, are the tail on the dog?
[00:18:16] <Martin Thomson_web_799> "the Oblivious HTTP protocol allows a server to accept requests via a proxy.  The proxy ensures" -- this is just a different way of saying what Ted said
[00:18:17] <Jari Arkko_web_522> Ekr: Ok. Fair enough. Lets do that.
[00:18:20] <Patrick Tarpey_web_364> non-collusion...
[00:18:22] <Eliot Lear_web_684> @Stephen- yep.  It's long.
[00:18:28] Kazunori Fujiwara_web_305 joins the room
[00:18:32] Chris Inacio leaves the room: Disconnected: Replaced by new connection
[00:18:36] Chris Inacio joins the room
[00:18:49] Jasdip Singh_web_367 leaves the room
[00:19:01] <Martin Thomson_web_799> question for the room, how many people have read the draft?
[00:19:11] <Lucy Lynch_web_628> me
[00:19:12] <ekr@jabber.org> @MT: Wait, what?? We were supposed to do that?
[00:19:20] <David Schinazi_web_243> There's a draft???
[00:19:21] Benedict Wong_web_719 leaves the room
[00:19:21] <Jonathan Hoyland_web_493> I have. I also build a formal model.
[00:19:27] <Matthew Finkel_web_244> Can't you create a poll?
[00:19:31] <Martin Thomson_web_799> I wrote it, so maybe it doesn't say what I thought it did, but a LOT of these questions are answered there.
[00:19:32] <Eric Orth_web_393> Charter draft or protocol draft (oHTTP or oDoH)?
[00:19:35] <Matthew Finkel_web_244> ("you")
[00:19:42] <Dominique Lazanski_web_199> +1 on security and threat model
[00:19:48] <Mark Nottingham_web_885> MT: calling it a protocol that uses proxies calls into question how it relates to HTTP as a protocol, and how it relates to HTTP proxies. Saying that it's an application (i.e., a definition of a specific kind of resource) is much clearer.
[00:19:56] <Patrick Tarpey_web_364> +1 security and threat model
[00:19:57] <Benjamin Schwartz_web_292> Nygren: We do not hear you.
[00:19:57] <kaduk@jabber.org/barnowl> I'm pretty sure I read the draft.
[00:19:57] <sftcd> FWIW, having heard the discussion so far, I'm worried that this might not be the "best" direction but do support the work going forward as planned by the proponents (and I might lose connectivity in a sec, hence this)
[00:19:59] <Jonathan Hoyland_web_493> https://github.com/cloudflare/ohttp-analysis/
[00:20:19] <Martin Thomson_web_799> Mark: you just want to rename everything.  That's totally in scope for working groups.  You might even say that is all that working groups are good for.
[00:20:27] <Mark Nottingham_web_885> But of course.
[00:20:32] <ekr@jabber.org> How about Oblivious HTTP/3. OH3!
[00:20:45] <Mark Nottingham_web_885> MT/3
[00:20:55] <ekr@jabber.org> @mnot: +1
[00:20:56] <Lars Eggert_web_589> as a meta-comment, i really appreciate it when people turn their video on when they speak - disembodied voices at 3:20am are tiring
[00:20:58] <Jana Iyengar_web_431> I actually like the name.
[00:21:06] <kaduk@jabber.org/barnowl> ekr: only OH_3^+ is chemically stable
[00:21:11] <Jonathan Hoyland_web_493> +1 Lars
[00:21:18] <Eliot Lear_web_684> @Lars, you really don't want to see me at 2:21.
[00:21:23] Jason Weil_web_486 leaves the room
[00:21:24] <Ted Hardie_web_425> @Lars looking presentable at that hour also tiring.
[00:21:25] <ekr@jabber.org> @kaduk: OHH?
[00:21:27] Jason Weil_web_619 joins the room
[00:21:56] <Christopher Patton_web_151> interesting point, Erik!
[00:21:59] <Chris Box_web_555> Agree we need to be super clear on which use cases can use this protocol safely and securely. Lots of people with different interpretations of the concept in this BoF shows the charter text needs to be clearer. Also agree it needs a new name to help with that.
[00:22:07] <Jonathan Hoyland_web_493> Given how much resistance we're seeing to the OHTTP name, how about OHM.
[00:22:08] Al Morton_web_139 joins the room
[00:22:19] <dkg> Hoyland: nice
[00:22:25] <Chris Lemmons_web_804> Oblivious Web Resource?
[00:22:28] <Martin Thomson_web_799> I seem to remember Mark Nottingham giving editors considerable license in naming things.  And regretting that.
[00:22:29] <Watson Ladd_web_318> PRD? private resource delivery?
[00:22:33] <Carrick_web_582> I liked "HOPP"
[00:22:34] <Eric Orth_web_393> Can we just call it "Oblivious"?
[00:22:36] <Brendan Moran_web_255> I wouldn't want to impede the OHM suggestion
[00:22:43] chenmeiling_web_506 leaves the room
[00:22:44] <Francois Ortolan_web_796> +1 security and threat model
[00:22:48] <Christopher Patton_web_151> What does OHM stand for?
[00:23:01] <Brendan Moran_web_255> Oblivious Http Messaging
[00:23:07] <Tommy Jensen_web_978> Oblivious Forwarding of HTTP messages (OFH)?
[00:23:12] chenmeiling_web_786 joins the room
[00:23:15] Stephen Farrell_web_919 leaves the room
[00:23:19] Stephen Farrell_web_404 joins the room
[00:23:25] Zaheduzzaman Sarker_web_668 leaves the room
[00:23:43] <Jonathan Hoyland_web_493> Oblivious HTTP Messagepacks?
[00:23:52] <Martin Thomson_web_799> Quantized Units Independent of Connections ?
[00:24:04] Zaheduzzaman Sarker_web_225 joins the room
[00:24:06] <dkg> oblivious forwarding for services:  OFFS
[00:24:06] Kazunori Fujiwara_web_305 leaves the room
[00:24:07] <Chris Box_web_555> :-)
[00:24:08] <Jonathan Hoyland_web_493> :rolling_on_the_floor_laughing::rolling_on_the_floor_laughing:
[00:24:08] <Christopher Patton_web_151> ha
[00:24:08] <nygren> Do we have the capacity to deal with all of the jokes that would come from OHM?
[00:24:10] <Christopher Patton_web_151> ha
[00:24:14] Kazunori Fujiwara_web_489 joins the room
[00:24:14] chenmeiling_web_786 leaves the room
[00:24:20] <Watson Ladd_web_318> i expect some resistence to that name
[00:24:24] <Eric Orth_web_393> Bonus of the name "Oblivious", lots of letters to later decide what it stands for (and the initial 'O' obviously stands for "Oblivious").
[00:24:36] <Watson Ladd_web_318> and when it gets more complex, some reluctance as well
[00:25:37] <dkg> +1 Jana
[00:25:37] <Andrew Campling_web_920> When considering use cases and when being clear how they use this protocol safely and securely, we also need to think about permissionless innovation, eg fhow to avoid use by C&C etc
[00:25:39] <Stefan Santesson_web_171> "Private HTTP"?
[00:26:01] <Benjamin Schwartz_web_292> If you're in the mic queue, and you're calling for more discovery, please specify the inputs and outputs of your desired discovery process.
[00:26:06] <dkg> Andrew: are you saying that we need to make this so that only the good guys can use this protocol?
[00:26:07] <Patrick Tarpey_web_364> The use cases described so far dovetail with browser software - hard coded ...
[00:26:08] <David Oliver_web_744> Privacy Preserving HTTP -- terrible acronym
[00:26:12] <Jonathan Hoyland_web_493> Mark is no longer just a disembodied head!
[00:26:15] <Chris Lemmons_web_804> Oblivious Web Services
[00:26:23] <Watson Ladd_web_318> there's a bit for that
[00:26:38] <cabo> I don't normally fly above the mic line
[00:26:42] <Carrick_web_582> @Jonathan: :(
[00:26:51] <Jana Iyengar_web_431> Mark is exactly a "disembodied head"
[00:27:02] <dkg> a disembodied head in the morning, though
[00:27:16] <kaduk@jabber.org/barnowl> Mark at 3am was very much a disembodied head
[00:27:19] <Brendan Moran_web_255> @watson If you have client authentication to the proxy, it should be called "admittance"
[00:27:31] <Mike Bishop_web_188> Of course HTTP has a discovery mechanism -- HTTPS/SVCB!
[00:27:34] <Jana Iyengar_web_431> given how everyone I've seen over the past couple of days, we are a disembodied herd
[00:27:42] <Jonathan Hoyland_web_493> @Watson @Brendan What have I started?
[00:27:50] <ekr@jabber.org> Sorry about the speed, but trying to make room!
[00:28:04] <Brendan Moran_web_255> @Jonathan: a thing of beauty, naturally!
[00:28:04] <Sean Turner_web_433> applicability statement ;)
[00:28:13] <Sean Turner_web_433> it's there!
[00:28:15] <Benjamin Schwartz_web_292> Mike: I would say the discovery mechanism is "<a href=..."
[00:28:27] <Benjamin Schwartz_web_292> argh, HTML tag stripping
[00:28:43] <Mike Bishop_web_188> I feel like there are two distinct sets of use-cases; in one, discovery is useful and in the other it's completely extraneous.  The draft limits its goals to one side of that divide.
[00:29:00] James Gruessing_web_861 leaves the room
[00:29:05] <ekr@jabber.org> Wow, misread the queue and was like "This definiteily isn't watson ladd"
[00:29:05] <Jana Iyengar_web_431> I don't think use cases belong in the charter.
[00:29:14] <Jari Arkko_web_522> +1 on better description of non-usecases
[00:29:17] <Mike Bishop_web_188> @Ben, \<a href=""\>?
[00:29:21] <dkg> Oblivious Watson Ladd
[00:29:28] <Jana Iyengar_web_431> OWL
[00:29:28] <Mike Bishop_web_188> Apparently not.
[00:29:32] <Jonathan Hoyland_web_493> :joy:
[00:29:38] <Martin Thomson_web_799> Jana, my point exactly.
[00:29:39] <Benjamin Schwartz_web_292> Mike: Anyway, I think "a href=..." is a discovery mechanism for HTTP.
[00:29:44] <Christopher Patton_web_151> Watson is one of the least oblivious people I've ever met
[00:29:46] <Mark Nottingham_web_885> I'm fine if the charter lists some out of scope things. By necessity it can't be complete, and of course it can't limit what people actually do.
[00:29:46] <Andrew Campling_web_920> +1 to Toerless on the need for more documentation, to be included in the charter milestones alongside the protocol itself (ditto use cases / limitations etc)
[00:29:59] Samuel Weiler_web_131 leaves the room
[00:30:11] <Thomas Mangin_web_778> You can not have 'non use case' I will use the technology as I please :-) Understanding planned use case and why the work is being done is good but it can not be exclusive !
[00:30:12] <Spencer Dawkins_web_809> @Jana, I might agree about the use cases in the charter, but I think the constraint ("not intended to be used with discovery") could be clear.
[00:30:12] <David Schinazi_web_243> Some of the folks asking for these nebulous explainer documents should perhaps volunteer to write them?
[00:30:15] Samuel Weiler_web_612 joins the room
[00:30:15] <Daniel Migault_web_727> would it make sense to have ohttp as svcb parameter ?
[00:30:19] <Alissa Cooper_web_751> For avoidance of doubt, I think the use case clarification is like 2 sentences long.
[00:30:31] <ekr@jabber.org> @Daniel: No
[00:30:42] <Mark Nottingham_web_885> +12 Alissa. Requiring long explainers is make-work
[00:30:45] <ekr@jabber.org> Because it cannot be trusted
[00:30:51] <dkg> Thomas Mangin: describing a non-use case is a way to *dismiss* proposed changes that are targeted at that case
[00:31:19] <Jonathan Hoyland_web_493> @Thomas it's true you can't have a non-use case, but you can say "our security guarantees only apply if you fit in this small bubble."
[00:31:25] Chris Inacio leaves the room: Disconnected: Replaced by new connection
[00:31:29] Chris Inacio joins the room
[00:31:32] <Thomas Mangin_web_778> @dkg, I am fine with documenting it but it has no force
[00:31:35] <ekr@jabber.org> @Jonathan: Well, in this case it's also "this literally will not work in these cases"
[00:31:48] <Lucas Pardue_web_689> you could say this work "renders roles: oblivious"
[00:32:05] <Jonathan Hoyland_web_493> @ekr that too.
[00:32:25] <Mike Bishop_web_188> @Daniel, when the client and server aren't the same party, yes; when the client and server are the same party, no.
[00:32:28] <Christopher Patton_web_151> +Watson
[00:32:31] whalen@jabber.org joins the room
[00:32:33] <Vittorio Bertola_web_262> @ekr: This should be spelled out in the charter though, or no one guarantees that the mechanism that currently makes it technically impossible to use this for general browsing won't be removed during the WG's work
[00:32:35] <dkg> Thomas: it has force during the specification process, not during deployment.
[00:32:41] <Zaheduzzaman Sarker_web_225> there have been good discussions in this meeting that should help improving the applicability statement part of the charter text.. say something along what Ted said would be helpful ..
[00:32:47] <David Schinazi_web_243> That's RFC 7258 :)
[00:32:54] <nygren> A svcb parameter might cover lots of the elements of discovery needs, at least for distributing keys and indicating the classes of proxies supported.
[00:32:55] <Martin Thomson_web_799> Watson said it: the goal of a BoF is to determine if there is interest in finding a constituency around a protocol, such that it might be specified, implemented, and deployed.  It is not a process of loading up those people with extra work in the hopes that they might fail.
[00:33:06] <Jana Iyengar_web_431> Does anyone think that articulation of use cases will change the work that might happen? Or are you not convinced that there aren't good enough use cases?
[00:33:07] <ekr@jabber.org> @Vittorio: there's no one mechanism. It's like the whole structure of the system. It's what makes it worth doing rather than MASQUE
[00:33:18] <Mirja Kühlewind_web_871> someone asked this in the chat early on but not sure it was further discussed: What is the expectation about who runs the proxy?
[00:33:18] <Watson Ladd_web_318> far more elegantly than I did
[00:33:21] <dkg> cooperating but not colluding :)
[00:33:35] <Jari Arkko_web_522> Watson: I don't think discovery means that ISPs need to get into the application. For me, it means that for instance me as a user can have control over what's being done and by which services, as opposed to having fixed things by say a browser.
[00:33:47] <Watson Ladd_web_318> that's configuration
[00:34:02] <Mark Nottingham_web_885> +1 Tommy - very well put
[00:34:06] <Vittorio Bertola_web_262> I don't think it is fair or useful to assume that the people that came up with concerns are trying to make this fail.
[00:34:12] <Éric Vyncke_web_273> @mirja this is part of my concerns...
[00:34:14] <Andrew Campling_web_920> +1 Jari
[00:34:15] <Daniel Migault_web_727> @ekr with DNSSEC (just assuming it is enabled) we would have the same level of trust as the server.  Of course client and sevrers needs to be different parties.
[00:34:23] <Jana Iyengar_web_431> +1 Tommy. Configuration is a fine way to deploy this.
[00:34:24] <Watson Ladd_web_318> and in the application i have in mind, that works, but I want a default so that users don't need explicit action to protect their privacy
[00:34:27] <Christopher Patton_web_151> Use cases: DNS; safe browsing; telemetry, ...
[00:34:40] <Thomas Mangin_web_778> for me the discussion should be about configuration due to the trust discussion presented (and not discussed enough IMHO)
[00:34:45] <Lucas Pardue_web_689> are there (m)any success stories of techincal means of discovery?
[00:34:46] <ekr@jabber.org> @Daniel: yes, if you had DNSSEC, then it would be of value, but we just aren't designing stuff that assumes DNSSEC
[00:34:48] <Eliot Lear_web_684> I feel like people have repeated their arguments... repeatedly...
[00:35:08] <Martin Thomson_web_799> Eliot: why be surprised?
[00:35:13] <Wes Hardaker_web_757> @eliot: it's an ietf mic line, right?
[00:35:20] <Jonathan Hoyland_web_493> Oh, can't remember who said it, but I don't see how you could use this for OCSP, because how would you bootstrap trust?
[00:35:23] <Chris Lemmons_web_804> ODOHs: All the names, none of the buzz.
[00:35:28] <Watson Ladd_web_318> Vittorio, I apologize for missing you in the queue, not sure what your concerns where
[00:35:33] <David Schinazi_web_243> @Jari in the use cases described, I can say with a lot of certainty that Chrome will not use a discovery mechanism even if one were to be standardized. Because discovery provides no value to these use cases. Therefore it will not make any change to how much the world is centralized
[00:35:35] <Daniel Migault_web_727> @Mike thanks.
[00:35:37] <ekr@jabber.org> @JHoyland: I can imagine a number of mechanisms.
[00:35:37] <Carrick_web_582> @Jonathan Preconfiguration
[00:35:43] <Watson Ladd_web_318> @Jonathan: out of band, OCSP signed so not a problem
[00:35:44] <ekr@jabber.org> but yeah, it's not amazing
[00:35:45] <Keith Bare> I'll note that a thing that I found confusing reading the charter is where the protocol is used.  It wasn't obvious to me to me when I read the charter the proposed protocol is used *both* between the client and proxy as well as between the proxy and server.  (It's clear in the draft though.)  That, I think is one reason I at least thought this might be applicable for general browsing, rather than the specific use-cases that have been discussed during this session.  I visualized something more like CONNECT after reading the charter.
[00:35:56] <Daniel Migault_web_727> @ekr ok, I see. Thanks!
[00:36:03] <Benjamin Schwartz_web_292> ODOH discovery via a local network mechanism is an even weirder trust model, given that we _know_ there is an adversary with sufficient traffic analysis visibility to deanonymize.
[00:36:09] Deb Cooley_web_200 leaves the room
[00:37:17] <Jari Arkko_web_522> @david are you saying that me as a user for instance will have no way of affecting what Chrome will do, nor will I be able to have my own infrastructure employ some proxy services? Google will decide what proxies it will route my traffic through? That's unfortunate, if so.
[00:37:34] <Pete Resnick_web_490> One reason for the use cases and limitations in the charter is to keep certain people from having some of these discussions in the WG itself; you want to be able to say, "Look at paragraph 5 of the charter; please go away."
[00:37:59] <ekr@jabber.org> @Jari: so are you sad that you can't send Chrome Telemetry to some other place?
[00:38:03] <Jonathan Hoyland_web_493> @Keith one interesting thing that falls out of the formal analysis is that you can have the proxy drop the outer layer of TLS / QUIC encryption, and the security guarantees don't change.
[00:38:04] <Jana Iyengar_web_431> @Jari -- clearly that's not how it's going to happen. The point here is that you _can_ deploy with configuration, much like you would for a forward proxy, for instance.
[00:38:14] <Watson Ladd_web_318> @Jari: why does discovery equal user configuration?
[00:38:38] <Keith Bare> @Jonathan Yeah, that's kind of neat.
[00:38:42] <Andrew Campling_web_920> The charter is missing milestones including documenting the use case limitations, documenting the operational and security considerations etc.  
[00:38:44] <Benjamin Schwartz_web_292> Hoyland: Not if there's padding.
[00:38:52] Chris Wendt_web_834 leaves the room
[00:38:58] Chris Wendt_web_884 joins the room
[00:39:02] Chris Wendt_web_884 leaves the room
[00:39:04] <Vittorio Bertola_web_262> @ekr: I guess Jari's point is that if the purpose is to prevent Google from knowing where my telemetry comes from, then I might want to use a proxy I trust rather than one Google trusts.
[00:39:04] Chris Wendt_web_377 joins the room
[00:39:05] Ralf Weber_web_975 leaves the room
[00:39:16] <Watson Ladd_web_318> and how does discovery matter for that?
[00:39:22] <Jonathan Hoyland_web_493> @BenSchwartz, yeah the analysis is a symbolic one, so no padding consideration.
[00:39:25] <Jana Iyengar_web_431> @Vittorio, that's a configuration matter
[00:39:29] <Watson Ladd_web_318> one of the issues is the first proxy cant be in the same AS
[00:39:33] <Mark Nottingham_web_885> Vitttorio: That's not discovery, that's configuration
[00:39:37] <Watson Ladd_web_318> otherwise too much data goes to the second proxy
[00:39:37] Jason Weil_web_619 leaves the room
[00:39:42] Jason Weil_web_169 joins the room
[00:39:42] <Daniel Migault_web_727> @ekr, telemetry is encrypted after all.
[00:40:00] <ekr@jabber.org> @Daniel: it's encrypted *to* Google (also to Mozilla, of course)
[00:40:01] <Benjamin Schwartz_web_292> It's discovery if you have a MASQUE proxy and you want to know if there's an associated OHTTP proxy, which could be useful.
[00:40:19] <kaduk@jabber.org/barnowl> Vittorio: it's not either/or.  Google has to trust it regardless.  You
might want to *also* trust it, but if google doesn't trust it, it gets
rate-limited/banned
[00:40:20] <Vittorio Bertola_web_262> I cannot configure a different proxy if I don't know how to find one and if the process is not sufficiently automated that it is easy for me to do so.
[00:40:25] <Robert Moskowitz> 3
[00:40:27] <Daniel Migault_web_727> @ekr I hope so.
[00:40:37] <Joseph Salowey_web_495> Is it "oh, HTTP" or "Oh! HTTP"?
[00:40:50] <Mark Nottingham_web_885> Oh, *shakes head* HTTP.
[00:40:50] <Jana Iyengar_web_431> @Vittorio, that is a product problem, not a protocol problem
[00:41:01] <dkg> Salowey, i pronounce it "eh, http"
[00:41:02] <Daniel Migault_web_727> could youplease state all questions ?
[00:41:04] <Martin Thomson_web_799> not enough time to respond
[00:41:06] <Mike Bishop_web_188> Poll closed too quickly.
[00:41:10] <Carrick_web_582> That was the fastest poll
[00:41:14] <dkg> it's unanimous!
[00:41:18] <Wes Hardaker_web_757> 0HTTP
[00:41:27] <dkg> ha ha
[00:41:29] <Watson Ladd_web_318> happened again
[00:41:31] <Eric Orth_web_393> I like the result.  Keep it!
[00:41:33] <Alissa Cooper_web_751> amazeballs
[00:41:34] <Patrick Tarpey_web_364> really quick
[00:41:36] <Jonathan Hoyland_web_493> The score doubled.
[00:41:36] <Mike Bishop_web_188> Take three.
[00:41:38] <Martin Thomson_web_799> vote now
[00:41:39] <Thomas Mangin_web_778> @vittorio, I can see how discovery without auto-setup would indeed be a good feature. It was always how I thought of it but perhaps for others had auto-setup in mind
[00:41:43] <Mark Nottingham_web_885> Baaarnes!
[00:41:43] <Tommy Jensen_web_978> 24 or bust this time
[00:42:00] <Mike Bishop_web_188> People racing to vote this time.  :-)
[00:42:01] <Lucas Pardue_web_689> take the median of 3 samples
[00:42:12] <ekr@jabber.org> This is actually a great example of where a proxy would be helpful!
[00:42:13] <dkg> i'd like to hear from someone who "did not raise hand"
[00:42:17] <Jana Iyengar_web_431> hey, we just voted
[00:42:20] <nygren> But Google might also care heavily about anti-abuse mitigations for telemetry and using a proxy they specify may give them controls to get data but with some ability to reduce abuse.  Turning off telemetry is probably better if you don't trust google.  The client can always collude with the server and then it's all pointless.
[00:42:22] <ekr@jabber.org> So you could have anonymous voting without trusting Meetecho
[00:42:29] <Pete Resnick_web_490> I'm surprised we have over 10% of people saying "not good idea or need more info".
[00:42:31] <Christopher Patton_web_151> +dkg
[00:42:38] <Glenn Deen_web_392> I don't see how to take the poll
[00:42:45] <Ian Swett_web_548> I want other people to work on it, does that count as raising my hand....
[00:42:52] <Mike Bishop_web_188> Over 20%, in fact.
[00:42:54] <Jana Iyengar_web_431> @Ian yes
[00:42:56] <ekr@jabber.org> Ian, it does
[00:42:59] <Mark Nottingham_web_885> We can take from this that people who support this are faster to click.
[00:42:59] <nygren> Go to the little graph thing in the middle of the top bar.
[00:43:00] <Sean Turner_web_433> @GlennDeen top row thing that looks like a chart
[00:43:03] <Sean Turner_web_433> 5th button over
[00:43:04] <Ian Swett_web_548> JK, but thanks
[00:43:10] <David Schinazi_web_243> @Ian it's "the IETF should work on it" not "I should work on it"
[00:43:12] <Carrick_web_582> Mark +1
[00:43:16] <Pete Resnick_web_490> 10% of everyone in the room, but yeah.
[00:43:16] <David Schinazi_web_243> :P
[00:43:26] Samuel Weiler_web_612 leaves the room
[00:43:34] Samuel Weiler_web_187 joins the room
[00:43:39] Kazunori Fujiwara_web_489 leaves the room
[00:43:42] <Martin Thomson_web_799> The question I have is: is the charter unfixable?
[00:43:50] <Toerless Eckert_web_889> mass inertia...
[00:43:56] <Toerless Eckert_web_889> ask for the negative ?
[00:44:10] Patrick Tarpey_web_364 leaves the room
[00:44:12] Samuel Weiler_web_187 leaves the room
[00:44:14] <Pete Resnick_web_490> Evidently they are all shy.
[00:44:15] <Thomas Mangin_web_778> yes, I want to be ever seen as bad guy syndrome
[00:44:15] <Christopher Inacio_web_438> Maybe there not here
[00:44:22] <Spencer Dawkins_web_809> Also fair to ask "there's no problem" versus "i need more information"
[00:44:24] <David Schinazi_web_243> Maybe these 21 people misclicked?
[00:44:27] Glenn Deen_web_392 leaves the room
[00:44:30] <Jonathan Rosenberg_web_139> I hit "not raise hand" because if I were in a live meeting, I wouldnt have raised my hand. Not the same as "i object to this group"
[00:44:31] <Wes Hardaker_web_757> probably a don't want to fight the fight problem
[00:44:31] <Christopher Inacio_web_438> because you didn’t have an opposing question
[00:44:36] Kazunori Fujiwara_web_683 joins the room
[00:45:00] <Carrick_web_582> @Jonathan: yeah, I think this isn't as good as the hum question.
[00:45:01] <dkg> Jonathan Rosenberg_web_139: the corresponding action would have been to do nothing
[00:45:06] <Spencer Dawkins_web_809> What Jonathan Rosenberg said
[00:45:16] Qiaoyu Deng_web_431 leaves the room
[00:45:16] <dkg> clicking "do not raise hand" means "hum against"
[00:45:23] <Jonathan Rosenberg_web_139> In person you have a binary choice. Here its a tertiary choice.
[00:45:26] <Pete Resnick_web_490> This is why hums are better: Eliot would have hummed quietly.
[00:45:29] <Jana Iyengar_web_431> I imagine the opposing question would be the opposite -- as in, there's nothing here for the IETF to do
[00:45:29] Glenn Deen_web_674 joins the room
[00:45:46] <Carrick_web_582> +1 Jana
[00:45:46] <dkg> Jana: yes, that's how these polls should be written
[00:45:47] <Jonathan Rosenberg_web_139> I agree we should ask the opposite question.
[00:45:57] <Benjamin Schwartz_web_292> I don't think there is an opposite question
[00:45:58] <Toerless Eckert_web_889> Jana: isn't that what i said before ?
[00:45:59] Benedict Wong_web_167 joins the room
[00:45:59] <Martin Thomson_web_799> Read the chat Richard Barnes
[00:46:04] Kazunori Fujiwara_web_683 leaves the room
[00:46:10] <Mark Nottingham_web_885> The oldest IETF sport -- debating the form of the question
[00:46:15] <Eliot Lear_web_684> I might have hummed in both directions ;-)
[00:46:20] <Martin Thomson_web_799> The opposite question is "who opposes work on this topic"
[00:46:23] <Jonathan Rosenberg_web_139> "who thinks this is not something the ietf should work on"
[00:46:24] <dkg> Eliot Lear_web_684: take it up with meetecho :P
[00:46:30] <Toerless Eckert_web_889> Martin: right
[00:46:32] <kaduk@jabber.org/barnowl> Mark: ah, yes, having a hum on whether the hum phrasing is useful came
later.
[00:46:40] <Jana Iyengar_web_431> I like Martin's and Jonathan's opposing questions
[00:46:47] Trent Adams_web_120 leaves the room
[00:46:53] Kazunori Fujiwara_web_455 joins the room
[00:46:55] <Eliot Lear_web_684> @dkg it's approaching 3am.  I've got a date with my pillow.
[00:46:57] chenmeiling_web_615 joins the room
[00:47:00] <Mark Nottingham_web_885> meetecho should have a template for the common form - support / oppose / don't know
[00:47:31] <Pete Resnick_web_490> @mnot: +1
[00:47:32] <Jana Iyengar_web_431> I like that
[00:47:41] <Éric Vyncke_web_273> On my side (cannot speak at 3 AM Local time w/o waking up the family) but I need to see an improved charter on the 'domain limit', accent on server needs to be modified, + Ted Hardie's context + clarification in the charter (if possible) about the trust among partners (Ekr replied to many of those points)
[00:47:53] <Martin Thomson_web_799> meetecho should have options that the chairs can fill out
[00:48:00] <Éric Vyncke_web_273> And BTW the BoF was interesting
[00:48:02] <Mark Nottingham_web_885> yup.
[00:48:04] <Jana Iyengar_web_431> Right. I thought they did. Clearly not.
[00:48:04] Al Morton_web_139 leaves the room
[00:48:05] <Tommy Jensen_web_978> +1, that, discovery isn't just not needed, it's actually a step backward
[00:48:11] <Vittorio Bertola_web_262> I'm sure Meetecho was given very detailed instructions to make this form exactly like it is. I just don't know what's the IETF process to determine or revise those instructions.
[00:48:23] <dkg> mnot: shouldn't we also offer more standard options like "i have not read the drafts" and "i'm using this session to nap in"
[00:48:27] <Martin Thomson_web_799> Yes, the IESG is ultimately to blame for the shortcomings of this tool
[00:48:27] <Jonathan Hoyland_web_493> @Éric if you want me to relay something to the mic you can precede it with "mic:"
[00:48:31] <Mark Nottingham_web_885> +1 dkg
[00:48:38] <Watson Ladd_web_318> +1 dkg
[00:48:38] <Toerless Eckert_web_889> a descriptive document could perfectly document why for the intended scearios discovery is undesirable..
[00:48:39] Phillip Hallam-Baker_web_159 leaves the room
[00:48:51] <Daniel Migault_web_727> good discussion thanks!
[00:48:52] <Tommy Jensen_web_978> @dkg: is the default response "hand raised" for the sleeping question? Otherwise I predict a problem.
[00:48:53] Rui Paulo_web_182 leaves the room
[00:49:00] <Éric Vyncke_web_273> Please read lound what I wrote above
[00:49:03] <Mark Nottingham_web_885> maybe a modal dialogue first: "have you read the drafts?" Because we know they work...
[00:49:10] <kaduk@jabber.org/barnowl> This is reading quietly, not reading loudly
[00:49:22] David Oliver_web_744 leaves the room
[00:49:43] Joerg Ott_web_466 leaves the room
[00:49:48] Michael Rosa_web_397 leaves the room
[00:49:49] Benedict Wong_web_167 leaves the room
[00:49:49] Nick Banks_web_370 leaves the room
[00:50:00] Justin Richer_web_168 leaves the room
[00:50:02] <Eliot Lear_web_684> Richard and Alexey: :clap::clap::clap::clap::clap::clap:
[00:50:19] Mo Zanaty_web_450 leaves the room
[00:50:19] Shivan Sahib_web_272 leaves the room
[00:50:22] Xavier de Foy_web_392 leaves the room
[00:50:25] Glenn Deen_web_674 leaves the room
[00:50:28] Greg Schumacher_web_244 leaves the room
[00:50:30] Dan Wing_web_756 leaves the room
[00:50:30] Geoff Huston_web_867 leaves the room
[00:50:34] Ian Swett_web_548 leaves the room
[00:50:38] Valery Smyslov_web_879 leaves the room
[00:50:38] <Thomas Mangin_web_778> :ocean:
[00:50:38] Jon Peterson_web_154 leaves the room
[00:50:38] Mark McFadden_web_702 leaves the room
[00:50:38] Bryan Call_web_225 leaves the room
[00:50:39] Toerless Eckert_web_889 leaves the room
[00:50:39] Eric Rescorla_web_191 leaves the room
[00:50:40] Thomas Fossati_web_184 leaves the room
[00:50:40] Carrick_web_582 leaves the room
[00:50:40] Russ Housley_web_629 leaves the room
[00:50:41] Ted Hardie_web_425 leaves the room
[00:50:41] Dominique Lazanski_web_199 leaves the room
[00:50:42] Stephen Farrell_web_404 leaves the room
[00:50:42] Eric Orth_web_393 leaves the room
[00:50:42] Alan Frindell_web_901 leaves the room
[00:50:42] Spencer Dawkins_web_809 leaves the room
[00:50:42] Tim Cappalli_web_302 leaves the room
[00:50:42] Eliot Lear_web_684 leaves the room
[00:50:42] Philipp Tiesel_web_607 leaves the room
[00:50:42] Chi-Jiun Su_web_545 leaves the room
[00:50:43] Lucy Lynch_web_628 leaves the room
[00:50:43] Marco Tiloca_web_440 leaves the room
[00:50:43] Francisco Arias_web_828 leaves the room
[00:50:43] Christopher Patton_web_151 leaves the room
[00:50:43] Roman Danyliw_web_556 leaves the room
[00:50:44] Dhruv Dhody_web_869 leaves the room
[00:50:44] Shumon Huque_web_723 leaves the room
[00:50:44] Pete Resnick_web_490 leaves the room
[00:50:44] Mirja Kühlewind_web_871 leaves the room
[00:50:44] Sean Turner_web_433 leaves the room
[00:50:45] Marie-Hélène Bouchard_web_427 leaves the room
[00:50:45] Toerless Eckert_web_925 joins the room
[00:50:45] Francesca Palombini_web_174 leaves the room
[00:50:45] Jonathan Rosenberg_web_139 leaves the room
[00:50:45] Dragana Damjanovic_web_122 leaves the room
[00:50:45] Joey Salazar_web_492 leaves the room
[00:50:46] Jason Weil_web_169 leaves the room
[00:50:46] Richard Barnes_web_481 leaves the room
[00:50:46] Eckard Bogenfeld_web_858 leaves the room
[00:50:46] Jonathan Hammell_web_682 leaves the room
[00:50:47] Wes Hardaker_web_757 leaves the room
[00:50:47] Joseph Salowey_web_495 leaves the room
[00:50:47] Christopher Wood_web_401 leaves the room
[00:50:47] Ken Takayama_web_658 leaves the room
[00:50:47] Vittorio Bertola_web_262 leaves the room
[00:50:47] Patrick Kelsey_web_258 leaves the room
[00:50:48] Erik Kline_web_793 leaves the room
[00:50:48] Frode Kileng_web_500 leaves the room
[00:50:48] Jorge Cano_web_239 leaves the room
[00:50:48] Florence D_web_174 leaves the room
[00:50:49] Robert Story_web_936 leaves the room
[00:50:49] Jay Daley_web_610 leaves the room
[00:50:50] Barry Leiba_web_222 leaves the room
[00:50:50] <Zaheduzzaman Sarker_web_225> thanks to the chairs
[00:50:50] Tara Whalen_web_749 leaves the room
[00:50:50] Benjamin Kaduk_web_587 leaves the room
[00:50:50] Andrew Campling_web_920 leaves the room
[00:50:51] Éric Vyncke_web_273 leaves the room
[00:50:51] Benjamin Schwartz_web_292 leaves the room
[00:50:51] SeongHan Shin_web_683 leaves the room
[00:50:51] Jari Arkko_web_522 leaves the room
[00:50:51] Mark Nottingham_web_885 leaves the room
[00:50:52] Watson Ladd_web_318 leaves the room
[00:50:52] Peter Campbell_web_768 leaves the room
[00:50:52] Keith Bare_web_267 leaves the room
[00:50:52] Julien Maisonneuve_web_943 leaves the room
[00:50:52] Dan Druta_web_844 leaves the room
[00:50:52] Chris Box_web_555 leaves the room
[00:50:53] Jiao Kang_web_536 leaves the room
[00:50:53] Sanjay Mishra_web_283 leaves the room
[00:50:54] <francesca> Thank you to the minute takers! :D
[00:50:54] Andrew S_web_607 leaves the room
[00:50:54] Matthew Finkel_web_244 leaves the room
[00:50:54] Chris Wendt_web_377 leaves the room
[00:50:55] Jana Iyengar_web_431 leaves the room
[00:50:55] Jason Livingood_web_872 leaves the room
[00:50:56] Christopher Inacio_web_438 leaves the room
[00:50:57] Frode Sorensen_web_701 leaves the room
[00:50:57] Kazunori Fujiwara_web_455 leaves the room
[00:50:58] Alissa Cooper_web_751 leaves the room
[00:50:58] Chris Lemmons_web_804 leaves the room
[00:50:59] Zaheduzzaman Sarker_web_225 leaves the room
[00:51:00] John Border_web_950 leaves the room
[00:51:01] Robert Story_web_397 joins the room
[00:51:01] Yan Yan_web_139 leaves the room
[00:51:01] Justin Iurman_web_448 leaves the room
[00:51:02] Matthew Quick_web_564 leaves the room
[00:51:03] Martin Thomson_web_799 leaves the room
[00:51:03] Thomas Mangin_web_778 leaves the room
[00:51:04] Karen O'Donoghue_web_939 leaves the room
[00:51:04] <cabo> Meetecho: good night
[00:51:06] Hamid Azizullah_web_354 leaves the room
[00:51:06] Alessandro Toppi_web_758 leaves the room
[00:51:07] Lucas Pardue_web_689 leaves the room
[00:51:08] Greg Wood_web_810 leaves the room
[00:51:12] ekr@jabber.org leaves the room
[00:51:13] Jiri Novotny_web_453 leaves the room
[00:51:14] Kazuaki Ueda_web_889 leaves the room
[00:51:14] Tero Kivinen_web_719 leaves the room
[00:51:23] Wei Pan_web_715 leaves the room
[00:51:24] Keith Bare leaves the room
[00:51:25] tim costello_web_123 leaves the room
[00:51:25] Alexey Melnikov_web_872 leaves the room
[00:51:27] Marcus Ihlar_web_657 leaves the room
[00:51:28] <Meetecho> Good night!
[00:51:33] <Taiji Kimura_web_680> Tommy and Sean: Thank you!
[00:51:37] Magnus Westerlund_web_834 leaves the room
[00:51:39] Mike Bishop_web_188 leaves the room
[00:51:39] Robert Story_web_397 leaves the room
[00:51:39] Jonathan Lennox_web_149 leaves the room
[00:51:40] Brendan Moran_web_255 leaves the room
[00:51:40] Taiji Kimura_web_680 leaves the room
[00:51:45] Rikard Höglund_web_162 leaves the room
[00:51:48] Cullen Jennings_web_205 leaves the room
[00:51:52] Tadahiko Ito_web_977 leaves the room
[00:51:53] Toerless Eckert_web_925 leaves the room
[00:51:56] Meetecho leaves the room
[00:51:57] Qin Wu_web_617 leaves the room
[00:52:01] nygren leaves the room
[00:52:04] Carsten Bormann_web_306 leaves the room
[00:52:05] Markus Amend_web_552 leaves the room
[00:52:10] Eric Kinnear_web_378 leaves the room
[00:52:11] Robert Wilton_web_110 leaves the room
[00:52:13] Daniel Gillmor_web_912 leaves the room
[00:52:13] Alessandro Amirante_web_322 leaves the room
[00:52:13] Colin Whorlow_web_957 leaves the room
[00:52:13] Hannes Tschofenig_web_140 leaves the room
[00:52:13] Robert Moskowitz_web_565 leaves the room
[00:52:13] Kohei Isobe_web_492 leaves the room
[00:52:13] Tommy Pauly_web_864 leaves the room
[00:52:13] Suhas Nandakumar_web_636 leaves the room
[00:52:13] Harald Alvestrand_web_212 leaves the room
[00:52:13] Lars Eggert_web_589 leaves the room
[00:52:13] Shigeya Suzuki_web_903 leaves the room
[00:52:13] David Schinazi_web_243 leaves the room
[00:52:13] Jonathan Hoyland_web_493 leaves the room
[00:52:13] Takahiro Nemoto_web_410 leaves the room
[00:52:13] Hiroyuki Goto_web_246 leaves the room
[00:52:13] Daniel Migault_web_727 leaves the room
[00:52:13] Francois Ortolan_web_796 leaves the room
[00:52:13] Kazuho Oku_web_387 leaves the room
[00:52:13] Armando Faz-Hernández_web_834 leaves the room
[00:52:13] Satoru Kanno_web_482 leaves the room
[00:52:13] James Galvin_web_286 leaves the room
[00:52:13] Erik Nygren_web_563 leaves the room
[00:52:13] Korry Luke_web_250 leaves the room
[00:52:13] Nathalie Moreno_web_286 leaves the room
[00:52:13] John Preuß Mattsson_web_988 leaves the room
[00:52:13] chenmeiling_web_615 leaves the room
[00:52:13] Tommy Jensen_web_978 leaves the room
[00:52:13] Stefan Santesson_web_171 leaves the room
[00:52:13] Rebecca Guthrie_web_636 leaves the room
[00:52:13] Diego Lopez_web_887 leaves the room
[00:52:13] Stephen McQuistin_web_981 leaves the room
[00:53:01] spencerdawkins leaves the room
[00:53:04] whalen@jabber.org leaves the room
[00:56:26] whalen@jabber.org joins the room
[00:58:17] frodek leaves the room
[01:03:04] kaduk@jabber.org/barnowl leaves the room
[01:04:52] francesca leaves the room
[01:06:44] Robert Moskowitz leaves the room
[01:26:35] dkg leaves the room
[02:13:02] whalen@jabber.org joins the room
[02:13:05] whalen@jabber.org leaves the room
[02:34:46] whalen@jabber.org joins the room
[02:35:05] whalen@jabber.org leaves the room
[02:53:06] whalen@jabber.org leaves the room
[02:54:23] whalen@jabber.org joins the room
[02:57:36] whalen@jabber.org leaves the room
[07:56:23] Chris Inacio leaves the room: Disconnected: Replaced by new connection
[07:56:27] Chris Inacio joins the room
[11:54:02] whalen@jabber.org joins the room
[12:38:47] whalen@jabber.org leaves the room
[12:41:10] whalen@jabber.org joins the room
[13:54:48] whalen@jabber.org leaves the room
[14:10:20] whalen@jabber.org joins the room
[14:21:56] Chris Inacio leaves the room: Disconnected: Replaced by new connection
[14:22:00] Chris Inacio joins the room
[14:24:18] whalen@jabber.org leaves the room
[14:24:23] whalen@jabber.org joins the room
[14:55:26] Chris Inacio leaves the room
[22:17:05] whalen@jabber.org leaves the room
[22:17:41] whalen@jabber.org joins the room
[22:31:35] whalen@jabber.org leaves the room
[22:54:15] whalen@jabber.org joins the room
[23:29:05] whalen@jabber.org leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!