[15:49:45] ABEL-PC joins the room [15:49:55] ABEL-PC leaves the room [20:09:13] eric.brunner joins the room [20:28:33] eric.brunner leaves the room [20:51:16] Andrew Sullivan joins the room [20:51:19] ogud: Olafur Gudmundsson joins the room [20:51:27] Andrew Sullivan leaves the room [20:52:13] ogud: Olafur Gudmundsson has set the subject to: DNSEXT Working group jabber room@IETF-73 [20:56:47] keith-1280 joins the room [21:06:33] otmar joins the room [21:10:44] Antoin joins the room [21:11:29] ogud: Olafur Gudmundsson leaves the room: Replaced by new connection [21:13:38] marcos joins the room [21:13:47] marco joins the room [21:16:34] Jelte joins the room [21:19:13] Exodus joins the room [21:19:29] Exodus leaves the room [21:19:34] yone joins the room [21:19:48] ogud: Olafur Gudmundsson joins the room [21:20:04] ogud: Olafur Gudmundsson has set the subject to: DNSEXT Working group jabber room@IETF-73 Meeting in session [21:20:07] Sam will be Jabber scribe, with me as his backup [21:20:18] fujiwara joins the room [21:20:19] but due to technical problems i'll start off [21:20:34] welcome to the meeting of the DNS extensions working group [21:21:11] andrew sullivan is showing the note well [21:21:30] shinta joins the room [21:21:47] meeting materials at http://tools.ietf.org/wg/dnsext/agenda [21:21:50] PaulWouters joins the room [21:22:01] if you are going to the mike, please say your name (every time) [21:22:08] liman joins the room [21:22:12] fdupont joins the room [21:22:13] if you are remote, and would like someone to forward your comment to the mic, please state so [21:22:20] dblacka joins the room [21:22:23] markkao joins the room [21:22:28] Agenda onscreen [21:22:39] 1. WG status [21:22:44] 2 resilience work [21:22:50] 3. proposed new work [21:22:58] and i missed the last :) [21:23:06] matt-larson joins the room [21:23:11] weiler joins the room [21:23:21] status update on dnsex-2929bis and forgery-resilience [21:23:26] jaap joins the room [21:23:34] Jim Fenton joins the room [21:23:48] Jim Galvin joins the room [21:24:02] (sam will take over now) [21:24:04] robert joins the room [21:24:07] no one responded in the sha256 "last week" post-WGLC review. [21:24:12] but still some things to clean up. [21:24:17] other docs: [21:24:30] wouter joins the room [21:24:36] no progress on a list of 4 docs. "we need you to send specific text to fix specific problems" [21:24:52] I think it's too soon to be talking about last call for -axfr-clarify [21:24:54] (seems mp3 stream is down, if anyone can fix it?) [21:24:55] mcharlesr joins the room [21:25:03] we need at least 4-5 more years for that one [21:25:04] raj joins the room [21:25:07] edsn0 needs an update. Olafur has the token [21:25:10] mp3 worksforme. [21:25:14] protocol profile is being killed. [21:25:24] Tatuya Jinmei joins the room [21:25:33] mp3 is there, but audio level is very low. [21:25:36] claudio.marotta joins the room [21:25:46] is this better audio level [21:25:47] ? [21:25:47] wouter: indeed i got confirmation it is working but very quiet now. [21:25:54] matthijs joins the room [21:25:55] yes, low. I have to bump volume to the point where I get noise. [21:26:09] there's been 2 reviews under 2929bis. [21:26:24] 2929bis due as RFC "any minute now" [21:26:25] audio is low volume but good enough. [21:26:38] Lyman Chapin joins the room [21:26:50] is that audio better? [21:27:05] yes, better [21:27:13] Suzanne joins the room [21:27:21] A little better. Acceptable. [21:27:24] pending RR request is being denied? [21:27:33] Q: any reaction to the 2929bis process? [21:27:54] Peter Koch: not sure it's a bug.... puzzled about ASSET request.... [21:28:00] ahu joins the room [21:28:06] race condition between WG working on something and expert review.... [21:28:11] bert hubert here [21:28:17] levigner joins the room [21:28:21] who retains change control of protocol? [21:28:33] if it goes to expert, then WG decides to change spec.... [21:29:10] chris_griffiths joins the room [21:29:31] Andrew: we can have the expert review based on proposal in front of us. if WG makes "significant" changes... then at IETF review... we can say "that's not what we gave early approval for; you need a new type" [21:29:47] Andrew: assumes people will use this in good faith. [21:30:13] kivinen joins the room [21:30:25] andrew: we'll be writing up a guide, but nothing more formal. [21:30:31] donald eastlake: [21:30:31] (Audio from salon C yesterday and salon D today was also extreeemely low. I have all controls on full to even listen. Would be nice if they could look at that) [21:30:46] there's a checkbox on the template for "update". [21:31:17] Further forgery resilience work. [21:31:20] Olafur: [21:31:25] ahu looks up [21:31:58] Hey Bert ! [21:32:13] hi Antoin! [21:33:00] Olafur: refers to history of Kaminsky attack. [21:33:17] task today: figure out what we've learned in last 4 months.... [21:33:27] last month or two, wg mailing list very quiet. [21:33:51] we had a call for ideas. got 6 drafts; much overlap [21:34:14] chairs asked wg to comment on ideas: almost silence. [21:34:39] chairs invited people to join a "design team". at this mtg. [21:35:06] 6 people + chairs: nicholas weaver, antain, jim reid, matt larson, peter koch, david blacka. [21:35:13] 2.5 hr on Monday [21:35:13] llugh joins the room [21:35:19] hm. my audio cut out as soon as he said "high bandwidth". [21:35:55] topic: add'l entropy [21:36:01] -- dns ping. [21:36:13] had one set of suggestions to ML before mtg. [21:36:48] order of things they think preferable: [21:36:58] dns ping -- "just do it" no harm [21:37:47] if you always go to same NS, predictable.... [21:38:06] discourage rrt banding [21:38:09] topic: data acceptance [21:38:18] (most of this is on slides) [21:38:21] dblacka leaves the room [21:38:21] matt-larson leaves the room [21:38:22] the rtt banding does not need protocol specificattion [21:38:27] dblacka joins the room [21:38:27] matt-larson joins the room [21:39:44] should caches explicit ask for authority data? design team: needs more stody [21:39:56] query fallback: [21:40:01] tcp should be avoided. [21:40:06] hi matt! [21:40:13] Hi, Bert. [21:40:20] TCP fallback will be our DOOM [21:40:23] DOOOOOOOOOOOOOOOOOOOOOOOOOOOOM [21:40:23] udb preferable to tcp, but more study needed. [21:40:31] "our"? [21:40:36] everyone [21:40:55] Other options: [21:41:05] "do nothing; this will just delay dnssec" [21:41:09] I know of only one implementatio nthat brags of TCP fallback heuristics against forgery. [21:41:16] onakayu joins the room [21:41:18] open mic [21:41:28] Shane Kerr. [21:41:30] No, DNSsec is the _solution_ to these problems. [21:41:41] Prepend entropy.... [21:41:47] Olafur: we did not look at it. [21:41:52] Shane: we should add this. [21:42:23] Ed Lewis: you didn't ask if people think this is a bad idea. [21:42:45] matt-larson: I pondered implementing TCP fallback :-) [21:42:49] Let's not do anything and get cache poisoned! [21:42:54] Ed: there's been a presumption in parts of the group that we should do something. I ahven't commented becuase I don't think it's worth doing this work. [21:42:54] ...says Ed [21:43:10] huguei joins the room [21:43:11] matt-larson: let me put it this way, if you deploy edns-ping, I won't do tcp fallback, ok? :-) [21:43:12] Bert, I will buy a ticket to The Netherlands, if necessary... [21:43:20] afraid of fixing a short-term problem w/ long-term fix [21:43:30] short term problem because of dnssec coming. [21:43:34] why dmaage protocol.... [21:43:43] short term until the glorious future of DNSSEC! [21:43:57] chuckle [21:44:01] the future is here... [21:44:01] Ed just said he sees DNSSEC solving a large part of this problem. [21:44:02] a signed zone shining on a hill [21:44:04] if you buy into "dnssec will come"..... [21:44:23] if we start putting in "little fixes", we'll have extraneous protocl gadgetry = scar tissue. [21:44:34] 0x20 is not so bad. [21:44:43] some things make protocol more complicated. [21:44:52] unlike DNSSEC hehe [21:44:59] good tech solutions now may, 5 years from now, be an irritation. [21:45:04] dblacka leaves the room [21:45:07] Olaf Kolkman: Ed++. [21:45:10] dblacka joins the room [21:45:11] simplicity is good. [21:45:18] I don't even want to think of what "Ed++" would be [21:45:29] simplicity for DNSSEC for operators is key [21:45:32] these are purely recommendation -- they don't change protocol. [21:46:09] andrew: is oalf suggesting we need "best current INTERPRETATION" docs? [21:46:35] Olaf: you can make choice to make things more robust: retry. multi queries, TCP. but those may have cost to external world.... [21:46:43] important to figure out external penalties of them. [21:46:59] stewart chesire: [21:47:25] do you really mean "must strip 0x20" (from earlier slides)? [21:47:50] stuart: current servers return case in zone file [21:47:54] olaf: no they don't [21:48:11] jelte: disagree that DNSping doesn't hurt. [21:48:35] jelte: rtt banding is an implementation issue. could be bcp, but even that is unnecessary. [21:48:55] au! [21:48:57] ;) [21:49:23] jelte: should tcpo be avoided due to server state only or also traffic? Olafur: just state. [21:49:27] TCP state-keeping will be our DOOM [21:49:28] jim reid: [21:49:46] can you explain why it will be our DOOM? [21:49:57] omg, translate what Jim says into English ! :) [21:50:00] engineering decision. we've got to do something until dnssec is more widel deployed, which won't be anytime soon. [21:50:08] we have to do something now. [21:50:13] in all seriousness, keeping state for a hojillion TCP connections is a very complicated and difficult problem on a busy server [21:50:33] good analysis of impacts, but we have to do something as an interim measure [21:50:44] robert: did that help? [21:50:45] weiler, you are faster than my audio feed [21:50:52] yes thanks [21:51:08] matt: i know but i just wanted to make sure that that was the actual issue they had with it (and not any other) [21:51:19] yes, that was the issue: it's all about state [21:51:21] dblacka leaves the room [21:51:21] I want to say that every time in the past ten years that we've had a problem that would have been solved by DNSSEC, we've heard the same thing, "DNSSEC can not be deployed" [21:51:27] dblacka joins the room [21:51:38] jim: there's no clean soln. here. better to take some kind of hit to get a short term fix. [21:51:40] Nonsense--DNSSEC will be deployed in six months. [21:51:42] if we have to take a hit, let's make the hit be: DEPLOY DNSSEC. [21:51:46] peter koch: (was part of design team) [21:51:52] I would disagree [21:52:01] DNSSEC is moving forward with ISP's [21:52:11] 'small steps for an implementer, but large steps for mankind IN THE WRONG DIRECTION" [21:52:20] short-term = half the way to DNSSEC deployment. Is there a Greek philosopher in the house? [21:52:25] mcharlesr: DNSSEC cannot be deployed just by a software update. This is what we need for fast deployment [21:52:38] http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01199.html <- ready in 6 months [21:52:40] rtt banding: urges implementers to be aware of effect of accumulated swarm behavior of resolvers hitting auth servers. [21:52:56] http://en.wikipedia.org/wiki/Zeno's_paradoxes [21:53:07] peter (still): document pro/cons is right way fwd. [21:53:13] "software update" --- you mean the one that would close windows boxes from sendig spam? I actually would claim a software update is in fact the opposite of "fast deployment". An operator action at an ISP is "fast" [21:53:25] because these ideas will pop up over and over again [21:53:30] and takes away panic mode [21:53:35] (jelta takes over) [21:53:40] i will be willing to listen to peter to explain his views to me :) [21:53:44] It's always either "you are blackmailing us into using DNSSEC" or "See, we don't need DNSSEC". [21:53:56] bruce at mike [21:53:56] jelte, rather. [21:53:58] people who dont want DNSSEC will stay not wanting it [21:54:15] bruce: what is missing from the last slide is the cost when nothing is done [21:54:54] roy arend at mike: what i understand from hallway discussion, the least evil one here is probably edns ping, but that is susceptible to downgrade unless you keep state in resolver [21:55:02] oh please [21:55:07] 1 bit, roy [21:55:11] per remote host [21:55:17] roy sees no value in dnsping. [21:55:19] roy:arends: i'd like to do nothing and await dnssec support [21:55:24] anyway. I gotta get in a vehicle now. [21:55:24] I could keep edns ping state of the complete IPv4 space *in memory* [21:55:33] rob austein: let's not add stuff that will come back to haunt us later [21:55:35] mcharlesr leaves the room [21:55:48] jim reid: most resolvers already keep state [21:56:03] (note that most of these folks were on design team) [21:56:18] matt larson: I'm puzzled about all the negative reactions [21:56:49] matt: some of these things are relatively minor, some are bad ideas but some are harmless [21:56:58] danny joins the room [21:57:06] eric.brunner joins the room [21:57:10] roque@ietf73 joins the room [21:57:15] matt: we have to be realistic, we have seen much progress in dnssec, but we also have to be realistic that large parts of the namespace will never be signed [21:57:24] stephen.morris joins the room [21:57:24] fneves joins the room [21:58:12] matt: doing nothing now is irresponsible [21:58:22] olaf: i have to agree with everybody today [21:58:42] "contientious" [21:58:50] "here endeth the sermon" [21:59:03] olaf: i'd like to see feedback from people who are more operationally inclined to say something about the impact of these things [21:59:30] (matt my mostly harmless problem is not about any one specific thing but about combining several) [21:59:33] (10:54:42 PM) mcharlesr@gmail.com/Gaim49E1534F: you might want to know that Bert Hubert runs a company called PowerDNS, and the architecture of PowerDNS prevents it from easily doing DNSSEC. [21:59:39] this was accidentally sent to me only I think [22:00:25] validated as secure is also just one bit... [22:00:26] :-) [22:00:58] ray joins the room [22:01:19] matt-larson leaves the room [22:01:30] Matt Larson joins the room [22:01:54] (me taking over) [22:02:06] Paul: disagreeing w/ Matt re: things changed after this summer. [22:02:25] we did get an incredible amount of publicity.... and a large number of name servers still haven't been updated. [22:02:41] incremental changes will get much less publicity = even less deployment. [22:02:46] and we aren't seeing attacks in the wild. [22:02:51] attack is very easy to see. [22:02:52] dblacka leaves the room [22:02:56] Paul Hoffman, that is. [22:02:58] dblacka joins the room [22:03:25] so is this a proposal to perform high-profile attacks ourselves? [22:03:27] we've advertised the vulnerability window, that there are still vulnerable hosts,..... we know little about who will be protected. [22:03:41] value might be low enough where negative change effect outweighs incremental value. [22:03:48] ted lemon: [22:04:03] economics drives fixes. [22:04:28] would like to see dnssec more widely deployed. lets spend eneergy on dnssec, not this. [22:04:39] agree [22:04:42] re: irresponsibilty: not a valid reason to do the right thing. [22:04:55] any comments for the mic? [22:05:01] if you are not with us, you are against us.. [22:05:27] are there people that think that one of these fixes can replace dnssec? Or is this all about a short-term 'before DNSSEC' (BD) fixes? [22:05:28] bush said that [22:05:32] peter koch: disagree w/ ed re: .... decisions of software vendors. ietf can't stop bad ideas....but documented BCP should continue [22:06:00] wouter: I don't think these fixes can deliver cryptographic-level security [22:06:06] peter: small changes may have large effects. even though no protocol police, should take responsibility. [22:06:23] wouter: if intended for mike, let us know explicitly. [22:06:33] weiler: as I wrote on namedroppers: whatever fancy protections (i.e. DNSSEC) we'd like to deploy. please don't negect simple, cheap, and pure software-update-only precautions. [22:06:48] wes hardaker: interesting that there's silence. it's hard to get excited about a hack. we have "good work that is shoddy" [22:07:00] I'm very much for the EDNS ping draft. [22:07:08] here, here [22:07:19] I also resent calling these "hacks" [22:07:23] otmar, for the mik? [22:07:27] please [22:07:31] thank you wes :) [22:07:40] wes hardaker makes good sense [22:07:57] Melinda_bb joins the room [22:08:00] keep it simple [22:08:06] hardaker: will we actually remove these hacks in 5 years? is this really temproary? [22:08:08] these are not hacks [22:08:15] some are [22:08:17] jason livinggood: [22:08:19] keep it simple == DNSSEC? give me a break. [22:08:27] are attacks seen in wild? [22:08:28] and if you think DNSSEC will be deployed in 90% of zones, you are...living in a different universe. [22:08:38] he's seeing a largenumber on a regular basis. [22:09:36] (missed the name) a comment: part of the thing is, it actually looks like there's interesting interaction between multiple layers [22:09:42] nick weaver. [22:10:07] nick weaver: there are interactions between solns, that may be useful. [22:10:12] alex joins the room [22:10:22] it's the 'better bike lock' scenario. yes dnssec will gain 80%+ deployment.... [22:10:24] nick weaver: wish there were more academics like me. [22:10:42] PaulWouters: how do you know? [22:10:48] advantage for doing nothing: 30 bits won't deal w/ high bw attack. [22:11:02] as attacker, what will you spend bot traffic for? [22:11:07] attack low hanging fruit... [22:11:13] do nothing is attractive. [22:11:35] alex leaves the room [22:11:36] eric.brunner leaves the room [22:11:37] olafur closes mic. [22:11:47] Alex joins the room [22:11:58] ahu: how many unlocked bikes do you see? [22:12:01] sra joins the room [22:12:04] req to list will make "do nothing" option clear. [22:12:18] to paul wouters: lots, in Seattle. [22:12:19] it if costs money, you get a new lock. if your DNS is losing you money, you get a better DNS [22:12:23] ray leaves the room [22:12:24] eric.brunner joins the room [22:12:32] New Work. [22:12:38] AJS speaking. [22:12:55] oh no all the other bikes have good locks, everyone is targeting my bike, lets buy a lock. [22:13:01] bellis...dnsproxy [22:13:20] Olafur: 6-7 have read [22:13:23] otmar leaves the room [22:13:24] stephen.morris leaves the room [22:13:24] eric.brunner leaves the room [22:13:24] fneves leaves the room [22:13:25] Olafur: will adopt soon. [22:13:45] Olafur: trying to get it done "soon". [22:13:52] eric.brunner joins the room [22:13:53] fneves joins the room [22:14:00] bagnulo-behave-dns64 [22:14:11] oops, back up. [22:14:13] ahu: just trying to explain Paul's line, but really, you are dutch too. [22:14:22] Alex leaves the room [22:14:23] eric.brunner leaves the room [22:14:41] no one spoke in opposition to adoption of dnsproxy [22:14:56] eric.brunner joins the room [22:15:10] lecture on commitment to reviews. [22:15:21] bagnulo-behave-dns64 [22:16:03] AJS: this is here because behave wg charter forces docs w/ dns implications to have a WGLC HERE. [22:16:17] seriously, large % of zone DNSSEC deployment, simply hinges on a couple of zone grabbers, doesn't it [22:16:44] AJS: implies this doc is on the agenda in Malta (Jan interim mtg) [22:17:07] Wouter: What is a "zone grabber"? [22:17:21] cannot hear [22:17:23] wouter, the largest operators of zones currently run based on a Perl-based DNS solution [22:17:34] what interim mtg? [22:17:56] IETF wide interm meetings to be held in Malta in January [22:18:08] what week? [22:18:21] marcel will describe behaviour and then ask some questions about the options we can take [22:18:44] application scenario slide [22:18:46] (jelte taking over; see slides) [22:19:22] two boxes: nat64 and dns64 [22:19:32] don't want to do changes on hosts [22:19:47] no support for v6 only servers. only v4 or dual stack. [22:20:02] two scenarios: ipv6 end site/isp on one side, v4 internet on the other side [22:20:13] other one: ipv6 internet and v4 only end site [22:20:32] (DNS64 function location slide) [22:20:44] Can somebody tell me in a crispy sentence what this dns64 thing is? [22:21:09] dnsalg by another name i think [22:21:22] dns64 location needs to be put in local nameserver (hosts could do it too but that requires longer deployment) [22:21:42] ray joins the room [22:21:56] ipv6-network-to-ipv4-internet slide [22:22:21] mic [22:22:24] comment from room: you said nothing new, but you've got synthesis on the fly [22:22:32] thanks [22:22:45] ray leaves the room [22:22:55] question from speaker: should we tag synthetic records? [22:23:20] you need to do something, because you are changing the answer [22:23:22] dblacka leaves the room [22:23:29] dblacka joins the room [22:23:32] if tagged, at least DNSSEC may be easier... [22:23:32] (when AAAA records are synthesized for the v6 only local network asking about a v4-only internet location) [22:23:38] dnssec in this? [22:23:57] lots of slides later on [22:24:11] i think one of the requirements of this it does not break dnssec [22:24:31] ed lewis: it shouldn't matter whether it is synthetic for the end hosts, but probably does for the caches in between [22:24:33] chris_griffiths leaves the room [22:24:38] weiler leaves the room: Replaced by new connection [22:24:42] weiler joins the room [22:24:48] marcel: that was another part, what should the ttl be [22:25:07] marcelk: any time you contact the same host, you'd syntehesize the same record [22:25:27] ed: how long do you think the data is good for, is what the ttl is, not how long you think the data is stable [22:25:54] francis dupont: you should be able to recognize synths by prefix, so tags should not be needed [22:26:41] marcel: these are real ipv6 addresses... [22:27:33] andrew (no hat): if you're inside the site, you can tell, but if the records gets on the internet, there is no way to tell [22:28:11] iljitsch: operators will not give access to translator to random places on the internet [22:28:38] iljitsch: if you give that data to someone at another site it will not work [22:29:05] peter koch: you are not tagging the AAAA but you are tagging the address instead? [22:29:23] i thought the dns response was tagged... [22:29:46] peter: if you're afraid of the content leaking out, that would mean marking the content as non-routable [22:30:00] peter: but that's a spearate issue [22:30:30] marcel: about recognizing: how likely is this to leak? i have contradictory opinions on this [22:31:02] and now marcel lost me :/ [22:31:12] Melinda_bb leaves the room [22:31:27] ilj: should behave adopt a well-known prefix? [22:31:29] its marcelo btw [22:31:34] marcel: that's not what we are here for [22:31:48] peter: i would say it is not a dns issue, aaaa is agnostic about semantics [22:32:27] but the host is asking for an AAAA RR, and he has to know if the answer was authentic or synthetic [22:32:37] francis: for ipv6 internet scenario you'd need more than one prefix [22:32:46] rob austein: this is not a dns issue indeed [22:32:59] rob: my problem is wth one of the premises [22:33:18] rob: you appear to deal with legacy v6 hosts [22:33:29] dblacka leaves the room [22:33:33] rob: push the smarts to the host, not the middle of the net. [22:33:34] rob: but to differentiate, hosts need to be aware of behave [22:33:39] dblacka joins the room [22:34:01] warning: DNSSEC slides upcoming. [22:34:05] mark andrews: leakage will be a probem even with tagging [22:34:24] (missed name) with legacy hosts, they will not understand tags anyway [22:34:40] bernie voltz? [22:35:11] nmarcel, next silde, dnssec support [22:35:14] roque@ietf73 leaves the room [22:35:14] roque@ietf73 joins the room [22:35:20] marcel: how are we going to support dnssec? [22:35:44] you will need to perform synth after validation [22:36:01] so the server must do that [22:36:19] if you want the host to do synthesis, you'd have to do that after validation on the host [22:36:57] s/marcel/marcelo/g in all of the above, my apologies [22:37:41] mark andrews: in one of the scenarios you are just publishing quad-a's, so just don't mention synthesis there [22:38:11] marcelo: what happens with dynamic update? [22:38:16] (rob: thank you!) [22:38:21] "it hurts when i do that" "don't do that" [22:38:24] except, of course, people will [22:38:29] this is painful. [22:39:10] mark andrews: when doing dynamic dns, you want to synth on update, not on query [22:39:23] john schnitzlein [22:39:29] from isoc [22:39:37] (spelling likely incorrect) [22:39:37] where to publish the AAAA's? they contain both local and remote information right? [22:40:04] right [22:40:18] the scribes fail to understand the Q. [22:40:20] which slide? [22:40:33] app support -- refined. [22:40:36] i think there is confusion about the different scenarios [22:41:13] ? [22:41:25] mike! [22:41:37] ahu leaves the room [22:41:45] Matt Larson leaves the room [22:41:48] (from room) john is question a problem in case one, not being addressed in case 2 [22:42:02] chairs: we're running late. [22:42:15] scenario's are indeed confusing:) [22:42:18] that's not a scribe comment: that's me telling Olafur... [22:42:31] mark andrews: in both cases, the site doing the NAT is creating a prefix, in one case you publish that to the world, in the other only to your own site [22:42:53] he's leaving 5/6 DNSSEC slides not presented. [22:43:14] (scribing again) AJS: it's clear there are people here w/ expertise to bring to bear on this doc. [22:43:27] AJS: disclaimer: I'm an editor. would appreciate people spending time on this doc. [22:43:38] i read it [22:43:45] (we're about to move on) [22:44:06] AJS: I wrote the passage in the doc, but I'm not sure it works... use behave mailing list. [22:44:28] moving on.... [22:45:01] draft-andrews....expire [22:45:07] mark andrews: [22:45:45] occasionally expire field not honored. slaves don't get updates due to loops in zone xfer graph. [22:45:54] pass info down zone xfer graph.... [22:46:27] when have daisy chained servers. expiry intervals double.... problem in terms of making more robust NSs [22:46:36] have slaves talk to each other if master goes down [22:46:45] (expiry intervals could increase to infinite) [22:46:48] Q: adopt? [22:47:02] ~5 in room have read draft [22:47:08] Q: does it solve a real problem? [22:47:40] peter koch: a brave attempt ... to try to expire a zone...and rely on it vanishing. before working on this, need to clarify semantics of expire field. [22:47:41] sm joins the room [22:48:15] relief for secondary, but not a measure of control for zone admin. find no support for mark a's view in the "scriptures". clarifying that is a precondition [22:48:37] andrews: if a secondry can't talk to master, it's supposed to expire zone. [22:48:55] austein: [22:49:28] this is supposed to provide relief to serrver ops who have constructed hideously complicated zone xfer graphs. [22:49:37] Matt Larson joins the room [22:49:41] how much do we want to protect them from v. say 'you shot yourself in the foot' [22:50:01] is there any sane reason to build zone xfer graphs that complicated? [22:50:05] marka : I'm aware of a number [22:50:09] rob: that doesn't make it wise [22:50:10] 7 [22:51:08] ed lewis: good to bring this in. unlike ttl etc. when you get a zone xfer you don't know how long the zone has been around. we have that countdwon for data, but not the zone [22:51:12] jelte: agree w/ ed. [22:51:22] jelte: can we say "don't do that" [22:51:34] marka: "no, cause they don't read it... i want this to be automated" [22:51:59] can someone step in for a moment? [22:52:12] Sure. I'll step in. Seriously. [22:52:36] Andrew: out of time. Will take to the mailing list. Some expression of interest [22:52:41] Have request before the WG to adopt the document. [22:52:57] Mark to send request for adoption to the mailing list and look for the usual 5 people to commit to review and work on it [22:53:05] Will also entertain arguments as to why it shouldn't be adopted [22:53:14] Need to make the decision on the list [22:53:19] And if you support it, you're signing up to do the work [22:53:25] (scribe grumps at having the line cut off before he got to the mic, when he had been busy scribing) [22:53:38] New topic: request from Scott Rose to adopt dnssec-algo-signal [22:53:45] send it to the list :) [22:53:50] If you want it adopted, send to the list [22:54:05] oh i had comments about that one too :( [22:54:13] AOB: Stuart Cheshire on his sleepy proxy [22:54:13] to the list!;) [22:54:15] kivinen leaves the room [22:54:31] Stuart: sent an email to the list, will send a request to IANA for a new EDNS option code [22:54:47] Working on an idea where when a machine goes to sleep, it uses mDNS to find a proxy [22:55:01] "Here are the DNS records that describe my services" and goes to sleep [22:55:08] Uses wake-on-lan to wake it up when someone needs it [22:55:11] Need MAC address [22:55:19]