[06:42:32] Ralf Weber joins the room [06:44:46] fdupont joins the room [06:49:33] fneves@jabber.registro.br joins the room [06:51:44] yone joins the room [06:53:40] Antoin joins the room [06:54:25] James Galvin joins the room [06:54:33] Olafur joins the room [06:55:24] ray joins the room [06:55:36] David Conrad joins the room [06:57:01] mlepinski joins the room [06:57:21] Suz joins the room [06:57:28] jakob@キレイ.se joins the room [06:57:46] but dnsop at ietf75 is just beginning..... [06:58:03] Exodus joins the room [06:58:09] Antoin has set the subject to: DNSOP at IETF75 [06:58:12] rhe joins the room [06:58:17] sconte joins the room [06:58:18] marka joins the room [06:58:28] Dowon Kim joins the room [06:58:45] sm joins the room [06:58:56] pawal joins the room [06:59:05] Brenden Kuerbis joins the room [07:01:43] shinta joins the room [07:01:45] Brenden Kuerbis leaves the room [07:02:03] jabley joins the room [07:02:05] Brenden Kuerbis joins the room [07:03:34] Andrew Sullivan joins the room [07:03:37] huguei joins the room [07:04:02] matthijs joins the room [07:04:04] Andrew Sullivan will be your jabber scribe [07:04:08] takasima joins the room [07:04:10] ja joins the room [07:04:26] scott_rose joins the room [07:04:29] Kim Davies joins the room [07:04:37] Apologies in advance for my lousy typing and tendency to spell people's names wrong. [07:05:04] BTW, I'm at the very back of the room, so I can't see you if you go to the mic [07:05:08] so you have to say your name [07:05:28] quite how anybody is going to fight it out from the middle of any row to the mic remains to be seen [07:05:42] JeremyHitchcock joins the room [07:06:08] Surely they'll leap to the mic in a paroxysm of anxiety about falsehoods. [07:06:10] the room is perfectly staged to quell dissent ;) [07:06:16] Agenda at http://www.ietf.org/proceedings/75/agenda/dnsop.txt [07:06:25] koji joins the room [07:06:43] As long as we've pushed all the trouble-makers to the middle... [07:07:04] There are meeting materials at https://datatracker.ietf.org/meeting/75/materials.html [07:07:09] Rob starts the meeting [07:07:29] fujiwara joins the room [07:07:43] Jelte joins the room [07:07:46] Peter Koch sends regrets. Jaap Akkerhuis os filling in [07:07:50] Agenda bashing [07:07:52] . . . [07:08:07] Alain? asks for 5 mins under A.O.B. [07:08:30] Alain Durand, I think [07:08:31] WG progress: Chair apologises for lack of progres [07:08:53] Johan Ihren now up for the key timings draft [07:09:14] Roy Arends joins the room [07:09:32] (item 3.1 on the agenda) [07:09:39] Johan is making slow progress to the mic [07:09:46] agile as a mountain goat [07:09:50] (For those not in the room, this room is set up like a theatre [07:09:57] sandoche joins the room [07:09:57] jinmei joins the room [07:09:59] and therefore it's hard to get out from where you are sitting) [07:10:03] Jaap on lead guitar [07:10:14] mark andrews on drums [07:10:28] drugs? oh drums! [07:10:42] yes the room is not ideal for an interactive discussion [07:11:08] You can have an interactive discussion in any room if you're willing to work hard enough at it ;-) [07:11:39] Now waiting for the projector to detect Johan's laptop. [07:11:42] dcrocker joins the room [07:12:31] Panagiotis.Saragiotis joins the room [07:12:55] Giving up on display [07:12:59] after 5 minutes Johan does not his slides [07:13:06] s not not need [07:13:25] he is the consummate showman, whetting everyone's appetite... [07:13:38] einar joins the room [07:13:49] lgforsberg joins the room [07:13:52] Reminder: draft was presented in San Francisco [07:13:57] Asked to be accepted as WG doc [07:14:14] Wolfgang Nagele joins the room [07:14:14] Wolfgang Nagele leaves the room [07:14:17] failed to submit a new version yet. What's the present state? [07:14:25] gih joins the room [07:14:36] updates: had comments on ML & private, believe they've been addressed [07:14:56] psavola joins the room [07:15:00] major item: management & handling of 5011 revoke status? Johan lost, and so it's going to be included [07:15:07] still working on acronym soup. [07:15:36] edmon joins the room [07:15:38] Somewhere around 30 vars, and hard to read. Trying to make it comprehensible, if not easy to read [07:15:53] Also, need to interact with 4146 bis [07:16:10] AltumSE joins the room [07:16:24] (s/4146/4641) [07:16:41] planning for new submission in August, so watch for it [07:16:47] Questions? [07:16:59] None [07:17:14] juampe.cerezo@gmail.com joins the room [07:17:23] Now time to wrestle with projector again [07:18:09] Now Wouter Wijngaards [07:18:17] Draft-wijngaards-dnsop-trust-history [07:18:22] http://www.ietf.org/proceedings/75/slides/dnsop-1.pdf [07:19:39] einar leaves the room [07:19:45] einar joins the room [07:19:46] Giving up on displaying slides [07:19:55] Wouter is asking for adoption of his draft [07:20:12] Plan is to support end-users who want validators on their machine [07:20:47] They don't stay online all the time. 5011 works fine for things online all the time, but not so good for end users [07:20:57] (slides being displayed now) [07:21:32] So this draft is an attempt to make the old trust anchor is up to date, over port 53 ^c. [07:21:35] &c [07:21:54] This does not remove any security from 5011. [07:22:06] slide 2 [07:22:36] richard.barnes joins the room [07:22:52] matthijs leaves the room [07:22:54] abelyang joins the room [07:23:06] matthijs joins the room [07:23:18] It's important to fetch the keyset first, to protect against attack at step 3 [07:24:45] Slide 3 [07:25:10] the TALINK RRTPYE is needed to make this work [07:26:34] Again, Wouter emphasises that this is to support end users, and not always-on systems [07:26:39] Steve Crocker at mic [07:26:44] nice, but two things [07:26:45] einar leaves the room [07:26:50] einar joins the room [07:27:00] psavola leaves the room: Replaced by new connection [07:27:00] psavola joins the room [07:27:07] 1. as w/ 5011, how do you test whether this part works? [07:27:12] Long wait times [07:27:34] Wouter: configure with backdated test chain [07:28:07] Steve: general idea, algo's like this need to be testable, so there's more work to do. It would be good to speed things up for testing [07:28:13] 2. How long is this chain? [07:28:30] Suppose the chain is very long, w/ large number of changes [07:29:02] possible to make small change to the approach to bootstrap (suppose someone's offline for 10 years). [07:29:20] huguei leaves the room [07:29:32] Wouter: if you roll every 30 days . . . [07:29:44] Steve: no, suppose you're testing, so you're rolling every minute [07:30:28] Rob: if you're only testing, it doesn't have to be really efficient [07:30:38] Steve: yeah, but needs to be in tolerable time [07:30:56] Someone at mic: replacement of 5011 or complement? [07:31:26] Wouter: little coy, but 5011 is the basic mode, and this is really a fallback strategy [07:31:37] Someone == Johan Ihren [07:31:38] cgriffiths joins the room [07:31:53] mic: requires zone owner to publish TALINK [07:32:20] Wouter: just _someone_ has to publish. It's an old key, so good enough. [07:32:34] Johan: unfortunate to have this and 5011. But important to do [07:32:38] this is a real problem [07:32:48] Bill Manning at mic: [07:32:51] David Conrad leaves the room [07:32:51] JeremyHitchcock leaves the room [07:32:59] JeremyHitchcock joins the room [07:33:01] David Conrad joins the room [07:33:19] Lead person on that draft (? one Johan just mentioned?) was Olaf Kolkman [07:33:35] Ralf Weber leaves the room [07:34:16] Temporal quality to 5011 with a "best practice" of every 30 days. What this does is a more general purpose mechanism of how to resync. Likes this approach. [07:34:24] Something like this should replace 5011. [07:34:42] Wouter: reason 30 days in draft now because it was not intended to compete w/ 5011 [07:34:45] Cory von Wallenstein joins the room [07:35:01] Wants this to be addition/backup strategy [07:35:23] if WG wants to use this to replace 5011, then that's ok with him [07:35:31] ray leaves the room [07:35:41] note that the key in step 3 is required to be a SEP key [07:35:55] [couldn't hear & can't see] at mic [07:36:10] what if your key is lost and you cannot use it any more? [07:36:17] jpc joins the room [07:36:25] juampe.cerezo@gmail.com leaves the room [07:36:44] what if a mechanism for completely changing key is easier to implement than keeping the chain of trust? [07:37:00] Wouter: yes. If key actually lost, you can't continue chain of trust in zone [07:37:18] 5011 would have lost track as well. If you can't get a signature in the chain, you're hosed [07:37:23] Ricardo joins the room [07:37:31] put a revocation in, don't lose that! [07:37:36] add new keys, &c. [07:37:51] haa joins the room [07:38:15] abelyang leaves the room [07:38:25] [Olaf Kolkman -- didn't say name! bad!] [07:38:42] argue that if trust anchors are maintained by OS anyway, why use this? [07:38:52] [alternative phrasing of same question] [07:39:03] einar leaves the room [07:39:08] einar joins the room [07:39:32] Wouter: ok, sure. But this approach does not require the OS to do it, and so you don't have to trust OS to do it right. Just a different path. This is not the only way to do it [07:39:33] (Question before last was Antoin Vershuren (spelt wrong, sorry)) [07:39:38] Rob closing mic [07:39:50] Roy Arends at mic [07:40:05] A few years from now I replace my 512 bit key [07:40:12] that key has been around for a long time [07:40:21] and the key has been broken [07:40:38] Wouter: well, your zone is lost then. Once it's been broken, you need an out of band approach [07:40:52] Roy: yes. Will you say more about the leap of faith argument? [07:41:14] os updates use dns... [07:41:24] Wouter: if you don't have a key, a leap of faith is one of your strategies [07:41:37] Roy: but such a leap of faith is less secure than plain DNS. [07:41:57] so please add something to the draft about it [07:42:12] Rob (as chair): is this a DNSOP or DNSEXT doc? [07:42:27] haa leaves the room [07:42:29] Wouter: operations support [07:42:45] Rob: ok, we'll maybe huddle about the right WG for it [07:43:03] mgraff joins the room [07:43:38] The operator has to decide when a key is no longer safe to use, even ones that are N years old, and not provide a chain for those. [07:43:39] Ted Lemon: nervous about potential for undetected compromises here. Really assuming people are watching log files [07:43:59] Rob: assuming this ends up in DNSOP [07:44:03] adopt? [07:44:30] Chair sees support for document [07:44:37] 8-10 people apparently willing to review [07:44:42] did not take names [07:44:44] The draft should talk about keeping only history for a limited number of years [07:45:09] Kim Davies leaves the room [07:45:09] David Conrad leaves the room [07:45:09] JeremyHitchcock leaves the room [07:45:11] NExt [07:45:12] einar leaves the room [07:45:12] Next [07:45:17] JeremyHitchcock joins the room [07:45:17] einar joins the room [07:45:18] David Conrad joins the room [07:45:19] Kim Davies joins the room [07:45:27] Jason Livingood [07:45:34] draft-livingood-dns-redirect-00.txt [07:45:37] edmon leaves the room [07:45:50] edmon joins the room [07:45:53] No slides online [07:46:07] But his display came up first try! [07:46:20] Will the slides appear online later? [07:46:25] yes [07:46:36] Was prepared for reaction [07:46:40] he will get them posted after the presentation [07:46:46] but wants to be transparent and wants feedback [07:46:47] Thanks [07:46:59] Detailed and open minded review, please [07:47:33] Slide 2 [07:48:37] slide 3 [07:49:04] describing 4 major types of redirect. The web stuff is the most common [07:49:08] but there are some others [07:49:53] wouter joins the room [07:50:14] roque joins the room [07:50:30] Discussion of opt-out and opt-in. Notes that users may not feel the same way about default opt-in or -out as the DNSOP community feels [07:51:10] Incomplete sections: Appx B is tracking open issues [07:51:17] DNSSEC stuff needs a lot of work [07:51:20] einar leaves the room [07:51:21] it does [07:51:25] einar joins the room [07:51:27] we are of thought [07:51:36] Perhaps DNSSEC portion should just say, "These are incompatible." [07:51:48] agreed [07:51:54] matthijs leaves the room [07:51:59] BCP/Informational? Some controversy here :D [07:52:00] that redirect does not work with DNSSEC [07:52:13] I am of that opinion [07:52:17] Very helpful to get detailed review [07:52:23] matthijs joins the room [07:52:25] as opposed to "this is lying crap, please leave" [07:52:59] has now got some specific use cases for failure modes, so helpful (but if you have more, that's ok) [07:53:22] is there something that should be sent to DNSEXT for a protocol mechanism to do this [07:53:37] Rob Austein not as Chair [07:53:49] wants motivation for why to do this [07:54:00] thinks the real reason is "it would cost more to do it otherwise" [07:54:07] and that needs to be outlined explicitly [07:54:10] Chris Morrow [07:54:15] Has not read draft [07:54:33] not in best interests of network in general to codify how to do this sort of thing [07:54:42] therefore, opposed to adopting [07:55:01] Rob (as Chair) [07:55:07] two directions [07:55:13] one: if you're going to do this, here's how [07:55:36] two: here's a tech we know people are using, here's why, here are reasons why bad, here's what people actually do, make tradeoffs clear [07:56:01] Olaf Kolkman suggests there is a framework for this in an IAB draft [07:56:45] Sorry, too much distorion, didn't hear at mic (but sounds like Antoin) [07:56:57] missing problem statement [07:57:08] Yup, Antoin Verschuren. [07:57:26] JeremyHitchcock leaves the room [07:57:26] David Conrad leaves the room [07:57:34] If this is just to redirect web things, then the draft doesn't belong in DNSOP [07:57:34] JeremyHitchcock joins the room [07:57:37] David Conrad joins the room [07:57:56] but DNSOP should produce a redirect about what bad effects happen [07:57:59] psavola leaves the room: Replaced by new connection [07:57:59] psavola joins the room [07:58:24] Jason suggests he maybe needs to add descriptions of other techniques [07:58:30] Wes Hardaker at mic: [07:58:34] changed mind in last 30 mins [07:58:51] matthijs leaves the room [07:58:55] needs to document list of cons, but now thinks we should do Rob's direction 2 [07:59:07] wouter leaves the room [07:59:21] people do seem to realize that refusing to have a document won't stop anyone [07:59:24] abelyang joins the room [07:59:40] wouter joins the room [07:59:51] matthijs joins the room [07:59:55] Michael Graff at mic [08:00:08] psavola leaves the room: Replaced by new connection [08:00:08] psavola joins the room [08:00:09] Nothing in draft about what happens when you're _not_ a web browser [08:00:31] Jason: yes, argument that deep-packet inspection vendors use [08:00:38] The biggest requirement for the DNS Redirect spec is to be complete and explicit about the scenarios it can work for and the ones it simply cannot. [08:00:57] Vijay [didn't hear] at mic [08:01:05] Vijay Gill. [08:01:26] psavola leaves the room: Replaced by new connection [08:01:26] psavola joins the room [08:01:27] conccerned about "stamp of approval from IETF" [08:01:50] I lost track of the last speaker, sorry [08:01:53] Malicious site redirection is probably generally ok to just redirect at DNS level. However, redirecting all traffic in the NXDOMAIN case seems like a very bad idea overall. Email typos would do what? [08:01:54] Rob as Chair [08:02:12] could include text that says, "This is very bad." [08:02:31] we still need all the costs on the table to make such a draft even sensible [08:02:36] rob suggests path where this draft becomes "draft-dnsop-dns-redirect-considered-harmful" [08:02:40] note that web proxies cost a lot to operate [08:03:13] wouter leaves the room [08:03:30] ray joins the room [08:03:33] Linus Nordberg joins the room [08:03:43] legally-mandated redirect is partly about reducing help desk calls. This needs analysis, and the issue isn't always the ISP [08:03:53] einar leaves the room [08:03:59] Jason: web proxy issue is both scalability and also privavy [08:04:01] privacy [08:04:02] roque leaves the room: Replaced by new connection [08:04:14] when law enforcement finds out about the logs, issues may crop up [08:04:17] I have no problem with redirects for legal mandate or security purposes. I have big problems with redirects of NXDOMAIN responses [08:04:26] ray: I agree. [08:04:46] Surprised not to get more feedback about the legally-mandated area [08:04:58] Mark Andrews @ mic [08:05:04] roque joins the room [08:05:09] concentrating on NXDOMAIN redirect [08:05:18] Matt/Ray: important to note there are many different user bases in an ISP [08:05:18] shows up lack of something in the way http is handled [08:05:36] and how you implement NXDOMAIN redirection [08:05:43] and importance for a good opt-out [08:05:43] would be nice to have extensions to DHCP to tell systems, "go here for nice NXDOMAIN" [08:06:51] Problem with change of namespace, particularly for NXDOMAIN [08:07:01] Doug Otis @mic [08:07:19] had a project a couple years ago. Browser is where vulnerabilites occur [08:07:32] and not happy with the response time from browser vendors [08:08:01] wouter joins the room [08:08:09] project was killed because too hard to support [08:08:18] it had to be perfect, and couldn't make it that [08:08:25] and you have to go to several major browsers and various browser revisions to even get 98% coverage [08:09:04] AleksiSuhonen joins the room [08:09:24] Jason: yes, malware protection is important [08:10:04] Chris Morrow again. Sympathetic, but web is not the Internet [08:10:07] can't solve this in DNS [08:10:20] let's look at the DNS synethesis draft & update that [08:10:46] The real problem here is we are proposing different solutions. This draft documents current practices. Anything that says "use something else" is going to be ignored. [08:11:00] agreed [08:11:01] Debating whether this is a good idea needs to be a separate discussion from this effort, which is attempting to accurately document existing practice. [08:11:10] we are trying to document current implementations and practices [08:11:23] the finnish police's lawful intercept redirects to their server which i think is able to let good website subdirectories pass and blocks only the bad things (child porn under the finnish law) [08:11:26] gigix73 joins the room [08:11:40] New Zealand does that too [08:11:41] Rob: very unhappy that this is completely incompatible with DNSSEC [08:11:47] My only concern in this whole thing is that it needs to say specifically that there are problems, and what they are. There is a section talking about the HTTP flow, but nothing about SMTP, FTP, or other protocols. [08:11:51] Olafur Gudmonsson @ mic [08:12:06] Doesn't like the draft, but admits he does it at home [08:12:31] should also talk about what if end systems use their own recursive systems [08:12:45] qualify that - he does domain blocking at home, he doesn't rewrite NXDOMAIN at home. The latter is what most people object to. [08:13:06] Jason: some discussion in draft, but needs to be better documented [08:13:20] to whoever said earlier "we should write as many reasons in the draft about why it is a bad thing": if the list is too long, people won't read it all the way through and they won't see the reasons that would turn their minds [08:13:20] psavola leaves the room: Replaced by new connection [08:13:20] psavola joins the room [08:13:21] what Ray said is a better expansion of what O.G. said [08:13:49] [missed] is there anyone in the world who puts "no redirect" in contracts? [08:13:56] Wants that from ISP [08:13:59] glenn kowak [08:13:59] [missed] == Glenn [08:14:21] Jason: don't know. may be upshot of current FCC rule. [08:14:25] JeremyHitchcock leaves the room [08:14:33] JeremyHitchcock joins the room [08:14:56] [missed-- Antoin again?] I know my ISP has something along these lines in contract [08:15:04] Right now there seems to be NO mention about this as a bad thing. [08:15:07] Glenn: is ISOC messing with this at all? [08:15:15] That is, no side effects discussion at all. [08:16:04] could we consider this as part of "net neutrality"? [08:16:05] psavola leaves the room: Replaced by new connection [08:16:05] psavola joins the room [08:16:17] I don't see how. [08:16:42] If someone were to redirect competitor.com to a proxy that made all images load slowly, then sure. [08:16:42] we shold have a poll - who objects to lawful redirect, who objects to malware protection, who objects to NX DOMAIN redirects? [08:16:45] Danny McPherson: actually is an RFC on what expectations of internet connectivity is. don't have ref. On earlier comment, malware usually resets resolver. If you're doing this to protect subscribers, then likely to be rewritten [08:16:50] (for me, no, no, YES!!!!) [08:17:17] Ray: object to it happening, or object to documenting it? [08:17:23] But remember, this is not a good/bad thing. [08:17:29] It's a current practices summary. [08:17:29] Bill Manning: worthwhile to document technology and techniques [08:17:32] objects to doing it [08:17:33] psavola leaves the room [08:17:42] and point out that it's going to be hurtful [08:18:21] Bill again: reasons to do in controlled environments if your customers are fully informed and agree to it [08:18:35] as soon as it affects me & I'm not one of your customers, there's a problem. How is this containable? [08:18:44] I see that we as IETF have two options: (1) reject this RFC entirely. (2) accept it. [08:18:50] Rob: 5 min warning [08:18:59] if possible we should get a separate draft on "lawful intercept / etc" and then address the prblems caused by NXDOMAIN rewrites separately [08:19:05] I don't think we are capable of saying "this is good or bad" in this context. [08:19:10] [?] cannot be fully informed. Can't opt out reasonably [08:19:28] (Chris Morrow) [08:19:34] Places where this will work, but inside an ISP you can't be fully informed [08:19:49] Bill: Olafur's children are probably informed by their parents [08:19:59] yao joins the room [08:19:59] Agree to separate/rewrite about lawful intercept/malware stuff. [08:20:02] Chris: does your SIP client use DNS? [08:20:22] [?] Olafur is not rewriting NXDOMAINs [08:20:29] which is a different matter [08:20:33] [I think it's Ray] [08:20:34] (Ray Bellis) [08:20:35] David Conrad leaves the room [08:20:36] JeremyHitchcock leaves the room [08:20:43] JeremyHitchcock joins the room [08:20:45] David Conrad joins the room [08:21:10] Rob: there's the policy space issues too. Not going into it today [08:21:18] (yes, it was me, sorry) [08:21:18] Olafur is not a common carrier, so it doesn't count [08:21:24] einar joins the room [08:21:30] Rob: sense of room [08:21:31] parentally mandated redirect [08:21:49] Does anybody mind if Jason submits another version? [08:22:13] Sam Weiler: co-editor who is willing to add applicability statement? [08:22:25] Lars Liman: I would rather see what he does behind curtain [08:22:39] Jason should be allowed to use the dnsop mailing list [08:23:06] unless mail.ietf.org is redirected somewhere [08:23:08] Ray again: useful to separate drafts for traffic-won't-happen (NXDOMAIN) and traffic-will-happen [08:23:11] Lucy Lynch [08:23:33] support Rob's previous suggestion, use this as the basis for a WG draft [08:23:38] (option 2) [08:23:59] Jason: if complaint is that ISPs go away and don't bring problem statements to IETF [08:24:16] then here's the effort of someone bringing work here [08:24:37] Lawful intercept and malware protection is a technical problem. NXDOMAIN is a commercial opportunity [08:24:37] yao leaves the room [08:24:44] Danny: it's an individual draft right now, so "you can do what you want" [08:25:00] Rob does not think documenting government mandates most urgent problen [08:25:04] problem [08:25:12] Rob thanks Jason [08:25:18] richard.barnes leaves the room [08:25:24] End of that segment [08:25:27] And now back to our regularly scheduled bickering. :) [08:25:30] next [08:25:34] 4.3 [08:25:42] 4.3) draft-ljunggren-dps-framework-00.txt [Anne-Marie Eklund-Lowinder]][20 min][10:10] [08:27:09] weshardaker joins the room [08:27:53] Slide 3 [08:28:42] Slide 4 [08:29:16] Since se has been signed for a long time, they're experienced [08:29:27] and the DPS is the result of some of that experience [08:30:01] will help trusting parties to determine whether they should in fact trust operator [08:30:15] slide 5, comparison w/ PKI [08:30:50] gigix73 leaves the room [08:30:54] DNSSEC does not work with the kind of audits that are found in PKI, Webtrust audits [08:31:31] [slides for Jason Livingood's presentation just showed up in my inbox from DNSOP] [08:31:39] matthijs leaves the room [08:31:40] rather, with DNSSEC you don't need an audit to play [08:31:51] with X.509/HTTPS you need an audit to get into the trust anchor store that vendors distribute [08:31:53] Who should publish a DPS? [08:31:59] What Joe said [08:32:13] Who should be interested in a DPS? [08:32:33] matthijs joins the room [08:32:46] David Conrad leaves the room [08:32:56] David Conrad joins the room [08:33:03] DPS framework motivation [08:33:25] richard.barnes joins the room [08:33:27] came from experience of a lot of people asking for help [08:34:12] ja leaves the room [08:34:21] framework [08:34:24] richard.barnes leaves the room [08:35:38] alaind964 joins the room [08:35:40] This is a brief and early draft. Basically just an outline for a DPS right now [08:36:01] abelyang leaves the room [08:36:15] needs description of each section, outline of what should be in there [08:36:34] might be too early to be a WG document. Interested in contributions, however [08:36:35] ja joins the room [08:36:59] Roy Arends: just learned of document this morning, very interesting work [08:37:23] Need a similar policy framework; if this is accepted by WG it would be helpful [08:38:14] Ondrey [I will misspell this badly, so I'm not trying. Sorry] [08:38:22] This would be helpful if adopted [08:38:52] Mark Andrews: an end user can also be helped by standard way of establishing trust out of band. Likes it [08:39:13] Here we go: Ondřej Surý. Sorry [08:39:28] Thomas Roessler joins the room [08:40:07] New draft predicted either in two weeks, or end of September [08:40:18] Next, Alain Durand [08:40:19] alaind964 leaves the room [08:40:30] 4.4) draft-howard-isp-ip6rdns-00.txt [Alain Durand][15 min][10:30] [08:41:07] One thing I have to admit, the microphones work VERY VERY well here. [08:41:26] yeah, scarily loud when you talk into one... [08:41:53] And they are't picking up extra sounds much, just vocals. Good tech. :) [08:42:35] Things we have learned: Put your preso on a flash drive in PDF format. Let the one working laptop present it. [08:42:48] how about submit your presentation before the meeting [08:43:08] it's not rocket science [08:43:22] ...this projector appears flakier than most, though. :) [08:43:56] I seem to recall that there are problems when one uses PowerPoint for rocket science. . . [08:44:15] mgraff: did we learn this just today? [08:44:26] Alain talking about reverse DNS for ipv6 [08:44:45] current practice: prepop reverse tree w/ possibly relevant data [08:45:29] [note from Jabber scribe: I have 25 minutes of battery left, and we have more than 25 minutes of meeting, so I think I will probably disappear before things end] [08:45:32] JeremyHitchcock leaves the room [08:45:40] JeremyHitchcock joins the room [08:45:45] Alain outlines a set of bad ideas for reverse IPv6 [08:46:43] pre-populate, use wildcards, dynamic DNS & friends, reverse zone delegation, and on-the-fly synthesis [08:46:53] there are problems with each of these [08:47:35] Would like to recommend a draft that says it's ok to do nothing [08:47:51] now want a document that says some alternatives are really bad [08:48:05] wants WG to adopt document as WG doc [08:48:15] matthijs leaves the room [08:48:16] Bill Manning @ mic [08:48:32] if it's ok for DNS operator to do nothing about reverse map [08:48:36] why do it for IPv4? [08:49:07] Linus Nordberg leaves the room [08:49:11] matthijs joins the room [08:49:22] JeremyHitchcock leaves the room [08:49:24] weiler joins the room [08:49:40] what's the name of this draft? [08:49:54] http://www.ietf.org/id/draft-howard-isp-ip6rdns-00.txt [08:50:01] andrew: this wg had a document that discussed this [08:50:04] the document died in process [08:50:09] no agreement on really anything [08:50:17] there's protocols, such as IRC, that really crave reverse mappings [08:50:22] chances of getting consensus on a statement that it's ok not to do reverse v6 [08:50:28] about as good as getting consensus on the last draft [08:50:29] Cory von Wallenstein leaves the room [08:50:34] suggest that if we adopt this doc, failure will result [08:50:42] then there's protocols, such as teredo, that make reverse mappings impossible [08:50:46] Mark Andrews @ mic [08:51:00] wouter leaves the room [08:51:00] calling irc a protocol is a bit generous [08:51:09] it's out there [08:51:19] wouter joins the room [08:51:20] end sites will have more capability under v6 [08:51:25] if we specify how to do it [08:51:30] and that would be a good thing [08:51:32] DNAME might work [08:51:42] Kim Davies leaves the room [08:51:42] pawal leaves the room [08:51:48] pawal joins the room [08:51:52] Kim Davies joins the room [08:52:10] 4141 [08:52:16] missend [08:52:35] Alain: level of knowledge needed is fairly high, and does not scale to large service provider [08:52:43] mgraff runs off to rob room 4141 [08:52:52] don't want to kill reverse tree, but need document where it says "ok not to provide" [08:53:28] [notes that the reverse-mapping-conisderations document actually _said_ it's ok not to populate. We couldn't get agreement.] [08:53:40] Rob: what's the value proposition to make this happen? [08:53:52] Alain is talking about particular part of reverse tree [08:54:07] i think a draft about going through the PROs and CONs of all the alternatives would be very valuable [08:54:09] look at existing v4 practice, made up names from numeric value [08:55:39] Mark: there are applications that need this [08:55:47] not just FTP [08:55:50] SMTP needed [08:55:53] needs it [08:55:58] Cory von Wallenstein joins the room [08:56:00] ISP opening up SMTP? BS. :) [08:56:17] note the ietf.org MTA was not written in 90's and rejects mails sent over IPv6 and which don't reverse... [08:56:28] Alain: if you want the real thing, do it, but it's silly to populate the whole v6 range [08:56:38] Shane Kerr at mic [08:56:44] supports it 100% [08:56:53] doesn't share Andrew's concerns [08:57:12] wouter leaves the room [08:57:13] Chris Griffiths [08:57:16] agrees with document [08:57:42] how hard is it going to be to put in a DNS server that will answer with dynamically generated name to a query that is within certain address range (say /48) [08:57:45] there's daemon software out there that will generate ipv6 reverse mappings on the fly when they get queried [08:57:47] needs to add items that say when you do need reverse [08:57:57] Doug Otis at mic [08:58:00] That would require DNSSEC on the fly too. [08:58:01] Olafur: you beat me to it :) [08:58:13] blacklists for reverse SMTP. [08:58:16] agreed [08:58:23] DNSSEC on the fly is not hard [08:58:24] it will need DNSSEC on the fly [08:58:48] and that needs to be addressed for dynamic updates [08:59:05] you need reverse for SMTP. [08:59:10] I think new software and hardware solves on the fly approach's problem [08:59:41] Seems that there are differences between business-type customers and "dialup-like" home users. [08:59:42] Alain: can do the reverse properly [08:59:49] you also need key exchange with the parent [08:59:55]