IETF
dnsop
dnsop@jabber.ietf.org
Thursday, July 20, 2017< ^ >
each has set the subject to: IETF 99 DNSOP
Room Configuration
Room Occupants

GMT+0
[05:58:36] joel jaeggli leaves the room
[06:08:10] Peter van Dijk joins the room
[06:22:28] Peter van Dijk leaves the room
[06:58:07] joel jaeggli joins the room
[07:05:26] joel jaeggli leaves the room
[07:30:51] serenheit joins the room
[07:48:09] serenheit leaves the room
[08:05:05] tale joins the room
[10:05:19] tale leaves the room
[10:14:45] tale joins the room
[12:26:24] tale leaves the room
[13:33:47] tale joins the room
[14:23:08] Peter van Dijk joins the room
[14:29:35] Peter van Dijk leaves the room
[14:29:39] Peter van Dijk joins the room
[15:14:51] tale leaves the room
[15:52:52] Peter van Dijk leaves the room
[15:54:00] Dan York joins the room
[15:54:56] Meetecho joins the room
[16:01:16] ray joins the room
[16:02:01] TedLemon joins the room
[16:02:01] TedLemon leaves the room
[16:02:01] TedLemon joins the room
[16:02:57] paulwouters joins the room
[16:04:55] Peter van Dijk joins the room
[16:05:12] Ray Bellis joins the room
[16:05:12] Akira Kato joins the room
[16:05:12] Juan Cerezo joins the room
[16:05:12] Edward Lewis joins the room
[16:05:12] Marco Pizzoli joins the room
[16:05:12] Peter DeVries joins the room
[16:05:13] John Border joins the room
[16:05:31] John Klensin joins the room
[16:05:47] Cathy Aronson joins the room
[16:06:00] Jan Komissar joins the room
[16:06:13] Klensin joins the room
[16:09:32] Yoshiro Yoneya joins the room
[16:11:26] Wouter Wijngaards joins the room
[16:12:05] <Dan York> DNSOP day 2 - I'm available to scribe if people need it
[16:12:17] <Dan York> Anyone remote
[16:12:22] <ray> yes, I am
[16:12:31] <ray> I have the video feed too
[16:12:50] <Peter van Dijk> hi ray :)
[16:12:56] Lars Wegmann joins the room
[16:12:57] <Peter van Dijk> i found out -just now- you also presented xpf on ietf98
[16:12:57] <ray> Hey Peter
[16:13:05] <ray> I did?  I forget… :p
[16:13:08] <Peter van Dijk> haha
[16:13:11] <Peter van Dijk> it was quite brief
[16:13:13] <Peter van Dijk> one slide really
[16:13:16] Weiler joins the room
[16:13:19] Suzanne joins the room
[16:13:47] Kal Feher joins the room
[16:14:43] Andrew Sullivan joins the room
[16:14:43] Matthijs Mekking joins the room
[16:16:10] koji joins the room
[16:17:32] <Dan York> Warren standing up talking about pictures of IPv6 usage
[16:18:05] C. joins the room
[16:18:10] Okke Timm joins the room
[16:18:11] <Suzanne> and about an open errata,we'll follow up to the list to remind people which RFC was involved and what the concern was
[16:18:19] <Dan York> Talking about https://www.ietf.org/proceedings/99/slides/slides-99-dnsop-sessb-multiple-responses-multi-qtypes-00.pdf
[16:18:24] <Dan York> Wes now up there
[16:18:30] <Dan York> Wes Hardaker
[16:20:01] Vicky joins the room
[16:23:35] Miles McCredie joins the room
[16:23:58] <Vicky> Since BIND 9.11.0, we will return the TLSA record if we have one, when answering a query for MX
[16:24:27] <Dan York> Mic line forming
[16:24:31] <Dan York> Paul Hoffman at mic
[16:24:39] <ray> Tale has started an implementation of multi-qtypes
[16:24:39] <Dan York> Shane Kerr at mic
[16:24:54] <Dan York> Ralf Web at mic
[16:25:07] <Dan York> Any remote folks want to comment?
[16:25:23] <Peter van Dijk> (Tale is in the line as well)
[16:25:25] Dawn Hardaker joins the room
[16:25:27] <Suzanne> trying to keep comments short
[16:25:41] muks joins the room
[16:25:43] <Suzanne> but hate to tell people not to have interest/opinions :)
[16:25:46] <muks> hi
[16:25:50] <Dan York> Suzanne... good luck with that!
[16:25:54] <muks> i prefer smart clients to smart servers
[16:26:03] <Dan York> Dave Lawrence at mic - he wrote some code
[16:26:07] <muks> EDNS client subnet only works on stuff in the answer section btw
[16:26:09] <Dan York> Ondrej Sury at mic
[16:26:10] mklock joins the room
[16:26:29] Andrew Sullivan leaves the room
[16:26:29] tale joins the room
[16:26:49] <muks> smart servers can have a performance impact (additional internal datastructure queries have a big impact on performance)
[16:27:18] <muks> it's better if the client requests what it wants and the server provides that, than guessing what the client may need that the client may end up throwing away
[16:27:22] <Dan York> Olafur Gudmundsson at mic
[16:27:41] <ray> object to Olafur’s comment - we had this discussion in Berlin
[16:27:48] <Dan York> @muks - is that a comment for the mic or is this side conversation?
[16:27:55] <muks> you can say it at the mic
[16:27:58] <Dan York> Andrew Sullivan at mic
[16:28:02] <muks> i'm Mukund Sivaraman (ISC)
[16:28:07] <Dan York> Okay - will do
[16:28:30] <Dan York> If anyone wants anything proxied to the mic, please preface it with "MIC:" so I know
[16:28:42] <Dan York> Paul Wouters at mic
[16:28:46] <Ray Bellis> please ask Andrew to send email to list explaining his comment
[16:29:23] <Dan York> Kazunori at mic
[16:29:30] Andrew Sullivan joins the room
[16:30:06] John Levine joins the room
[16:30:15] dkg joins the room
[16:30:20] Big bad wolf joins the room
[16:30:25] Benno Overeinder joins the room
[16:30:42] <Andrew Sullivan> Well, it's not the first time I made this observation (I made it in DNSEXT when that WG still existed, for instance)
[16:30:49] <Andrew Sullivan> but I'll do another go at it, sure
[16:31:04] <Dan York> Jim Reed at mic
[16:31:08] <Ray Bellis> Andrew - thanks
[16:31:10] <Suzanne> @ajs I  think you made it at least once in this very room
[16:31:11] <muks> thank you dan
[16:31:24] <paulwouters> muks: its hard for the client to ask both A record and a TLSA record prefixed elsewhere
[16:31:39] <Big bad wolf> Ray:  Berlin discussion did not say what was in scope for "optimization"
[16:31:40] <Dan York> Matt Pounsett at mic
[16:32:17] <Andrew Sullivan> @Suzanne: probably.  I'm deeply worried that we're making changes that look like they're optimizations but that are changing the fundamental assumptions
[16:32:44] <Suzanne> You must love session-signal then
[16:32:46] <Dan York> Now Peter van Dijk speaking about https://www.ietf.org/proceedings/99/slides/slides-99-dnsop-sessb-draft-bellis-dnsop-xpf-01.pdf
[16:32:52] <Ray Bellis> I'd like to understand what assumptions you think my draft is changing
[16:32:58] <Dan York> Draft has changed substantially. Go read it.
[16:33:30] <Andrew Sullivan> Maybe those fundamental assumptions need to change.  But it'd be pretty strange to get DNSbis by accident, and I fear we're headed that way.  And session-signal has some of these properties too and it's even in keeping with something I also want to do
[16:33:45] Dawn Hardaker leaves the room
[16:33:58] <Ray Bellis> session signaling definitely is a big step - not sure this applies to multi-qtypes, though
[16:34:08] <Andrew Sullivan> but this is all fodder for the list.  Or maybe addition to draft-klensin-dns-function-considerations-03
[16:36:00] Benno Overeinder leaves the room
[16:36:47] Peter van Dijk leaves the room
[16:37:18] <Ray Bellis> I don't remember where "X-Proxied-For" came from, but I prefer it over "X-Forwarded-For"
[16:37:33] <Dan York> Ondrej Sury at mic
[16:38:05] <Ray Bellis> it's also harder to add an OPT RR where none previously existed
[16:38:15] <Dan York> Sara Dickinson at mic
[16:38:22] Benno Overeinder joins the room
[16:38:46] <Ray Bellis> I added text to address Sara's privacy concerns in the -02
[16:38:59] <Suzanne> how's the remote sound? Chairs were warned the front mic can sound muddy/muffled
[16:39:05] <Ray Bellis> sounds fine to me
[16:39:24] <Andrew Sullivan> It sounds muddy in the room, though :)
[16:39:51] <Suzanne> that I can't fix
[16:40:25] <Ray Bellis> Sara's concerns feel *massively* overblown to me
[16:40:32] <Dan York> dkg at mic
[16:40:41] <Dan York> warren kumari at mic
[16:41:04] <Andrew Sullivan> @Ray: I think I disagree.  The DNS is a major leaker of perpass info
[16:41:14] Peter van Dijk joins the room
[16:41:29] Benno Overeinder leaves the room
[16:41:47] <Ray Bellis> I've tried to be very clear in the draft that it's for use within a single adminstrative domain, where all of the information being sent up stream is *already* available
[16:42:02] <muks> paulwouters: if a client wants TLSA, can some EDNS option field be used to request it (corresponding to the A) ? e.g., most current clients will not use a TLSA
[16:42:11] <Big bad wolf> Old proposal: https://tools.ietf.org/html/draft-ietf-dnsind-dns-error-00
[16:42:15] <Andrew Sullivan> Yes, but the DNS is _famously_ bad at containing data in the way the draft says
[16:42:22] <Dan York> David Lawrence (tale) now presenting https://www.ietf.org/proceedings/99/slides/slides-99-dnsop-sessb-draft-tale-dnsop-edns0-clientid-00.pdf
[16:42:29] <Andrew Sullivan> but I want to think about it more, which is why I have been silent
[16:42:32] <Ray Bellis> and this is simply a *technical measure* to permit the server to continue to use existing mechanisms that rely on transport level information when a proxy / load-balancer sits in front of a server
[16:42:44] <Andrew Sullivan> but I don't think it's fair to call her concerns "massively" overblown
[16:44:05] <Peter van Dijk> @Dan that's not the deck he is presenting
[16:44:18] <Peter van Dijk> @Dan that one is next
[16:44:37] <Andrew Sullivan> I have been trying to figure out how to put NODATA/NOERROR (in a completely unambiguous way for a change) into this idea
[16:44:53] <Andrew Sullivan> but I can't decide whether this is brilliant or a horrible bag on the side
[16:45:19] <Andrew Sullivan> (maybe what I really need to do is to write draft-sullivan-dnsop-bag-on-side-00)
[16:45:36] <Vicky> David Lawrence presenting https://www.ietf.org/proceedings/99/slides/slides-99-dnsop-sessb-draft-wkumari-dnsop-extended-error-00.pdf
[16:46:02] <Dan York> Paul wouters at mic
[16:46:34] <Dan York> @Vicky / @Peter - thanks for pointing out the error.  Thanks!
[16:46:41] pallavi aras joins the room
[16:46:50] <Suzanne> @dan I just realized the agenda needed an update it didn't get….sorry about that….Tale is presenting extended-error, which has Warren's name on it in the agenda
[16:47:41] <dkg> Ray Bellis: the xpf proposal offers no mechanism to technically constrain the data to the administrative domain
[16:47:42] <Klensin> @Suz: sorry to be slow -- remote sound is great.  Remove video is a little fuzzy - out of focus or otherwise not sharp, but tolerable.
[16:47:52] <Dan York> @suzanne - Aha! That's why I didn't see it.
[16:47:59] <Dan York> @Olafur was at the mic
[16:48:07] <Dan York> Jim Reed was at the mic
[16:48:09] <dkg> it basically says "thou shalt not" -- which i do appreciate
[16:48:36] <dkg> but it's not as effective as having some way to keep the data protected.
[16:48:43] <Dan York> Petr Spacek at mic
[16:48:53] Taiji Kimura joins the room
[16:49:19] Matthew Pounsett joins the room
[16:49:28] <Yoshiro Yoneya> Mic volume is so small that I can't hear comments clearly even in the room.
[16:49:33] <Dan York> Jan Vladek at mic
[16:49:38] <Dan York> Ralf Weber at mic
[16:50:13] <paulwouters> ENOSECURE
[16:50:30] <Dan York> Warren now speaking
[16:50:35] <dkg> it also doesn't seem to have any way for the client to opt out of having its address forwarded.  ecs at least has a means for the client to indicate that it doesn't want to get data constrained by its IP address (though it's entirely advisory)
[16:50:38] <ray> @dkg it would in theory only ever get deployed in the internal side of specific applications / appliances.   We mustn’t over complicate the protocol just because it “might” get abused.  Any protocol can be abused.
[16:50:48] Han Zhang joins the room
[16:50:59] <Peter van Dijk> the lack of opt out is intentional
[16:51:16] <Peter van Dijk> but when Tale is done telling you about clientid I'm sure xpf will be forgotten ;)
[16:51:17] <Dan York> David Lawrence (tale) now giving the slides I referenced before: https://www.ietf.org/proceedings/99/slides/slides-99-dnsop-sessb-draft-tale-dnsop-edns0-clientid-00.pdf
[16:51:20] <dkg> ray: i think we need to start looking at it the other way around: if you know that there's a "right place" to do it, we need to think about how to constrain it to the right place.
[16:51:30] <dkg> Peter van Dijk: :)
[16:51:31] Yoshiro Yoneya joins the room
[16:51:35] <paulwouters> +1
[16:51:45] Cathy Aronson leaves the room
[16:52:01] <Peter van Dijk> he is framing it better though ;)
[16:52:18] <paulwouters> Groundhog Day
[16:52:25] serenheit joins the room
[16:52:26] <ray> @dkg we cannot prevent any person from implementing and transporting any data between their own servers (c.f. the current talk)
[16:52:54] Benno Overeinder joins the room
[16:52:54] Benno Overeinder leaves the room
[16:52:54] Benno Overeinder joins the room
[16:52:55] <dkg> ray: i fully agree.  anyone who has any data can exfiltrate it and drm is an impossibility
[16:53:15] <ray> the thing that’s expected to constrain the data to the right place is that in 99.9%+ of cases it’ll be *physically* constrained to the LAN that sits between the load-balancer and the servers behind it
[16:53:33] Viktor Dukhovni joins the room
[16:53:56] <Andrew Sullivan> The expert review process has _always_ needed improvement and it is _always_ unsatisfying to someone
[16:54:13] <Peter van Dijk> @ajs that's two observations, not one, I presume
[16:54:16] <dkg> ray: that doesn't sound like a mitigation that we can enforce via the protocol.
[16:54:21] <Andrew Sullivan> yes, 2
[16:55:18] <Klensin> But, Andrew, this sounds like "inadequate instructions to IANA and revierers" which, while not uncommon, is something that can be fixed, even if the fix has to involve iterative learning.
[16:55:55] <ray> dkg: no, of course it isn’t.   Without full on encryption (with all the overhead) there’d be no way to do that
[16:56:01] <Andrew Sullivan> The problem is that the last time we had _strong_ instructions to the experts, they refused everything all the time on the grounds that the instructions said so
[16:56:32] <Andrew Sullivan> Ultimately, we have to give instructions that the DNS community can live with, and this community does not lack for people who want to tell everyone else what to do
[16:56:36] <ray> dkg: but ironically this feature is intended to *facilitate* end user encryption, for example by making it easier to deploy front-end TLS boxes (that unwrap the TLS, and deliver non-TLS to the server)
[16:56:47] <Dan York> Paul Wouters at mic
[16:57:08] <Suzanne> The initial take on those conversations is that IANA will work with us on an FAQ-type document that can be linked from the registry and will explain some of the procedural questions that are not obvious to the new or inexperienced participant in the process. We will also look further into whether there needs to be more guidance on expert review and what's the bext mechanism for doing it (update the relevant RFCs or provide refinement to the guidelines within the existing flexibility we have under the RFC).
[16:57:25] <Dan York> Sara Dickinson at mic
[16:57:54] <Andrew Sullivan> It is possible to write a document like this that officially recommends that it is a bad idea
[16:57:55] Andrew Hadenfeldt joins the room
[16:58:04] Benno Overeinder leaves the room
[16:58:05] <Andrew Sullivan> "here is what people are doing and it is a bad idea"
[16:58:18] <Matthew Pounsett> Yeah, that's a very good way to document current worst practice.
[16:58:23] <Andrew Sullivan> which is sort of the direction the draft goes, but maybe not strongly enough
[16:58:26] <Klensin> Understood.   And I've always considered it a flaw in the DE model that we have no template for "DEs do the clear cases, but marginal ones go somewhere else and there is an appeal mechanism about  'marginal'".  That wouldn't cover all cases either, but the problem you describe is not exactly unique to DNS-related registries.
[16:58:51] <Andrew Sullivan> No, it is not unique to the DNS at all :)
[16:59:15] Peter van Dijk leaves the room
[16:59:26] <Dan York> Peter van Dijk at mic
[16:59:31] <Dan York> Ralf Weber at mic
[16:59:40] <Dan York> Stephane Bortzmeyer at mic
[16:59:40] Peter van Dijk joins the room
[17:00:03] Benno Overeinder joins the room
[17:00:04] <TedLemon> It would actually be really nice if a draft were published that used an opaque token.
[17:00:07] <Andrew Sullivan> Sounds like Stephane didn't need to promise to review it since he already has :)
[17:00:19] <TedLemon> Right now there is no compliance process that forces that, and I think that's bad.
[17:00:29] <Matthew Pounsett> @ted: I don't think the RFC tools have a way to redact text
[17:00:48] <Dan York> Did anyone go to maprg earlier today? I understand there was some presentation about "DNS munging" that highlighted all the bad things people are doing out on the Internet. Anyone know what this was?
[17:01:05] <Andrew Sullivan> I had a conflict alas
[17:01:15] <TedLemon> My original intention for this was to put the control for this on the router so that device IDs would not filter up.
[17:01:27] <TedLemon> Of course, user classes are still somewhat user-identifying.
[17:01:32] <Dan York> dkg at mic
[17:01:41] tale leaves the room
[17:01:41] tale joins the room
[17:01:41] tale leaves the room
[17:01:48] <TedLemon> But what's done now is actually revealing device identifiers.
[17:02:13] <Dan York> Amused by "tale has left the room" when he is in fact standing in front of all of us
[17:02:33] Peter van Dijk leaves the room
[17:02:33] Brandon Williams joins the room
[17:02:59] Peter van Dijk joins the room
[17:03:45] <Dan York> Paul Wouters at mic
[17:04:22] Peter van Dijk leaves the room
[17:04:31] <Andrew Sullivan> Surely publishing something as an RFC that says, "Don't do this it's a terrible idea please make it stop" is a thing we ought to be able to do
[17:04:46] <TedLemon> No, that's endorsing it. :)
[17:04:58] <TedLemon> Praising it with faint damns.
[17:05:35] Peter van Dijk joins the room
[17:05:50] <Andrew Sullivan> If this WG is going to take on moving things on the standards track I think we need a DNSMAINT WG instead
[17:06:09] <Andrew Sullivan> because many of the non-standard standards track documents are nowhere near the level of quality they need to be
[17:06:14] <TedLemon> I should never have gone along with Olafur closing DNSEXT.   :(
[17:06:15] tale joins the room
[17:06:29] <Dan York> Shumon presenting https://www.ietf.org/proceedings/99/slides/slides-99-dnsop-sessb-dnssec-alg-nego-00.pdf
[17:06:31] <Andrew Sullivan> this effort was what brought DNSEXT back from sleep was all about
[17:06:32] <Klensin> The documents are _are_ effective are ones that are close to what Andrew suggests but that are light on  "this is evil" and strong on "if you choose to do that, the following bad things will happen to you and your users/ customers".  That is not "bad" in the protocol police sense, but bad effects.
[17:06:33] <ray> @Ted - I agree completely :(
[17:06:40] <Andrew Sullivan> and it was a massiev and complete failure
[17:06:46] <Andrew Sullivan> No, I strongly disagree
[17:07:02] <Andrew Sullivan> DNSEXT was doing absolutely nothing, and I was pushing far harder to close than Olafur was
[17:07:06] <TedLemon> The problem is, now DNSOP is DNSEXT.
[17:07:11] <Andrew Sullivan> We couldn't get anyone to review things
[17:07:24] <paulwouters> Andrew: I dont think the authors who want interoperable features wants RFC titles that say "don't do this thing"
[17:07:30] <TedLemon> Oh, that's right, you were the other chair.
[17:07:44] <Andrew Sullivan> no.  We shut down a WG that had a lot of get off my lawn, and people went away and worked out what actual ideas they wanted to work on
[17:07:45] <TedLemon> Or am I remembering the whole thing wrong?
[17:07:47] <Andrew Sullivan> that was success
[17:07:51] <Andrew Sullivan> nope, I was the other co-chair
[17:08:28] Yoshiro Yoneya leaves the room
[17:09:20] <paulwouters> TedLemon: before that change we have no DNSEXT whatsoever. I waited 2 years and a wg chair change before by non-op document could be discussed anywhere
[17:09:38] <muks> "After all DNSSEC fails open" => validation fails but as algorithm is not supported, the resolution passes?
[17:09:50] <Andrew Sullivan> @paul: the dnsext@ list is still open
[17:09:56] <Andrew Sullivan> nothing was preventing discussion at all
[17:10:10] <Matthew Pounsett> @muks: Yes
[17:10:21] <Andrew Sullivan> or nothing procedural
[17:10:28] C. leaves the room: offline
[17:10:29] <tale > looking forward to draft-sullivan-dnsop-bag-on-side-00
[17:10:52] <Andrew Sullivan> not discussing substance is what was preventing that work from getting done.
[17:10:55] <Suzanne> @Ted no we're not, not every document we discuss will get further work here. We wrote "not protocol" into the charter to protect us all against exactly that temptation. If it needs the work that badly, DNSMAINT is not a bad idea.
[17:10:56] <Peter van Dijk> @tale before I forget, I don't get why indeterminate is an error condition in your extended error draft
[17:11:00] mklock leaves the room
[17:11:03] <Peter van Dijk> @tale because it is not an error condition in rfc403x
[17:11:10] <TedLemon> Yeeah, but...
[17:11:33] <paulwouters> isnt indeterminate a ServFail ?
[17:11:39] <Peter van Dijk> it's not
[17:11:41] <Peter van Dijk> it's identical to insecure
[17:11:48] <Peter van Dijk> in the current protocol
[17:12:03] <paulwouters> if i withhold a RRSIG?
[17:12:22] <Peter van Dijk> if you withhold an rrsig while one is expected, you are bogus, not indeterminate
[17:12:23] <Andrew Sullivan> If you withhold an RRSIG and it's signed, it's bogus, no?
[17:12:31] <Dan York> CHANNEL - I have to drop off to meet someone ... if someone else can please jabber relay in these final few minutes, that would be ideal. Thanks!
[17:12:45] <Andrew Sullivan> I can
[17:12:50] <Peter van Dijk> i can
[17:12:51] <Andrew Sullivan> I will relay if need be
[17:12:51] <Peter van Dijk> oh good
[17:12:52] <paulwouters> sorry yes, what if i withold the entire answer
[17:13:03] <Peter van Dijk> if you don't answer, servfail (not necessarily meaning bogus)
[17:13:18] <paulwouters> isnt that indeterminate?
[17:13:25] <Andrew Sullivan> I think the WG should invent a new DNS-only transport.  That oughta keep us busy ;-)
[17:13:26] Lars Wegmann leaves the room
[17:13:34] <Matthew Pounsett> Yeah, that's just a timeout.  Recursive servers return servfail for non-DNSSEC timeouts too.
[17:13:36] <Peter van Dijk> @paulwouters no, that is 'there is no answer, failure'
[17:13:54] <ray> ajs - you could be onto something there ;-)
[17:13:55] <Matthew Pounsett> @ajs: we have.  DNS over TLV.
[17:13:59] <Andrew Sullivan> servfail is pretty heavily overloaded.  It basically has no semantics, and that's what people want
[17:14:01] <Peter van Dijk> indeterminate is a lack of DNSSEC decision making ability, because you have no trust anchors or nsec3 optout is messing you up
[17:14:34] Brandon Williams leaves the room
[17:14:37] Weiler leaves the room
[17:14:43] Weiler joins the room
[17:15:40] Kal Feher leaves the room
[17:15:49] Jan Komissar leaves the room
[17:16:09] <Andrew Sullivan> mic line is long given that we're over time!
[17:16:25] Matthijs Mekking leaves the room
[17:16:48] Edward Lewis leaves the room
[17:17:25] <paulwouters> obsolete more algos, introduce less algos
[17:19:04] <paulwouters> Ralf Weber speaking
[17:19:45] <Andrew Sullivan> If we manage to make DNSSEC impossible for anyone to implement, perhaps we'll win a prize
[17:19:58] <Peter van Dijk> shumon says the increase is marginal
[17:20:02] <Suzanne> final session for the day tends to work well for us, since time management is always a challenge
[17:20:03] <Peter van Dijk> but the increase starts at 100%
[17:20:29] <Peter van Dijk> wait i might be lying, ignore that
[17:20:50] <Klensin> @Suzanne: unless you have made special arrangements, you are going to lose Meetecho soon.  FWIW.
[17:21:08] <Andrew Sullivan> No, we're way over time, so yes, we will lose Meetecho
[17:21:26] <Dan York> > I think the WG should invent a new DNS-only transport.  That oughta keep us busy
We seem to be already doing that with the "<foo>-over-DNS" errors in slides this week!
[17:21:29] <Andrew Sullivan> (The chairs look anxious about that)
[17:21:46] koji leaves the room
[17:21:52] Peter van Dijk leaves the room
[17:22:00] tale leaves the room
[17:22:00] Taiji Kimura leaves the room
[17:22:00] Vicky leaves the room
[17:22:00] John Levine leaves the room
[17:22:01] Yoshiro Yoneya leaves the room
[17:22:02] Miles McCredie leaves the room
[17:22:03] serenheit leaves the room: Stream reset by peer
[17:22:07] <Andrew Sullivan> /end
[17:22:07] paulwouters leaves the room
[17:22:07] Benno Overeinder leaves the room
[17:22:11] Andrew Sullivan leaves the room
[17:22:22] Weiler leaves the room
[17:22:29] Suzanne leaves the room
[17:22:29] Big bad wolf leaves the room
[17:22:30] Klensin leaves the room
[17:22:35] Wouter Wijngaards leaves the room
[17:22:42] Marco Pizzoli leaves the room
[17:22:42] Viktor Dukhovni leaves the room
[17:22:42] Juan Cerezo leaves the room
[17:22:42] Okke Timm leaves the room
[17:22:42] John Klensin leaves the room
[17:22:42] Ray Bellis leaves the room
[17:22:42] pallavi aras leaves the room
[17:22:42] Han Zhang leaves the room
[17:22:42] John Border leaves the room
[17:22:42] Andrew Hadenfeldt leaves the room
[17:22:42] Akira Kato leaves the room
[17:22:42] Peter DeVries leaves the room
[17:22:43] Matthew Pounsett leaves the room
[17:22:48] Meetecho leaves the room
[17:22:50] Dan York leaves the room
[17:22:51] <muks> wow
[17:23:07] TedLemon leaves the room: Connection failed: timeout
[17:31:58] tale joins the room
[17:34:20] ray leaves the room
[17:35:29] dkg leaves the room
[17:52:42] TedLemon joins the room
[18:00:05] Suzanne joins the room
[18:12:12] Suzanne leaves the room
[19:08:23] Lars Wegmann joins the room
[19:09:09] Lars Wegmann leaves the room
[19:31:04] mklock joins the room
[20:10:58] mklock leaves the room
[22:25:22] Big bad wolf joins the room
[22:47:30] Big bad wolf leaves the room
[22:55:42] TedLemon leaves the room: Stream closed by us: Replaced by new connection (conflict)
[22:55:42] TedLemon joins the room
[22:56:42] TedLemon leaves the room: Connection failed: timeout
[22:56:45] TedLemon joins the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!