[06:52:18] MAP joins the room [08:01:24] MAP leaves the room [08:52:33] MAP joins the room [08:53:28] MAP leaves the room [10:24:41] Jelte joins the room [10:53:10] Ralf Weber joins the room [11:09:26] Danny joins the room [11:28:59] Ralf Weber leaves the room [11:36:17] OatWillie joins the room [11:36:24] hi kids [11:36:44] is the audio working today? [11:38:17] the wetf web site is "unavailable" ... [11:45:36] Antoin joins the room [11:47:11] trjh joins the room [11:56:18] i hear some murmuring on audio, so it appears to work [11:56:21] fdupont joins the room [11:56:28] mohsen joins the room [11:56:33] Shall I shout ? [11:56:57] yeah say hi to me :) [11:57:12] Do you hear the music ? [11:57:21] yes [11:57:30] than it seems fine.. [11:57:44] starting time in 120sec? [11:57:48] starting in a few minutes, no chairs are up yet... [11:57:48] sohgo joins the room [12:00:37] Chairs are installing themselves... [12:01:16] something about missing scribes [12:01:16] stephen.morris joins the room [12:01:36] psavola joins the room [12:01:43] marcos joins the room [12:01:56] stephen.morris leaves the room [12:02:11] Suz joins the room [12:03:02] Jim Galvin joins the room [12:03:12] koji joins the room [12:03:27] Joao joins the room [12:03:35] nishida joins the room [12:03:53] Think that's solved now.. [12:04:14] fneves joins the room [12:05:33] yone joins the room [12:05:46] narooter joins the room [12:06:05] five minutes late [12:06:08] Chair greeting [12:06:52] liman joins the room [12:07:01] All slides of today to be found under https://datatracker.ietf.org/meeting/72/materials.html [12:07:23] Any remote participants? [12:07:25] stephen.morris joins the room [12:07:26] Andrew Sullivan joins the room [12:07:29] yes [12:07:34] dblacka joins the room [12:07:35] ogud: Olafur Gudmundsson joins the room [12:07:37] Steve Crocker joins the room [12:07:38] pawal joins the room [12:07:40] edmon joins the room [12:07:47] good. Comments for the mic, please with "MIC:" prepended [12:07:54] how many people here are actually in the room? [12:08:15] キレイ joins the room [12:08:24] keith joins the room [12:08:40] Agenda bashing. Agender under http://www.ietf.org/proceedings/08jul/agenda/dnsop.txt [12:09:09] Jim Galvin leaves the room [12:09:09] swshin92 joins the room [12:09:18] fujiwara joins the room [12:09:32] changes to the mailing list. may need to answer to challenge email before post is approved. [12:09:38] The agenda in the materials page is slightly outdated [12:09:52] No changes to the agenda wished. Agenda approved. [12:10:16] Document status: reflectors-are-evil [12:10:25] galvinjamesm joins the room [12:10:25] one or two remaining discusses in AD followup [12:11:09] there appears to be 1 issue that P. Hoffman raised which needs to be further discussed [12:11:28] P. Hoffman: if somebody is waiting for my input, tell me [12:11:54] R. Bonica: Attempt to clear the discuss [12:11:57] (he is the AD) [12:12:07] PK: Hope for progress [12:12:14] Documents Status, past WGLC: [12:12:38] local-zones-05 and mapping-considerations-06, awaiting for proto write-up and WGLC summary, respectively [12:12:50] akoba joins the room [12:13:01] bc joins the room [12:13:03] PK: AD has encouraged him to move forward [12:13:22] Charter: remaining issue is "Performance and Measurement", overlap with pmol and bmwg working groups [12:13:47] Issues potentially arising by this overlap will be clarified and dealt with [12:13:54] psavola leaves the room [12:14:05] Advantage ist that both wgs are co-chaired by the same person [12:14:09] psavola joins the room [12:14:11] Document status, awaiting WGLC: [12:14:29] respsize-11 (was expired), as112-ops and as112-under-attack [12:14:47] No input when asked for important issues [12:15:07] Active WG drafts: two of them: dnssec-trust-anchor-02 [12:15:23] M. Larson: they wanted a LC in april [12:15:38] M. Larson: all comments thought to be addressed now in 02 [12:15:45] M.L: Let's go for LC [12:15:59] M.Larson: When? [12:16:12] R. Austein: Real Soon Now [12:16:35] The other doc is resolver-priming-01, editorial changes, incorporated feedback, identified issues [12:16:42] PK: How many have read? [12:17:19] audio has gone away [12:17:33] 10-ish have read [12:17:37] (hopefully audio is back) [12:17:38] thanks for the mic [12:17:59] Q: will respsize be revived? [12:18:06] yoshfuji joins the room [12:18:08] explicitly removed from the draft: DNSSEC validation with priming response [12:18:17] OatWillie: yes, it has been [12:18:30] Priming: Changes, should not expect 13 NS RRs [12:18:56] Q: same authors for respsize? [12:19:04] Another change: recommendation for a notification of changes in names or addresses [12:19:13] No comments from the room [12:19:23] OatW.: Dunno, check the I-D too ;-) [12:19:34] More Priming issues: [12:19:44] OatWillie: I don't believe so [12:20:24] PK reading slide 14 [12:20:31] mc joins the room [12:20:45] galvinjamesm leaves the room [12:20:51] PK: respsize deals directly w/ this (size) issue [12:21:27] Liman: what is the underlying reason for the need of specification? [12:21:46] PK: consistency [12:22:08] PK: if the wg says this can remain open, he removes that from the doc [12:22:19] Liman: Prefer avoid specifying that [12:22:49] Liman: doesn't want to be tight to a recommendation that eventually doesn't work in real life [12:22:54] s/tight/tied/ [12:23:11] i like Limans thinking [12:23:19] A recommendation for A or AAAA will be premature or outdated [12:23:34] yoshfuji leaves the room: Replaced by new connection [12:23:34] stephen.morris leaves the room [12:23:35] fneves leaves the room [12:23:49] yoshfuji joins the room [12:23:57] what about just some discussion about the pros/cons? [12:24:08] fneves joins the room [12:24:28] mention possible reasons to do one or the other and possible operational results? [12:24:39] Jelte: is that for the mic? [12:24:44] Liman: Ask the root nameservers, they have the addresses. that's the best strategy [12:24:48] if you think it's worth it :) [12:25:01] Jim Galvin joins the room [12:25:25] actually - given the flexable nature of v4/v6 transition, casting preference in an RFC might be a hinderence in future [12:25:26] Jaap: probably better to have a mix [12:26:01] Jaap: he prefers a recommendation (?) [12:26:49] Stephane: just make a reference to draft respsize [12:27:05] St: it already ellaborates on the topic [12:27:13] Jim Galvin leaves the room: Replaced by new connection [12:27:13] galvinjamesm joins the room [12:27:18] PK: Situation here is special [12:27:24] oawillie: the side comment in the draft is the key, 'EDNS0 is used as an indication of AAAA understanding on the side of the client'. if they've got an upgraded nameserver, they probably understand ipv6. [12:27:37] PK: Courtesy vs necessary information has to be addressed [12:28:20] St: doesn't think there is a big difference between priming and regular request [12:28:28] (that would be realting to the second question in the slide) [12:28:58] R. Austein: Fallback rules for EDNS0 are important [12:29:32] R. Austein: it will be a larger issue [12:29:56] A. Sullivan: should talk about tradeoffs and pros vs cons [12:30:49] thanks andrew [12:30:55] PK: hope we can get a consensus, instead of just listing tradeoffs w/o recommendation [12:31:41] M. Andrews: a lot of this has to do with bad behaviour in Bind 9 [12:31:45] Bind8, I mean [12:31:47] PK: if we list options, better ensure that the timestamp is done. e.g. all the options as seen in 2008 [12:32:17] If you want to keep Bind 88 working, you have to prefer AAAAs [12:33:25] PK: Speaking of bad behavior, after becoming the first priming response, you could already start resolution behaviour [12:33:33] we don't want to keep BIND8 working. It's been eol'd. [12:33:33] Ted Lemon joins the room [12:33:52] (sorry, I can't hear Mark clearly) [12:34:17] "we" might want to keep bind 8 working, regardless of ISC's commitment to the code. [12:34:37] PK: What should we do with incomplete priming responses? [12:34:58] PK: Closely realted: can we assume all roots to be authoritative for the root names? [12:35:17] M. Larson: Yes, that is the intent [12:35:30] M. Larson: The nonly exception is trying to be fixed [12:37:35] onakayu joins the room [12:38:09] Brian Dickson: should not have a consistent expectation on ALL roots. Maybe some EDNS0, some not [12:38:45] i am -not- happy w/ having divergent capabilities in a suite of authoritative servers. strikes me as a very bad idea [12:38:57] WPM01906 joins the room [12:39:34] OatWillie: it seems to me some people have that today. Or do you mean in the suite of authoritative servers at the root? [12:39:44] especially if different anycast instances would behave differently [12:39:53] Jelte: yes, exactly [12:40:29] Liman: L is the exception for the authortative behaviour on root server names, which is being tried to be fixed [12:41:10] PK: More priming issues. Given recent developments, should teh doc suggest reconsideration of DNSSEC validation of priming response? [12:41:17] i think PK had it right... it (lack of consistancy) is a protocol violation [12:41:27] if not, why set the DO in the priming query? [12:41:32] Leave it completetly? [12:42:27] Mark: we do set DO [12:43:19] andrew: if you chose to serve different data from authoritave servers in a suite, thats your business, but it confuses the heck out the clients and makes troubleshooting hell. i think the underlying presumption is that all auth servers as visible to all clients, which is false [12:43:28] Stephane B.: priming request MUST be don with UDP? What's the rationale for that in the doc? [12:43:52] PK: Efficient [12:43:59] Stephane: Security problem (poisoning) [12:44:22] PK: you probably would like to see DNSSEC validation of the priming response [12:44:31] Jyrki.Soini joins the room [12:44:32] St: Alternatively, TCP first, UDP after [12:44:36] OatWillie: the protocol explicitly allows different data from different authoritative servers [12:44:46] PK: Making friends with root server operators? [12:44:54] PK. More issues: [12:45:09] in a zone that changes a lot [12:45:10] TTLs of A/AAAA/NS to be equal? [12:45:13] andrew: chapter and verse please [12:45:18] you will have differences from different servers, no? [12:45:26] after priming without dnssec and being forged, every query should fail anyway [12:45:36] iff root is signed etcetcetc [12:45:43] Put this in the draft under IANA considerations? [12:46:13] Liman: not the right place, beacuse not all root servers are handled by IANA [12:46:32] PK: Still could put it there, document politics. [12:46:48] Liman: Remember private root. Aligning is a good thing. [12:46:50] narooter leaves the room: Computer went to sleep [12:47:07] Liman: DNSSEC may be an issue [12:48:02] PK: Depending on implementations, TTLs might be different when coming from root-servers.net or the root zone [12:48:14] Mark: they should come from the root-servers.net [12:48:23] Mark: Non issue [12:48:34] Mark: Fix the implementations that don't follow the specs [12:48:38] PK suggests to move this offline [12:49:03] PK: Any other comments? [12:49:16] jelte: I doubt that thats the case; if the attacker intercepts the priming query, they can control everything from then on. [12:49:32] Next on the Agenda: REPORT OF THE DCOMA DESIGN REPORT TEAM [12:49:46] draft-hardaker-dnsops-name-server-management-reqs-03 [12:49:59] yes but if you have dnssec and a signed root they can only dos you [12:50:06] http://www3.ietf.org/proceedings/08jul/slides/dnsop-1.pdf [12:50:16] it would be better to know right at priming but it wouldn't be absolutely necessary [12:50:21] Presentation made by Wes. [12:50:32] in name of the whole DCOMA team [12:51:07] shinta joins the room [12:51:31] These are only high level requirements [12:52:16] Work spanning from July 2007 to May 2008 [12:53:20] The draft does not appear in the IDs lsit of the Wg because of an spurious s in the name of the draft [12:53:28] But the name will be kept to keep history of the draft [12:53:45] Benno Overeinder joins the room [12:54:29] Wes: Who has read it? [12:54:35] About 5-10 ppl [12:54:39] rgaglian@ietf72 joins the room [12:54:55] Deployment requirements [12:55:05] MUST support all sizes of zones [12:55:19] MAY support ns discovery [12:55:46] (cf. universities, where you don't know the network you are working in) [12:55:53] snicker... all sizes... (where is Ed?...) anyone care to define the smallest zone construct? [12:55:54] MUST support static and highly dynamic zones [12:56:11] (e.g. TLDs to 1-10 record zones) [12:56:36] Protocol requirements [12:56:45] SHOULD use a minimal set of protocols in the solution [12:56:59] MUST supply a common data model [12:57:00] Thingy joins the room [12:57:23] MUST minimize impact [12:57:33] Requirements to server types [12:57:43] SHOULD support master, slave and recursive servers [12:57:49] out of scope: stub resolvers [12:58:04] it could be useful for stub resolvers, but that is beyond the scope a priori [12:58:28] management Operations divided in control, configuration, monitoring and alarms/events [12:58:32] Control Requirements: [12:58:41] MUST support basic service control operations [12:58:58] (restart, reload the conf, reload the zone, start and stop) [12:59:13] should support this minimal operations [12:59:25] Reqs about zone data: [12:59:38] should modify served zone list (add/modify/deletE) [12:59:54] (dynamic dns is acceptable solution) [13:00:10] Benno Overeinder leaves the room [13:00:11] should be able to manage a list of DNSSEC TAs [13:00:16] Benno Overeinder joins the room [13:00:22] should be able to manage TSIG keys [13:00:41] Should be able to mange DNS protocol auth (dynamic dns, recursion, access lists) [13:00:51] Monitoring reqs: [13:01:14] Ed Lewis: Lot of security items here [13:01:21] jpc joins the room [13:01:34] Wes: yes, we sepparated the security aspects in the draft [13:01:37] pawal leaves the room [13:02:04] some requirements are specific for recursive servers, and some are fot authoritative servers. does (or should?) the document separate these (in sections? maybe even in separate docs?) [13:02:05] Carsten St.: able to manage AND validate the data? [13:02:11] s/fot/for/ [13:02:23] PK: Completeness of the reqs, please at the end of the presentation [13:03:31] S. Crocker: related to DNSSEC, sepparation of content management of zone and key management [13:03:37] S. Crocker: supported? [13:04:00] wes: it shoudl be supported [13:04:11] Wes: Personally I agree it should be supported [13:04:20] Monitoring reqs: [13:04:28] MUST be able to monitor the health of the ns [13:04:51] (e.g. number of requests, responses, performance, status, access control violations, top 10 clients...) [13:05:01] (thosw would be "nice to have" monitoring tasks) [13:05:35] This expensive calculations could have impact on existing deployment [13:05:45] Reqs to Alarm/events: [13:05:50] Should support delivery of alarm conditions [13:06:12] top X clients [13:06:17] Benno Overeinder leaves the room [13:06:22] Benno Overeinder joins the room [13:06:25] (e.g. status change, resource exhaustion, auth violation and wes' favourites "lonely warning" (I never got a request)) [13:06:30] Security reqs: [13:06:36] MUST support mutual auth [13:06:51] (doesn't prohibit TSIG) [13:06:59] MUST support integrity and confidentiality [13:07:14] SHOULD provide fine-grained auth [13:07:38] MUST minimize security risks [13:07:56] Reqs about extensibility [13:08:17] MUST be flexible to accomodate future needs, allow vendor extensions, prvide extension identification and protect against namespace collision [13:08:38] What should happen with the doc now? Become RFC? [13:09:11] end of presentation [13:09:35] Jaap at the mic [13:10:21] nest steps proposal [13:10:41] make reqs draft wg work item and expect one more round before LC [13:10:52] Disband the design team and start protocol work [13:11:02] akoba leaves the room: Replaced by new connection [13:11:07] yone leaves the room: Replaced by new connection [13:11:17] yone joins the room [13:11:41] Mabye a new design team is necessary to start proto work [13:12:16] R. Austein: we feel the design team has done their job [13:12:19] Applause [13:12:24] Benno Overeinder leaves the room [13:12:30] Benno Overeinder joins the room [13:13:00] PK: how many read the latest version? [13:13:01] should this document even become an rfc? or should the wg just start the actual work based on this? [13:13:03] 5-10 reviewers [13:13:15] use it as a basis [13:13:19] Jelte: is that for the mic? [13:13:25] PK: this is over the 5 reviewers threshold [13:13:29] if you like, again :) [13:13:48] PK: Is this a useful draft to continue work on in this wg? [13:13:53] i am not to fond of requirements docs as rfcs, but that might be personal [13:13:59] s/to/too/ [13:14:36] R. Austein: We want a stable reference, a reqs doc must be an RFC, too [13:15:17] The point about hand-off is a reasonable one, when the work is going to another WG [13:15:33] yes [13:15:59] M. Souissi: usage of SHOULD+ keywords like RRFC4307 already does? [13:16:12] M. Souissi: 2119 might be unsufficient [13:17:00] P. Hoffman: don't do should+, it's way down the line (as an author of the idea) [13:17:31] J. Schinzlein: Thank the design team for the effort. Must become an RFC [13:18:19] R. Arends: Request to the Chairs for a Hum for adoption [13:19:02] R. Austein: 20-ish people would read future versions of the doc for review [13:19:04] Hum request [13:19:09] Unanimously for adopting [13:19:15] no hum against [13:19:16] hum (for) [13:19:23] Adopted [13:19:27] (thanks Jelte) [13:19:54] Marcos: that was not unanimity. Just nobody against :-) [13:20:14] (thanks, mr democracy expert) [13:20:16] And a very strong hum FOR [13:20:38] NEXT PRESENTATION: RVEIW OF RFC 4641 [13:20:48] P. Hoffman at the mic [13:21:05] Why do a review? 4 reasons [13:21:18] http://www.ietf.org/proceedings/08jul/slides/dnsop-2.pdf [13:21:43] We've learnt stuff, bad criptography in it, key rollovers has no justification in it, and it mixes a discussion of publishing trust anchors and keys in a signed parent zone [13:22:11] VH joins the room [13:22:17] Paul himself doesn't want to write, btw, the possible work, he's not a dnsop [13:22:18] VH leaves the room [13:23:36] onakayu leaves the room [13:23:37] R. Austein: Thje security directorate was asked for advice with this doc and we got flooded with advice [13:24:03] Joonhyun Lim joins the room [13:24:16] P. Hoffman: however, size choices is mostly handwaving without analysis [13:24:23] he would like to update that [13:25:06] Key rollover is misunderstood and without justifications [13:25:34] should start with security threats, decissions on how much defense is needed and then take decissions on rollover times/sizes [13:26:17] publishing trust anchors is different than publishing child keys [13:27:25] So, next steps? [13:27:33] See if the wg cares [13:27:51] O. Kolkman, doc editor: he is prepared to hold the pen for followup [13:28:06] p.h. did -NOT- point out one thing that was made very clear to me several years ago on these topics... key strength, rollover intervals, etc depend very much on: how often the zone changes and where in the heirarchy the zone cut sits. [13:28:20] Olaf: He thinks all issues or worth discussing, not necessarily agree with Paul's view [13:28:51] Olaf: a bCP stamp on that is not the wisest path, because still in flux if you consider deployment of DNSSEC [13:29:54] yes there are definite problems re: key rollover, i'll send a message to ops about that [13:30:00] S. Crocker: maybe other issues that you haven't mentioned [13:30:18] PaulWouters joins the room [13:30:48] S. Crocker: we have to deal with TAs, we should treat TAs and TARs as an intermediate necessary step [13:31:01] Benno Overeinder leaves the room [13:31:06] Benno Overeinder joins the room [13:31:18] PH: root is signed is a special case of Trust Anchor [13:31:37] S.Crocker: Yes, we should work on this as a wg [13:31:47] S.Crocker: TAs & TARs are -NOT- intermediate... they are nearly a permanent feature [13:32:11] Olaf: you always have to treat your KSK as a TA, this has to be taken into consideration [13:32:32] agree w/ Olaf here [13:32:35] pawal joins the room [13:32:41] (thanks, Oat) [13:33:17] Wes: hard to make a decission on whether we want to work on this. [13:33:33] Wes: you are saying "we may want to change things" [13:34:04] Olaf: propose to treat the current doc as a draft and start working on it [13:34:43] PK: thanks for usuing outcome of the wg as input for the RSTEP analysis of the PIR DNSSEC proposal, that's a success for us [13:35:05] PK: want to avoid battle of cryptogeeks on the floor of dnssec [13:35:11] *applause* [13:35:36] (btw; nice work on the rstep doc, it was good) [13:36:21] PaulWouters leaves the room [13:37:14] NEXT PRESENTATION: NON-AVailability of dynamic updates, J. Abley [13:37:32] jabley-dnsop-missing-mname-00 [13:37:33] http://www.ietf.org/proceedings/08jul/slides/dnsop-3.pdf [13:37:37] PaulWouters joins the room [13:37:54] Primary use of MNAME is for DU to find a server to find an update to [13:37:58] to find/to send [13:38:10] for many zones, never desirable to receive dns updat etraffic [13:38:30] proposal: specify an empty MNAME field in zones which do not welcome DNS UPDATE traffic [13:38:39] there is no current mechanism to do that [13:39:01] Empty field is menat to be just a dot "." [13:39:10] He's tried in a couple of implementations and it works [13:39:18] We have now to move the clients to interpret that [13:39:31] Possible impact: "." A queries to the root? [13:39:45] i think they get those queries anyway :) [13:39:57] Alternatively, do nothing or consciously specify a fall guy (prisoner.iana.org?) [13:40:00] joe.A: i've used a URL... [13:40:09] last question: should wg adopt this? [13:40:21] R.Austein: Not necessarily a dnsop item, subtel distinction [13:40:26] an url as mname? [13:40:33] R. Austein: because we are changing the semantics of a field [13:40:33] yup [13:40:45] Joe: Adjusting semantics to operational convention [13:41:04] is that accepted by parsers? [13:41:05] Mark: Broken update clients, they are not supposed to use MNAME [13:41:26] Mark: they shoudl use NS RRset [13:41:45] oh right with escapes [13:41:47] it was when i tested it... (bind 8, bind 9.3.2) ... but I haven't used stock bind in years.. [13:42:01] rgaglian@ietf72 leaves the room [13:42:05] cute :) [13:42:14] url? [13:42:15] R. Ausein: send a REFUSED? [13:42:17] i heard a dot [13:42:40] PK, no hats: a real problem, d not support adoption of this, it is premature [13:42:49] a URL instead of "." would be moderately different [13:43:04] less traffic to the roots [13:43:08] Benno Overeinder leaves the room [13:43:10] PK: rather describe the problem and make recommendations on how to get rid of unsocliited updates [13:43:10] +1 what peter said [13:43:13] Benno Overeinder joins the room [13:43:17] Steve Crocker leaves the room [13:43:18] you can always set it such that the update traffic never hits your network. [13:43:18] nishida leaves the room [13:43:23] Steve Crocker joins the room [13:43:26] well if they ever get an .html tld it might receive some traffic :) [13:43:38] as the behaviour that mark andrews describes isn't the case in practice :( [13:43:41] Wes: percentage measurements on how much you get hitted by that? [13:43:41] PaulWouters leaves the room [13:43:47] R. Austein: there is a public study somewhere [13:43:48] http://localhost/ [13:43:59] :) [13:44:28] Jim Reid: (I didn't hear that clearly) [13:44:32] why not just localhost.? [13:44:46] jim reid suggested putting MNAME to localhost. [13:44:49] nishida joins the room [13:44:50] Olafur G: thanks for bringing this up, hsould originate discussion [13:45:22] you know, this could be something that as112 takes on [13:45:25] PK: Sense of the wg on this? a) problem exists shoudl be addressed? b) go on with this document? c) oppose to either/don't care [13:45:38] Rob: First hum, is this a problem? [13:45:38] bc: that's one of Joe's options in his slides [13:45:56] ah, the fall guy one. [13:45:58] PaulWouters joins the room [13:46:00] Big hum for "this is a problem to be solved" [13:46:05] Next one, about this doc: [13:46:55] can i hum 'meh'? [13:47:08] A. Sullivan: even if this is a protocol change rather than operational convention, [13:47:10] localhost. is not yet a valid TLD altho ::1 might work [13:47:21] A. Sullivan: this doc has to be adopted [13:47:49] jelte: like a sheep? :p [13:48:28] Olafur: Request for the dnsop to host the discussion on the political jurisdiction problem [13:48:29] has to be adopted or what? death from above? [13:49:04] PK: IS this wg wiling to have this discussion here? (about the jurisdiciton of the problem) [13:49:08] so, they're having a discussion on whether to have a discussion on the document.... [13:49:14] Hum for yes [13:49:15] Benno Overeinder leaves the room [13:49:20] Benno Overeinder joins the room [13:49:27] (Very) Small hum against it [13:49:45] Mark: this wg already decided NOT to implement this decission [13:49:57] Mark: he was forced to remove "." from ?? [13:50:08] R. Austein: Please not this discussion now [13:50:14] from the local zones [13:50:15] NEXT PRESENTATION [13:50:30] EDNS0 support in auth servers on 27 july [13:50:36] OatWille: Whatever you put in there, it's going to be looked up as a DNS name. This is all just broken client implenetation. Fixing it with operational practice is not the right way forward ... [13:50:38] we agreed on discussing the possible solutions to the problem, not to adopt the document [13:50:40] http://www.ietf.org/proceedings/08jul/slides/dnsop-4.pdf [13:50:46] [13:52:15] liman: yes i know... parsing // as a DNS label was an interesting exercise [13:54:20] is that "Servers" or "domains served" in the numbers? [13:54:33] Is that a question for the mic? [13:54:41] no it is okay. [13:54:55] 'servers' is used in the draft [13:55:01] just pointing out to the room the numbers can be widely different [13:55:13] for domains broken vs servers broken [13:55:26] servers, if i understood an earlier slide [13:55:28] G. Michaelson: skeptic [13:55:38] Ggm: you went to authoritative,s to sources [13:55:58] Ggm: I see at delegation point significant lower numbers [13:56:39] R. Austein: EDNS capable clients may not need to do fallback anymore [13:56:51] Ggm: That's true. Good work. [13:57:15] Ed Lewis: you are measuring against servers, not domains [13:57:26] (that answers PaulW question) [13:57:35] how much of that tentative conclusion (maybe fallback isn't needed) is wishful thinking because no fallback would make a LOT of things a lot easier? [13:57:37] Joe: yes, we plan to do the toher, as well [13:57:50] Jyrki.Soini leaves the room [13:57:56] Wes: numbers before or after certain announcement? [13:57:58] Joe: After [13:58:22] Olafur: Cool [13:58:43] Olafur: you hit regular nameservers, and not Loadbalanced et al which are more of a problem [13:58:47] the tentative conclusion is based on tentative results [13:58:48] so [13:58:52] and are there any recent counts on broken firewalls dropping 512+ byte dns messages [13:59:04] ah olafur asks kind of the same thing [13:59:18] jelte: firewalls come into play on the client side, not the server side (which this is). [13:59:30] well, unless they've got a broken setup. [13:59:36] nishida leaves the room [13:59:44] actually i'm looking at this from the protocol-extension side [13:59:46] Jim R.; analysis on recursive resolver servers would be interesting [13:59:51] Benno Overeinder leaves the room [13:59:53] which is was it really is about imho [13:59:57] Benno Overeinder joins the room [13:59:59] Steve Crocker leaves the room [14:00:02] Steve Crocker joins the room [14:00:06] joe: plan to do some testing that way [14:00:11] koji leaves the room [14:00:26] keith leaves the room [14:01:09] Thingy leaves the room [14:01:11] Shane: We asked for "example.com" and some of the servers might have the behaviour of not answering that [14:01:12] just to add something about home users... http://iis.se/docs/Routertester_en.pdf [14:01:14] PaulWouters leaves the room [14:01:19] Shane: next time, other domains [14:01:25] dblacka leaves the room [14:01:32] yeah i've read that [14:01:33] dblacka joins the room [14:01:34] PK: Running out of time [14:01:43] rgaglian@ietf72 joins the room [14:01:53] PK: We will skip the discussion on distributeddns-04 [14:02:11] PK: DNS AAA synthesis is a hot topic in v6ops. Heads UP! [14:02:20] WPM01906 leaves the room [14:02:21] PK: AOB? [14:02:23] dblacka leaves the room [14:02:27] Thanks to everybody! [14:02:29] Joao leaves the room [14:02:30] We are done! [14:02:32] Adjourn! [14:02:33] Andrew Sullivan leaves the room [14:02:34] キレイ leaves the room [14:02:36] fdupont leaves the room: Computer went to sleep [14:02:36] yoshfuji leaves the room [14:02:37] See you in Minneapolis [14:02:37] thanks chairs [14:02:37] fneves leaves the room [14:02:39] Antoin leaves the room [14:02:41] Benno Overeinder leaves the room [14:02:42] swshin92 leaves the room [14:02:42] and jabber scribe/mike people [14:02:45] pawal leaves the room [14:02:51] Steve Crocker leaves the room [14:02:53] Ted Lemon leaves the room [14:02:59] See you soon, Jelte [14:03:02] bye! [14:03:06] ttfn [14:03:12] OatWillie leaves the room [14:03:13] cya [14:03:24] shinta leaves the room: Computer went to sleep [14:03:39] sohgo leaves the room [14:04:26] PaulWouters joins the room [14:04:30] marcos leaves the room [14:05:02] mc leaves the room [14:06:01] psavola leaves the room [14:06:43] bc leaves the room [14:07:36] Jelte leaves the room [14:08:28] キレイ joins the room [14:08:39] mohsen leaves the room: Computer went to sleep [14:09:04] liman leaves the room: Computer went to sleep [14:09:13] キレイ leaves the room [14:13:56] Suz leaves the room [14:17:28] yone leaves the room: Replaced by new connection [14:17:34] ogud: Olafur Gudmundsson leaves the room: Replaced by new connection [14:21:20] edmon leaves the room [14:21:28] galvinjamesm leaves the room [14:24:45] mohsen joins the room [14:25:50] Joonhyun Lim leaves the room [14:26:10] mohsen leaves the room [14:28:41] rgaglian@ietf72 leaves the room [14:29:01] jpc leaves the room [14:33:42] pawal joins the room [14:34:39] Jyrki.Soini joins the room [14:35:04] Jyrki.Soini leaves the room [14:51:34] Danny leaves the room: Replaced by new connection [14:51:34] pawal leaves the room [14:51:34] PaulWouters leaves the room [14:51:35] Danny joins the room [14:54:13] swshin92 joins the room [15:16:08] Danny leaves the room: Replaced by new connection [15:16:09] Danny joins the room [15:21:48] swshin92 leaves the room [15:28:15] Danny leaves the room: Replaced by new connection [15:28:15] Danny joins the room [15:31:28] Danny leaves the room: Replaced by new connection [15:31:28] Danny joins the room [15:59:44] fdupont joins the room [15:59:44] trjh leaves the room [16:13:31] fdupont leaves the room: Computer went to sleep [16:29:30] fujiwara leaves the room [16:57:54] jpc joins the room [16:57:54] Danny leaves the room [17:05:03] Danny joins the room [18:01:29] Danny leaves the room [18:18:06] Danny joins the room [18:54:16] Danny leaves the room: Replaced by new connection [18:54:16] Danny joins the room [19:10:35] jpc leaves the room [20:08:48] Danny leaves the room: Replaced by new connection [20:08:48] Danny joins the room [21:58:32] Danny leaves the room