[09:07:57] paul joins the room [09:09:58] paul leaves the room [09:15:22] paul joins the room [09:28:12] paul leaves the room: Replaced by new connection [09:28:12] paul joins the room [10:33:42] aman joins the room [10:35:50] wbeaver joins the room [10:36:07] wbeaver leaves the room [10:51:50] huguei joins the room [10:52:56] mrichardson joins the room [10:54:54] huguei leaves the room [10:55:10] scott_rose joins the room [10:55:16] hsalgado joins the room [10:55:25] Doug_Otis joins the room [10:55:58] Exodus joins the room [10:56:26] jinmei joins the room [10:56:28] Exodus leaves the room [10:56:48] seems appropriate that "Exodus left the room" [10:57:08] matthijs joins the room [10:57:13] Markkao joins the room [10:57:31] Andrew Sullivan joins the room [10:58:42] Wayne Beaver joins the room [11:00:56] fneves@jabber.registro.br joins the room [11:01:16] Starting now [11:01:22] fujiwara joins the room [11:01:26] someone say something into the mic, so that we can tell if we got a good audio connection? [11:01:46] I'm listening from home - seems to work for me [11:01:51] Andrew is speaking - audio sounds fine from here [11:02:05] persist joins the room [11:03:00] Merridew joins the room [11:03:11] fdupont joins the room [11:03:22] weiler joins the room [11:03:23] ok, audio level must be significantly lower than last session, had to double volume control.... [11:03:29] sebastian.castro joins the room [11:03:36] mgraff joins the room [11:03:42] marka joins the room [11:03:44] pawal joins the room [11:03:45] Brenden Kuerbis joins the room [11:03:51] Panagiotis.Saragiotis joins the room [11:03:51] Joe Abley will be the jabber scribe. [11:04:00] shinta joins the room [11:04:02] Wolfgang Nagele joins the room [11:04:04] tlyu joins the room [11:04:06] lgforsberg joins the room [11:04:14] wouter joins the room [11:04:20] jabley joins the room [11:04:34] andrew: first major topic [11:04:45] NYX joins the room [11:04:49] (andrew notes there will be a charter discussion later) [11:05:23] Chris joins the room [11:05:41] chairs are struggling with the projector in the traditional fashion [11:05:43] Jelte joins the room [11:05:47] TONGZHOU joins the room [11:05:51] agallant joins the room [11:06:03] Antoin joins the room [11:06:15] first up: forgery resilience discussion [11:06:20] various different techniques [11:06:34] volume is very low? [11:06:51] koji joins the room [11:06:52] Suzanne joins the room [11:07:03] ray joins the room [11:07:22] Paul: lower than at DNSOPS. Must be bigger room :) [11:07:26] Peter Koch joins the room [11:07:27] olfaur notes design team somewhat stalled [11:07:52] olafur notes proposals included dns ping, document withdrawn [11:08:00] 0x20 was withdrawn by proponent, but picked up by someone else [11:08:12] rtt banding/scattering causes fear, requires more work [11:08:59] Antony joins the room [11:09:01] olafur continues to summarise while the flashing projector makes me somewhat unable to listen to details [11:09:02] will try harder [11:09:28] tcp fallback should be avoided, say some people [11:09:41] some people alternatively claim that it can be handled with tuned stacks [11:09:44] org is surviving with lots of TCP [11:09:56] Simon Perreault joins the room [11:10:05] chairs would like guidance on two dragts in particular [11:10:19] draft-wijngaards-dnsext-resolver-side-mitigation-01 [11:10:30] draft-barwood-dnsext-fr-resolver-mitigations-08 [11:10:35] joe, can you indicate slide# if possible? thanks. [11:10:42] microphones surprisingly quiet [11:10:51] #9 [11:10:57] I cannot see the slides on the screen, and I don't have screen real estate to do open slides as well as agenda [11:10:58] sorry [11:11:13] andrew suggests that lack of comment on these drafts means they should not be adopted [11:11:16] there was some applause [11:11:36] andrew: option before the wg is not to adopt either of these [11:11:56] hoffman: I have no opinion, but I heard clapping, and I think that's unusual. might start with null option, since it sounds like it is popular [11:12:07] Andrew Sullivan leaves the room [11:12:15] Andrew Sullivan joins the room [11:12:18] olafur: you believe we should do no work on forgery resilience [11:12:24] olafur is requesting hum [11:12:25] I believe that we should deploy DNSSEC rather than band-aids. [11:12:51] kolkman: I am torn about this [11:13:01] I am not of the opinion that every idea that is documented in the current drafts are particularly good or bad [11:13:05] but this is about interop [11:13:07] that's why we are here [11:13:10] so I fall into the do neither of these things, as they won't get deployed any faster than DNSSEC, and will distract from it. [11:13:26] as implementers we try to cope by implementing methods to make the burden lighter [11:13:31] hsalgado leaves the room [11:13:38] I think we want to know from the wg are these good ideas? should we do this? or are we breaking interop? [11:13:43] paul (wouters) told me that wijngaards failed with one bank. I don't know about barwood. [11:13:50] Chris Griffiths joins the room [11:14:20] andrew: is this a statement that it seems like we should document what these techniques are? or are you suggesting that documenting them could be harmful to interop? [11:14:35] mrichardson: thats not the resilience draft? that's the resolver-mitigation draft? [11:14:52] olaf: what would be useful is to enumerate the techniques with tradeoffs [11:14:59] and the bank is just broken :P DNS without any working authorotative nameservers deserve to be broken [11:15:00] matthijs leaves the room [11:15:23] jpc joins the room [11:15:43] woolf: I agree reluctantly [11:15:45] barwood is the X20 stuff. I always thought that this was neat. [11:15:48] francisco.arias@jabber.icann.org joins the room [11:16:01] as someone who has to explain why particular ideas are good or bad, I think having documentation would be useful [11:16:21] koch: I was someone clapping their hands, but olaf gave me a hard stare, and I was frightened [11:16:35] some of these ideas are downright scary [11:16:56] I am in favour of not developing this stuff further, but at the risk of them disappearing to a different venue [11:17:02] or this wg having to declare them later to be harmful [11:17:08] if the work is to be dropped, there needs to be a written explanation [11:17:17] wouter leaves the room [11:17:35] I think we are not good at these. ...-harmful documents [11:17:41] belorn joins the room [11:17:50] if we can't agree on the advantages, surely we will not be able to agree on the downsides [11:18:10] trying to summarise what led to decisions and documenting the operational downsides of various of these ideas should be done [11:18:15] so, publish documents immediately as Historical with a WG note about why we did not adopt them. [11:18:18] wouter joins the room [11:18:19] Andrew Sullivan leaves the room [11:18:27] Andrew Sullivan joins the room [11:18:31] takasima joins the room [11:18:32] JeremyHitchcock joins the room [11:18:36] kolkman: as a process approach, you could say this is information on things that came up. they are not standard, so please do not enable them by default. [11:18:46] michael: if you need someone to speak at the mike for you, hopefully someone else can do it? [11:19:24] yeah, I hope so :-) [11:19:27] olaf: it might be that in the process of writing down those considerations, we might find one or two to which we don't object [11:19:34] michael: you should explicitly ask for someone to do that, probably [11:19:38] yes, I'm remote. [11:19:57] rob austein: explaining why he started the clapping [11:20:06] rob is concerned about the cumulative minor damage from all these whacky hacks [11:20:19] rob: strange retrofits can interact in strange ways [11:20:20] (just noticed .na (Namibia) went deployed dnssec) [11:20:35] tlyu leaves the room: Replaced by new connection [11:20:35] tlyu joins the room [11:20:38] rob: personal preferences is not to deploy any more resilience techniques [11:20:56] rob: e.g. port randomisation still causes strange fallout, and it's not just isc's code [11:21:01] rob: it's an OS issue, most generally [11:21:19] is .na in the itar yet? :) [11:21:24] rob is concerned that if we continue down the road of considering every tiny idea and implementing them all then we'll wind up with something that doesn't run [11:21:25] Antony leaves the room [11:21:26] Antony joins the room [11:21:44] manning: I have spare time opening up in september, which I could spend working on this if there is interest [11:21:49] manning: is there interest or not? [11:22:11] hama-the-sailor joins the room [11:22:33] andrew: when this discussion comes to a close, if may decide to adopt one or more documents [11:22:54] manning: I hear people saying there are way too many different things, and that we need a catalogue of all the things with discussion. [11:23:02] bill is volunteering to work on such a document [11:23:03] mgraff: no [11:23:22] Yea, I just noticed it wasn't too. Probably soon. [11:23:27] (missed name, sorry) [11:23:30] antoin? [11:23:32] Antoin [11:23:48] antoin doesn't have real opinion, except that he would like the system not to be too complex [11:24:01] antoin is also concerned that writing down ideas will give them legitimacy [11:24:28] olafur: if we write it down in a form that says "don't do this" then hopefully people won't do it [11:24:38] antoin therefore suggests bill manning, he says [11:24:51] francisco.arias@jabber.icann.org leaves the room [11:24:51] jelte: people *are* implementing these things right now, however [11:25:11] tlyu leaves the room: Disconnected [11:25:18] wes: that last point is a critical one. if people are going to implement stuff, it needs to be standardised [11:25:49] woolf: it would be fun to write a document which says do not write this document [11:25:56] tlyu joins the room [11:26:09] *cough* livingston [11:26:17] olaf/woolf: but we are talking about a document that says "don't do this, it will hurt interop" [11:26:32] koch: to follow up on olaf, less scared about interop [11:26:39] peter is more concerned about long-term operational effects [11:26:41] wouter leaves the room [11:27:10] Chris Griffiths leaves the room [11:27:20] koch: e.g. enforcing identical NS sets either side of zone cut, seems sensible but causes operational issues [11:27:22] wouter joins the room [11:27:30] andrew: so, that's an example of "don't do this, it will hurt other people?" [11:27:52] slippery slope problem? [11:28:02] hoffman: in the security area we often have documents that are about how to do this large thing, and some people have done some small optimisations on their own for whatever reason, and we found harm [11:28:07] hoffman: esp from interop [11:28:10] (especially, not ESP) [11:28:21] (see earlier large national bank with no authoritative namserver) [11:28:29] hoffman: we wound up writing text that described particular techniques and specified "do not implement" [11:29:05] andrew: I am hearing some support for a document that says here's a bunch of stuff that people have proposed, and you should/should not do these things [11:29:09] andrew: who is willing to work on this? [11:29:13] manning raises hand [11:29:21] TONGZHOU leaves the room [11:29:27] a few hands raised [11:29:56] manning: I think the document might look something that helps identify snake oil [11:30:19] Antony leaves the room [11:30:28] olaf suggests that drilling holes in manning's head might be good [11:30:42] mrichardson leaves the room [11:30:50] manning: I think what we need is a catagogue of bad ideas [11:31:05] that could be fun to write. [11:31:08] shane kerr: has been a while isnce I read these docs, but I don't recall thinking they were a list of things not to do [11:31:19] kerr: not sure how we got to the point where dnsext was all about stopping people doing things with dns [11:31:28] olaf: what I suggested is write down the various considerations [11:31:31] Antony joins the room [11:31:33] olaf: we might find good things and also bad things [11:31:37] mrichardson joins the room [11:32:08] wouldn't we have consensus that these were good ideas if they were? [11:32:11] Andrew Sullivan leaves the room [11:32:19] Andrew Sullivan joins the room [11:32:21] olaf: I want people to be able to make informed decisions when deciding whether or not to implement, or whether or not to turn on some of these features [11:32:39] TONGZHOU joins the room [11:32:52] shane: in some cases we don't know impact on interop, but I also want to say that it's ok that different implementations work differently and have different features [11:33:01] jakob joins the room [11:34:08] antoin: can sympathise with vendors who want to ship code that will be good for their customers, e.g. different pressure on recursive servers vs. authority servers [11:34:39] andrew closes the mic [11:34:39] TONGZHOU is now known as JianJin@cnnic [11:34:50] olaf: largely agrees and reiterates support for the benefits/risks document [11:35:03] andreas: I think there are several methods in these docs that are good ideas [11:35:19] andreas: I think dnsext likes to shut down proposals for default using excuses [11:36:11] andreas: I can't force the wg to adopt these docs, but would like to see the wg not active discourage work by others [11:36:26] i think most people only have one or two specific proposals in their mind during this discussion, not the whole set [11:36:39] olafur: could you send mail to namedroppers listing ideas you think are good, and why? [11:36:42] andreas: I will try [11:37:01] koch: idea is not to avoid implementation of special features by particular vendors [11:37:21] koch: dns is maintained and managed namespace which exhibits some degree of equilibrium [11:37:33] koch: worried that small changes might have unexpected consequences [11:37:43] koch: product manager vs, stability of internet [11:37:50] marco joins the room [11:38:14] andrew: questions to the wg. four options. [11:38:17] andrew: 1. do nothing. [11:38:29] andrew: 2. adopt barwood draft [11:38:41] wouter leaves the room [11:38:48] andrew: 3. adopt wouter's draft [11:39:03] Andrew Sullivan leaves the room [11:39:11] Andrew Sullivan joins the room [11:39:14] wouter joins the room [11:39:33] andrew: 4. adopt the work, merge the documents, incorporate other techniques, to make big catalogue of techniques and whether they should or should not be used [11:39:40] small hum for option 1 [11:39:48] no hum for option 2 [11:40:05] Francisco Arias joins the room [11:40:07] very small hum for option 3 [11:40:26] 4. hum. [11:40:26] obviously stronger hum for option 4 [11:40:39] there was a whole lot of not humming [11:40:39] andrew: we will get editors for this by proposal on wg [11:40:56] andrew: next topic [11:40:58] not humming = checking mail [11:40:59] andrew: edns0 [11:41:17] [projector is now working, olafur's edns0 slides are up] [11:41:26] olafur: we have appointed graff to edit edns0bis-02 [11:41:33] olafur: goal to finish this year [11:41:33] ray leaves the room [11:41:46] ipoese joins the room [11:41:59] olafur: olafur's draft on ends0 and bufsize/do was updated [11:42:20] olafur: eric, on edns0 size discovery [11:43:01] eric: work related to observed pmtu problems [11:43:09] Chris Griffiths joins the room [11:43:26] eric describes context for discussion, meaning of mtu, pmtu, etc [11:43:46] eric notes that middleboxes mean the effective useful measure is more than just the lowest mtu in the path [11:44:10] eric: problem size depends on your vantage point [11:44:16] anyone have a link to the presentation? [11:44:46] [tools.ietf.org page has links to the uploaded materials] [11:44:56] is there a draft? [11:45:15] Andrew Sullivan leaves the room [11:45:23] Andrew Sullivan joins the room [11:45:32] [andrew: are the slides uploaded?] [11:45:42] eric describes tool called dnsfunnel [11:45:44] mlepinski joins the room [11:45:50] Antony leaves the room [11:46:06] Antony joins the room [11:46:07] eric: tool tries with different buffer sizes to retrieve large RRSets (DNSKEY, I think I heard) [11:46:16] eric: tool describes timeouts, truncations, etc [11:46:19] slides: http://www.ietf.org/proceedings/75/slides/dnsext-3.pdf [11:46:33] Simon: thanks! [11:46:43] eric: end-middle-end problem [11:47:06] eric suggests no simple fix to this general problem space [11:47:32] wouter leaves the room [11:47:59] eric: edns0 buffer size != pmtu [11:48:21] wouter joins the room [11:48:41] eric: encourages people to download the tool [11:49:15] no comments at mic [11:49:22] andrew: action before the wg [11:49:52] andrew: we have a draft proposed draft-gudmundsson-dnsext-setting-ends0-do-bit-00 [11:49:57] olafur: that's going into edns0bis [11:50:00] andrew: then we do nothing, good [11:50:00] Wolfgang Nagele leaves the room [11:50:10] andrew: any more discussion on edns0? [11:50:21] [silence] [11:50:30] olafur: now we have a draft from behave, andrew is presenter [11:50:54] [the chairs are fighting with each other about whether slides were uploaded] [11:50:58] [olafur wins!] [11:51:07] andrew: this is dns64 work in behave [11:51:15] andrew: mark andrews has convinced me that there is a problem with the current draft [11:51:23] danwing joins the room [11:51:27] Andrew Sullivan leaves the room [11:51:29] andrew: I encourage you to look at this doc, since apart the marka-identified problem it's close to done [11:51:31] mrichardson leaves the room [11:51:35] Andrew Sullivan joins the room [11:51:56] mrichardson joins the room [11:51:59] andrew: text last time said "don't set the AD bit on synthesised answers" [11:52:09] or dnsext said [11:52:14] Antony leaves the room [11:52:24] andrew: got feedback saying that AD bit should be available to end node [11:52:31] Antony joins the room [11:52:45] andrew: now propose to set AD bit on validation success when commmunicating with the client [11:53:01] andrew: but this is changing the answer section, which is perilous [11:53:02] ray joins the room [11:53:12] andrew: this is not nxdomain interference, but it is answer section interference [11:53:20] andrew: if you have feedback, would like to hear it [11:53:46] the endnode should just validate itself :P [11:53:48] john: was in the behave session, but it was only lack of time that caused other people trying to raise concerns not to be heard [11:54:04] john: what do you mean by validated? dnssec-validated? or that "the lie has been validated through other means"? [11:54:11] andrew: approach is dns64 node is doing validation [11:54:27] andrew: if can't validate, does normal thing, SERVFAIL [11:54:40] andrew: if it can validate, at that point it can synthesise a AAAA from the A [11:54:50] ohh this is about dns64. never mind my comment then. [11:55:00] andrew: so the answer that the stub resolver receives is not the validated answer, but it is a synthesised answer based on a validated answer [11:55:11] andrew: signalled by AD bit [11:55:18] john: question whether it's justification or sleight of hand [11:55:44] john: does that bit mean that this is DNSSEC-validated, or are we opening the door to the idea that resolvers that act as valid can claim as valid whatever they choose? [11:55:52] olafur: we had this discussion a long time ago [11:56:03] olafur: end node can only believe the AD bit if it trusts the validator [11:56:36] rob austein: observation: AD bit is meaningless. nothing more than a debugging aid at this point. [11:56:48] And a very useful debugging aid, I often look at it when I do 'dig' at a troublesome nameserver [11:57:00] rob austein: nobody should be looking at the AD bit apart from as a debugging aid [11:57:26] sebastian.castro leaves the room [11:58:19] mrichardson leaves the room [11:58:24] run a validator on the endnode in that case [11:58:25] [andrew and rob argue about various things while I ignore them and reply to some urgent mail, done now, sorry] [11:58:45] mrichardson joins the room [11:58:52] Antony leaves the room [11:59:02] Antony joins the room [11:59:14] francis dupont: very location-dependent; mobile nodes can have bad interactions, but there is a solution: [11:59:28] francis: dns64 says you don't have to do this in the cache, you can do it in the [stub?] resolver [11:59:35] side question: a DNS64 sets the AD bit for its synthesized answer if the A answer it received from upstream validates. it does not need the negative AAAA answer to be valid. am I right? is this OK? [11:59:47] (should I take this to the mic?) [12:00:03] [if you want someone to hear it, yeah :-)] [12:00:13] (not sure it's on topic...) [12:00:15] andrew to francis: send text [12:00:31] olafur: action item, people who have seen this, take comments and send them to behave [12:00:34] sebastian.castro joins the room [12:00:36] CNNIC-ECC5CE798 joins the room [12:00:44] andrew: if you don't want to subscribe to behave, send them to me and I will forward them [12:00:59] andrew: there is also another proposal in behave that has some dns implications [12:01:08] andrew: would be useful to have participation in behave from dns people [12:01:24] [shane kerr on the stage] [12:01:33] shane: no slides, talking about draft-kerr-ixfr-only-00 [12:01:56] shane: about dns servers that multiple masters who don't always carry the same set of serials [12:02:17] shane: use IXFR from multiple masters, and not all masters have identical sets of deltas, fallback to AXFR can happen [12:02:26] Simon: on your question, good point. I think the text as it stands doesn't explicitly address that, so it should be added [12:02:31] shane: fallback to AXFR can be very bad, and trying a different master would be better [12:02:56] shane: define a new type IXFR-ONLY, similar to IXFR but with no fallback to AXFR [12:03:12] shane: some comments on the list [12:03:26] Andrew Sullivan: I sent it to the behave mailing list [12:03:34] shane: comments from jelte, suggests that if a full AXFR is small than an IXFR that it be allowed to answer an IXFR-ONLY request with an AXFR response [12:03:35] thanks [12:03:55] shane: e.g. transfer of re-signed zone with NSEC [12:04:10] shane: inclined to allow that, make that behaviour recommended [12:04:25] shane: another set of comments from ohta-san who said "you don't need this, just don't use compress ixfr option" [12:04:45] shane: don't believe that makes sense, since there's always a chance that some master will not have a complete set of deltas, don't always control your masters [12:05:00] mrichardson leaves the room [12:05:03] pawal leaves the room [12:05:10] pawal joins the room [12:05:10] shane: third, discussion on whether some knobs and controls related to IXFR-ONLY should be documented [12:05:22] shane: believe that including them in the draft is useful [12:05:26] shane: even if they are MAYs [12:05:30] mrichardson joins the room [12:05:47] Why can't you just close the TCP socket if the IXFR becomes AXFR? :) [12:05:50] maxired joins the room [12:05:53] shane: plan to upload new version, but would like to ask wg to adopt [12:06:04] olafur: wave your hands if you have read the draft [12:06:09] i ran into issues too where ixfr that failed (due to nameservers not having enough ram for two dnssec TLDs) and it caused a spiral loop of 20mbps [12:06:10] olafur sees 20 hands [12:06:22] liman: think this is a good idea, support adopting this [12:06:29] liman: consider making this an EDNS option and not a new type? [12:06:33] shane: no [12:06:39] liman: short of op types [12:06:44] olafur: to be explored later [12:07:11] liman: can see arguments both ways on chance of AXFR-fallback-if-smaller [12:07:26] liman: would be nice to allow clients to choose behaviour [12:08:08] peter koch: missed the discussion on namedroppers. but why do we need a protocol extension? why does a client not just drop the connection on an AXFR response? [12:08:09] Roy Arends joins the room [12:08:40] shane: overhead of beginning the AXFR response still exists, even if it is dropped by the client. this is a cleaner protocol option. [12:09:15] olafur plans to ask the list about various documents which might be added to the charter. requests good answers by friday. [12:09:59] olafur: requests hum in favour of ixfr-only [12:10:10] olafur: requests hum of objection [12:10:15] mild hum in favour, no hum against [12:10:38] olafur: got as far as ietf last call for new charter [12:10:58] olafur: various suggestions emerged following/during that last call [12:11:27] olafur plans to ask mailing list whether any of these ideas should be added to the current draft charter [12:11:33] [refers to four topics on the charter slide] [12:11:36] matthijs joins the room [12:11:48] maxired leaves the room [12:11:53] hoffman: because we changed the order of the agenda we don't know whether the stuff that is coming later should be added, e.g. crypto algorithms [12:12:03] olafur: crypto algorithms are already in there [12:12:16] weiler leaves the room: Replaced by new connection [12:12:16] weiler joins the room [12:12:23] liman: support the work of "write rfc guide" I fear it would require continuous updates, perhaps single rfc is not a good way [12:12:40] yao joins the room [12:12:41] PJS200 joins the room [12:12:52] seems like one has to complete DNS RFC GUIDE (at least one iteration), before one rewrites 1034/5. [12:12:55] andrew: if we're going to make a deliverable, we still need to add it to the charter [12:13:03] andrew: other options would also work, e.g. wiki vs. rfc [12:13:42] andrew: annual dns guide has been suggested [12:13:50] austein: suggests annual publication on april 4 [12:13:58] sorry, april 1 [12:14:03] wow, bad joke delivery [12:14:10] pawal leaves the room [12:14:10] JeremyHitchcock leaves the room [12:14:16] pawal joins the room [12:14:17] hta joins the room [12:14:18] JeremyHitchcock joins the room [12:14:25] liman: dns wg will not die, so let's stop trying to kill it [12:14:46] olafur: AD cannot be here, but he authorised chairs to funnel feedback to him [12:14:55] this draft should be published only on June 29. Less than 4 years of wrangling per version is un-IETFish. [12:15:04] hoffman: on the topic of annual rfcs, not done often but there's no prohibition [12:15:20] hoffman: usually ADs stamp on that ambition because of extra workload on ADs and IESG [12:15:33] hoffman: having said that, if you only have to review the diff, the workload can be small [12:15:46] hoffman: do not necessarily need a wg to keep that going, however [12:15:54] hoffman: can use AD-sponsored individual submissions [12:16:19] wes: identical discussion in ops area this morning [12:16:59] wes: they chose wiki over documents that need AD/IESG review [12:17:36] koch: I don't believe in regularly-published RFCs [12:17:47] matthijs leaves the room [12:18:33] matthijs joins the room [12:18:51] koch: how about just asking isoc to do this work for us [12:19:44] marka: I think we need to figure out which RFCs are dead [12:20:09] marka cites examples of servers that do 1034/1035 but not EDNS0, or something [12:20:19] pawal leaves the room [12:20:25] pawal joins the room [12:20:40] lixia joins the room [12:20:44] marka observes it is hard for new implementors to know what to implement, given the large amount of obsolete documentation [12:21:07] andrew: there was an effort no so long ago to produce such a set of documents, and the effort died for lack of text [12:22:37] jelte suggests that writing even more rfcs to solve the problem of there being too many rfcs is problematic [12:23:05] jelte: people in this room may be adept at solving this problem, but this should not be a wg effort [12:23:31] hoffman: agree with marka that important target audience is implementors [12:24:13] hoffman: I am willing to write this document in the form of a short list of documents and sections [12:24:21] mrichardson leaves the room [12:24:21] hama-the-sailor leaves the room [12:24:33] kerr: this is the ietf, all we have is rfcs [12:24:38] kerr: adding more text is not always bad [12:24:44] hama-the-sailor joins the room [12:24:58] kerr: e.g. adding tables of contents and indices makes a book longer yet also easier to use [12:25:26] kerr: willing to contirbute [12:25:28] mrichardson joins the room [12:25:41] andrew: action for chairs is to send revised charter which sends some of these items to the list [12:26:02] \ [12:26:29] Andrew Sullivan leaves the room [12:26:37] Andrew Sullivan joins the room [12:26:39] andrew: please hum in support of dns rfc guide, regardless of forma [12:26:39] t [12:26:45] is this a wg item, to be added to the charter? [12:26:50] matthijs leaves the room [12:26:51] strong hum for [12:26:54] no hum against [12:27:01] olafur says weak hum against [12:27:24] andrew: should it be an rfc [12:27:31] andrew: should it be something else? [12:27:37] stronger hum for something else [12:27:41] other format humm [12:27:52] matthijs joins the room [12:28:04] If it's a wiki, I forsee dueling edits. [12:28:17] Antony leaves the room [12:28:17] Antony joins the room [12:28:18] andrew: draft-li-dnsext-ipv4-ipv6-01, we have time [12:28:25] jinmei leaves the room [12:28:50] mgraff: The solution to that is the "conclave" format :) [12:29:17] li: propose idea where a client can ask for "give me an address, don't care address family" [12:29:34] li outlines advantages of such a query [12:30:18] li notes requirement for truck roll to implement such a new query, but also suggests truck roll inevitable for v6 [12:30:58] marka: always worried about metaqueries. could also completely deprecate AAAA queries, and deprecate A, and replace them both [12:31:25] ipoese leaves the room [12:31:39] who is talking?: if ns gets queried for A record, possible to return AAAA in additional, and vice versa? [12:32:37] olafur suggests document warrants further study, encourages techincal discussion on mailing list [12:32:44] kerr: hum for this? [12:32:57] andrew: how many have read this document? [12:33:13] [about 15 hands] [12:33:36] andrew: hum for this? [12:33:44] hama-the-sailor leaves the room [12:33:45] koch is excited about detailed semantics of question [12:33:58] andrew: hum for topic? [12:34:07] matthijs leaves the room [12:34:07] andrew: anti-hum for topic? [12:34:11] andrew: hum for draft? [12:34:24] andrew: anti-hum for topic? [12:34:28] hama-the-sailor joins the room [12:34:38] hum for taking on topic, tiny noise for not taking on this particular draft [12:34:45] meta-types are bad, m'kay. [12:35:04] matthijs joins the room [12:35:06] note the flag for other version addresses RR in additional section should add a NSEC* too in case there is none. [12:35:07] andrew: next and final topic, adding new dnssec algorithms [12:35:17] andrew: crocker up first [12:35:23] pawal leaves the room [12:35:29] pawal joins the room [12:35:50] And BTW it can be useful to get the list of existent RR types without trying a known to be non-existent one... [12:35:54] crocker: cycle where algorithms become deprecated and become replaced [12:36:08] crocker: how do you know when you can retire an old algorithm? [12:36:28] crocker: need to dual-sign with multiple algos until there is sufficient support [12:36:50] crocker: how to tell when dependency of old algo is low enough to pull the key? [12:37:06] crocker: proposal to allow the client to indicate algs that are understood [12:37:12] crocker: this provides basis for measurement [12:37:37] crocker: not trivial to use that information to reduce response set, since there may be intermediate nameservers [12:38:16] Doug_Otis leaves the room [12:38:22] I dislike the word 'understood' [12:38:56] AK [12:38:59] crocker: request wg adoption [12:39:13] wouter leaves the room [12:39:16] mrichardson leaves the room [12:39:49] mrichardson joins the room [12:39:51] lgforsberg leaves the room [12:39:53] Doug_Otis joins the room [12:40:24] andrew: defer wg adoption question until end of topic [12:40:34] "ack" sounds like "urgh" [12:40:59] graff: don't like the word "understood". DO causes confusion. "use" would be better, like "I would use this" rather than "I could understand this" [12:41:02] crocker: noted [12:41:05] wouter joins the room [12:41:15] olafur: next, david conrad [12:41:33] Antony leaves the room [12:41:39] Antony joins the room [12:41:40] drc: some of you might have heard, we plan to sign the root [12:41:51] drc: discussions between icann and verisign [12:42:02] drc: were thinking of suggesting that we sign the root only with RSA/SHA-256 [12:42:25] drc: reason to say this here is that it's incentive for sha-256 draft to proceed [12:42:46] drc: another reason, to get a sense of whether RSA/SHA-256 only is a good idea, at day one [12:42:52] Andrew Sullivan leaves the room [12:43:00] Andrew Sullivan joins the room [12:43:26] kolkman: guess it's a choice between SHA-1 and SHA-256 [12:43:39] kolkman: so long that there is software available I don't see a big problem [12:43:42] wouter, is SHA-256 code deployed? [12:43:47] matthijs leaves the room [12:44:08] kolkman: what drawback do you see? [12:44:13] drc: there are no bugs, only opportunities [12:44:22] Does RSA/SHA-256 even have an algorithm code? [12:44:26] kerr: I think it's better to do this now when there's no installed base, instead of doing a migration later [12:44:41] matthijs joins the room [12:44:43] jelte: proposing to use something for which the draft is not even four years old? [12:44:44] mic volunteer please: if there is any concern that SHA-256 is not currently deployed everywhere, then I would propose: sign with SHA-1, and then ROLLOVER to SHA-256. Consider it a test of rollover of the root!!!! [12:44:46] [laughter] [12:45:00] jelte: concerned about deployment [12:45:36] not so much deployment, more that the draft hasn't been proven to interoperate [12:45:43] i'll get it [12:45:44] question of whether there are vendors whose long software lifecycles might be incompatible with the timeline for signing the root [12:45:50] drc: we will discuss with microsoft [12:46:08] roy: what's wrong with SHA-1? why not roll over to SHA-256 later? [12:46:38] drc: thought that SHA-1 had been deprecated in certain governmental environments [12:46:50] drc: from my perspective doesn't make sense to deploy something that has a question, since we're just starting now [12:46:56] drc: but are looking for input [12:47:18] weiler for michael richardson: if there is concern about sha-256 implementation, do sha-1 then roll to sha-256, benefit is key rollover experience [12:47:29] in certain governmental environments SHA-1 has never been appreciated [12:47:30] "better is the enemy of good enough". deploy with SHA-1. Do it now. [12:47:31] olafur: let's take this to the list unless you have a crypto comment [12:47:58] hoffman: there is no problem with sha-1 right now. operational challenge with rollover, maybe. there is no crypto problem with using sha-1 to sign the root. [12:48:09] tlyu leaves the room: Disconnected [12:48:14] andrew: we are closing the mics [12:48:17] matthijs leaves the room [12:48:26] andrew: please take these comments to the list [12:48:30] tlyu joins the room [12:48:57] olafur: dnssec parameter registrations [12:49:08] Andrew Sullivan leaves the room [12:49:10] NYX leaves the room [12:49:12] sebastian.castro leaves the room [12:49:16] Andrew Sullivan joins the room [12:49:20] olafur: people ahve been asking that the requirements for adding new parameters be relaxed from the current "standards action" [12:49:37] olafur: seems ok to relax requirements as you gain experience [12:49:43] olafur: three options [12:49:47] olafur: current one, standards action [12:49:51] olafur: next, rfc publication [12:50:03] olafur: first come first serve [12:50:21] olafur: also question of required/optional [12:50:21] hama-the-sailor leaves the room [12:50:43] jinmei joins the room [12:50:58] hama-the-sailor joins the room [12:51:46] Doug_Otis leaves the room [12:51:47] olafur: possible paths forward: do nothing, commission document to implement revised approach, or do more thinking [12:51:59] queue for new hash algorithms is quite deep [12:52:33] hoffman observes that many hash algorithms listed on "BUT" slide were available earlier [12:52:55] olafur and hoffman have a bit of a semantic cage match going on [12:53:12] john and olafur are having a cage match about slide versions [12:53:21] olafur wins! [12:53:24] because he is on stage [12:53:48] olafur: goal is to identify criteria for evaluating new submissions [12:54:08] olafur: concerned about stability of internet with flood of new algorithms [12:54:56] did not catch name: have experienced serious problems with expert review process in enum, suggest caution if plan involves expert review [12:54:58] who is this? [12:55:04] Alex Mayrhofer [12:55:09] Antony leaves the room [12:55:15] Antony joins the room [12:55:23] Andrew Sullivan leaves the room [12:55:31] Andrew Sullivan joins the room [12:55:38] wes: 4 major categories (dnskey, ds, nsec, tsig). Running out of time. Can suggest new approach rather than dealing with it today [12:55:48] wouter leaves the room [12:56:01] wes: suggest find someone who is prepared to write up i-d with pros and cons that we can discuss in japan [12:56:07] olafur: or on the list [12:56:18] wes confirms that he was not volunteering [12:56:24] wouter joins the room [12:56:34] jinmei leaves the room [12:56:34] steve kent: two problems. one is if you register new algorithms, what's the implication in terms of support? [12:56:44] mrichardson leaves the room [12:56:50] steve kent: suggest two suites at any one time, a current and a next [12:57:18] steve kent: mandating support of all algorithms is not reasonable, too much cost for implemnetors [12:57:44] note that every addition to nsec3 obfuscation will add a dnskey algorithm number for every dnskey algorithm that is still in use [12:58:07] steve kent: if concern is lack of bits to number the algorithms, then makes sense to review to avoid parameter registries filling up [12:58:18] steve kent: could use crypto security rg in the irtf for expert review [12:58:20] all of the assignment policies for these registries assume sparse demand [12:58:46] unless they are stronlgy coupled (only use nsec3-myhash with myhash-signing and vice versa) [12:58:56] hoffman: I volunteer to be the document author for the how do we move this forward, quick response to steve, cfrg was consulted before and there was not much feedback [12:59:31] andrew: objection to steve's draft, since both chairs report to steve [12:59:41] andrew: have asked paf to assist [12:59:56] andrew: how many people have read algo-signal? [13:00:06] jelte: i proposed that a long time ago, I think. [13:00:10] I counted about 15-20 hands [13:00:23] andrew: hum for adoption (small hum) [13:00:31] andrew: hum for non-adoption (larger hum) [13:00:45] andrew: speaking for myself, that sounded like an even heat [13:00:50] [andrew is central, I am on one side of the room] [13:00:59] andrew calls for hands for review, some hands [13:01:19] andrew: that was all information for paf [13:01:31] steve: offers to stop being an author [13:01:33] JeremyHitchcock leaves the room [13:01:37] andrew: doesn't matter, paf has offered to be an arbiter [13:01:37] Andrew Sullivan leaves the room [13:01:38] mlepinski leaves the room [13:01:41] JeremyHitchcock joins the room [13:01:43] sam: this is actually what i really don't like about my own draft :p [13:01:45] Andrew Sullivan joins the room [13:01:45] andrew: over time by one minute, paf coming up for a second [13:01:57] paf: I heard a slight majority for adopting the doc [13:02:01] PJS200 leaves the room [13:02:03] paf: would like to talk to people who have opinions [13:02:06] wouter leaves the room [13:02:06] jelte: which draft? [13:02:09] [paf is on the other side of the room from me :-)] [13:02:12] Panagiotis.Saragiotis leaves the room [13:02:15] Suzanne leaves the room [13:02:24] tlyu leaves the room [13:02:36] olafur: have not decided whether to meet in hiroshima [13:02:42] koji leaves the room [13:02:43] olafur: but we will send mail two months before [13:02:45] jakob leaves the room [13:02:46] weiler leaves the room [13:02:48] lixia leaves the room [13:02:48] meeting ends [13:02:48] ray leaves the room [13:02:52] jabley leaves the room [13:02:54] hama-the-sailor leaves the room [13:02:55] Chris Griffiths leaves the room [13:02:57] fneves@jabber.registro.br leaves the room [13:02:58] Markkao leaves the room [13:02:58] danwing leaves the room [13:02:59] belorn leaves the room [13:03:02] Wayne Beaver leaves the room [13:03:06] yao leaves the room [13:03:06] Peter Koch leaves the room: Computer went to sleep [13:03:09] agallant leaves the room: Logged out [13:03:14] Francisco Arias leaves the room [13:03:14] persist leaves the room [13:03:15] Roy Arends leaves the room [13:03:17] Merridew leaves the room: QIP Infium: Спокойное общение [13:03:20] Antoin leaves the room [13:03:31] Chris leaves the room [13:03:37] scott_rose leaves the room [13:03:37] shinta leaves the room [13:03:44] Simon Perreault leaves the room [13:03:53] hta leaves the room [13:04:02] Jelte leaves the room [13:04:38] pawal leaves the room [13:05:18] Brenden Kuerbis leaves the room [13:05:47] takasima leaves the room [13:05:55] CNNIC-ECC5CE798 leaves the room [13:06:15] fdupont leaves the room [13:06:33] jinmei joins the room [13:06:38] Andrew Sullivan leaves the room [13:07:01] jinmei leaves the room [13:07:46] JeremyHitchcock leaves the room [13:10:22] Wolfgang Nagele joins the room [13:10:50] Wolfgang Nagele leaves the room [13:11:02] JianJin@cnnic leaves the room [13:11:23] TONGZHOU joins the room [13:11:29] jabley joins the room [13:12:03] TONGZHOU leaves the room [13:17:49] Roy Arends joins the room [13:19:37] jpc leaves the room [13:21:43] Brenden Kuerbis joins the room [13:24:07] fujiwara leaves the room [13:25:07] Brenden Kuerbis leaves the room [13:25:34] jabley leaves the room [13:27:57] pawal joins the room [13:29:48] pawal leaves the room [13:29:48] pawal joins the room [13:37:19] pawal leaves the room [13:38:38] hta joins the room [13:40:00] hta leaves the room [13:42:01] aman leaves the room [13:43:26] danny joins the room [13:44:30] anyone know which is the audio stream? [13:44:55] marco leaves the room [13:47:25] it's the large stage [13:59:25] paul leaves the room [14:00:13] mgraff leaves the room [14:01:38] Chris joins the room [14:01:44] Chris leaves the room [14:10:46] Antony leaves the room [14:17:59] JeremyHitchcock joins the room [14:33:31] Brenden Kuerbis joins the room [14:37:02] Doug_Otis joins the room [14:38:42] Doug_Otis leaves the room [14:48:57] JeremyHitchcock leaves the room [14:49:55] Brenden Kuerbis leaves the room [14:49:57] marka leaves the room [15:10:25] danny leaves the room [15:52:21] Chris Griffiths joins the room [15:52:33] Chris Griffiths leaves the room [16:05:48] Brenden Kuerbis joins the room [16:10:54] Peter Koch joins the room [16:58:03] Brenden Kuerbis leaves the room: Replaced by new connection [16:58:05] Brenden Kuerbis joins the room [17:05:01] Peter Koch leaves the room [17:48:54] Brenden Kuerbis leaves the room [18:29:01] Peter Koch joins the room [18:46:44] Peter Koch leaves the room [20:26:36] shinta joins the room [20:26:57] shinta leaves the room