[08:52:14] --- shigeya has joined
[08:56:31] --- wouter has joined
[09:25:28] --- Jelte has joined
[09:30:37] --- yone has joined
[09:43:16] --- wouter has left
[09:44:06] --- wouter has joined
[09:44:35] --- SteveC has joined
[09:46:18] --- jtk has joined
[09:48:04] --- Marcos has joined
[09:49:36] --- eludom has joined
[09:49:36] --- eludom has left: Lost connection
[09:52:39] --- eludom has joined
[09:53:24] * eludom has changed the subject to: Working group session about to start
[09:54:19] --- Suz has joined
[09:54:49] --- ggm has joined
[09:55:57] <ggm> http://www3.ietf.org/proceedings/07jul/agenda/dnsop.txt
[09:57:14] --- FDupont has joined
[09:57:37] --- secastro has joined
[09:59:01] --- rhe has joined
[09:59:01] --- itojun has joined
[09:59:39] --- mjo has joined
[09:59:55] --- jaap has joined
[10:00:17] <Jelte> can we do a sound check? i hear peter murmuring but that doesn't say much about the quality :)
[10:00:36] <jaap> Dit goed?
[10:00:39] <ggm> he has just spoken. how was that?
[10:00:44] <Jelte> oh wow
[10:00:49] <Jelte> great sound
[10:00:52] <shigeya> yep.
[10:00:57] <Jelte> thanks
[10:00:58] <wouter> works_for_me
[10:01:13] <Jelte> bit of a delay apparently :)
[10:01:29] <ggm> rtt estimation by jabber is never good
[10:01:47] <Jelte> :)
[10:02:18] <Jelte> BOF next IETF? rtt estimation methods using multiple protocols?
[10:03:12] --- dblacka has joined
[10:03:17] --- mg has joined
[10:03:20] --- iljitsch has joined
[10:03:23] --- pawal has joined
[10:04:09] --- dudisaki has joined
[10:04:13] <jaap> Introduction by Peter
[10:04:47] <jaap> Agenda bashing, no important changes
[10:05:21] --- marka has joined
[10:05:46] <jaap> RFCS 4892 (NISD) is pibliced
[10:05:58] --- aalain has joined
[10:06:25] --- shinta has joined
[10:06:38] <jaap> huston-6t04-draft-reverse-dns-07.txt in IESG (4 DISCUSSes)
[10:07:42] <jaap> main problem in IESG: new ADs have don't know history and security concerns
[10:07:59] --- liman has joined
[10:08:10] --- johani@jabber.org has joined
[10:08:19] <jaap> reflctors are evil passed WGLC and is waiting for PROTO write up & nits
[10:09:13] <jaap> ddnsop-default zones, WGLC done, awaitong update
[10:09:33] --- bruce has joined
[10:09:48] <jaap> BTW: Agenda on http://tools.ietf.org/wg/dnsop/agenda?item=agenda69.html
[10:10:00] <jaap> (so I don;t need to retype everything)
[10:10:17] <jaap> responsize in last call
[10:10:31] <jaap> as112 under attack under WGLC
[10:10:35] --- liman has left
[10:10:44] <jaap> Over to list of active drafts
[10:10:47] --- Rickard has joined
[10:10:54] --- liman has joined
[10:10:57] <jaap> as112-ops, revesred-mapping
[10:12:01] <jaap> Joe Abley about as 112 work basket
[10:12:19] <jaap> drafts...-as112-ops-00
[10:12:47] <jaap> there ar editorial suggestions, some unix centrisme
[10:13:06] --- ogud has joined
[10:13:14] --- arifumi has joined
[10:13:20] <jaap> Joe suggest 01 version before WGLC
[10:13:26] --- RussMundy has joined
[10:14:12] <jaap> Extendding AS112. suggestions made in Prague:IPv6 transport for current zones
[10:14:45] <jaap> Should AS112 serve othet zones as well?
[10:15:33] <jaap> (see also dnsop-default-local-zones-draft
[10:16:45] <jaap> ???: ii is not only transport
[10:17:00] --- yone has left
[10:17:07] --- yone has joined
[10:17:12] <Marcos> ??? = Akira Kato
[10:17:29] --- fujiwara has joined
[10:17:59] <jaap> Marka; which I dcannot hear myself
[10:18:11] <bruce> Mark Andrews: v6 transport is a non-issue (ie, not all v4 instances need to have v6 transport)
[10:18:18] <bruce> (paraphrased)
[10:20:02] <jaap> stephne borzmeier: Let's do current praqctice first before throwing in new stuff
[10:20:22] <jaap> Joe Abley: Was not suggesting to put all in current draft
[10:20:28] --- fenton has joined
[10:21:45] <jaap> Mark was also wondering about new zones, Liman agues that at first there is hardly traffic but later on thi might be more.
[10:21:53] <jaap> Peter: discussed in Prague
[10:22:21] --- juampe has joined
[10:22:37] <jaap> Joe: Suggestion was made to do that in a following document updating first
[10:23:19] <jaap> Peter: does this work need review in other group?
[10:23:35] <jaap> JJoe: will act on that
[10:24:19] <jaap> 32.2 on agenda: Andrew Sullivan: reverse mapping-considerations
[10:25:21] <jaap> lists major changes from 02-03 (see http://tools.ietf.org/wg/dnsop/agenda?item=agenda69.html) for details
[10:25:57] <Marcos> http://www3.ietf.org/proceedings/07jul/slides/dnsop-0.pdf for details
[10:28:06] --- Antoin has joined
[10:30:59] <jaap> Andrew list questions to the WG (see URL)
[10:31:02] --- onakayu has joined
[10:31:40] <Jelte> some Postfix setups block incoming smtp from hosts without a reverse dns entry (it's a config option)
[10:32:24] <jaap> Peter: Any comments on questions?
[10:33:16] <jaap> Matt Larson: Whatever we do, people will complain about the burden to operators
[10:33:31] <jaap> Matt: doesn;t think 1788 is relevant
[10:34:04] <jaap> Austein: Dean asked the right question. Should deans draft be accepted?
[10:34:42] <jaap> nobody who read the draft (15) wants it adapted (numbers from Peter Koch)
[10:35:31] <jaap> Stéphane B: BCP 030 is old and doesn't cover current practices
[10:37:22] <jaap> Andrews doesn't want to refer to everything possible, asspecially policy docs about spam might be in a flux.
[10:37:40] <jaap> Peter: anyne really in favor? Counts 1 hand
[10:37:59] <jaap> Andrew will propose text for history section\
[10:39:23] --- aalain has left
[10:39:37] <ggm> Kato san agenda item 3.3, referral response sizes.
[10:40:02] --- keith has joined
[10:40:06] <ggm> Kato: thanks for comments, will take to WGLC end of august
[10:40:30] <ggm> http://tools.ietf.org/html?draft=draft-ietf-dnsop-respsize-07 (no slides)
[10:41:21] <ggm> draft relates to large response behaviour. discusses the issues of non-EDNS0. up to 1/3 of observed resps show this.
[10:41:58] <ggm> emerging problems. firewalls stripping responses > 512.
[10:42:21] <ggm> seeks support for inclusion in doc to address
[10:42:39] <ggm> iljitsch: confirm 1/3
[10:43:02] <ggm> kato: yes. trace capture, this jan, 1hr, other statistics, JP dns server, see slightly more than 1/2
[10:43:23] <ggm> Iljitsch. saw earlier this year, 80% EDNS0 enabled in regular production. very different figure
[10:43:58] <ggm> Iljitsch. people rejecting >512. they shouldn't do it. if we work around, gives licence. object against work-around. if enable EDNS0 but then reject. either don't do EDNS0 or don't reject
[10:44:34] <ggm> Kato: EDNSO varies by environment/server/country. want to make sure ratio is not 100%, defines problem exists
[10:45:31] <ggm> Jim Reid: to pick up on EDNSO. have draft in ENUM wg, relating to this and NAPTR. suggest split in two. one for impls, with MUST about devices, also operational guidelines, respecting middleware boxes. mobile phone cpys dropping TCP query. maybe roll into this draft, find out who takes care. will chat.
[10:45:49] --- Marcos has left
[10:45:50] --- Marcos has joined
[10:45:54] <ggm> Peter: is this a formal coming across from ENUM WG?
[10:46:10] <ggm> Jim: from area. AD considers draft needs split. part should come from other than ENUM wg
[10:46:32] <ggm> Rob Austein. Q to Grp. this is an old draft (respsize) heard comments, going back years "finish already"
[10:46:47] <ggm> Q is, do we want to do anything we absolutly don't have to? get this one out? hum
[10:46:59] <ggm> hum add other stuff
[10:47:12] <ggm> sorry hum "further exploring space, including new issues"
[10:47:21] <ggm> mostly pref the first choice: cut this one
[10:47:36] <ggm> Peter K. try again.
[10:48:09] <ggm> what understood from Kato, Jim, seen in wild, have issue of EDNS0 deployment. ENUM stumbles over this issue. usually IETF, bad in saying 'thou shalt' everywhere.
[10:48:44] <ggm> OTOH, incouraging EDNS0 throughout DNS world, (sidethrow to now-dormant DNSEXT) what are appropriate prot elems to support today?
[10:49:13] <ggm> Personal op. seeing non EDNS0 q in wild, in busy TLD spaces, need for document, irrespective of EDNS0. that said, ask Q.
[10:49:40] <ggm> Olafur. EDNS0 should not be added to THIS draft. maybe statement "could make it go away" does no harm. I think draft is done. minor changes.
[10:49:51] <ggm> Get it out ASAP.
[10:50:07] <ggm> major undertaking to write should/must draft. needs to be done. not this vehicle
[10:50:40] <ggm> Jim. agree with Olafur. lets get this done, out, if need re-visit issues, other profile factors, op practice statements, new work item, separate draft. if in this draft only reference.
[10:51:24] <ggm> Peter. two ways to go. add statement to Kato but minimally, be done with it, no normatives. other options discuss EDNS, middleboxes, dive in.
[10:51:38] <ggm> Jim don't do it with this draft
[10:51:50] <ggm> Q1. in favour of this draft, minor editorial change. hum
[10:51:52] <ggm> [hums]
[10:52:17] <ggm> Q2 like to have this discussion, in this draft.
[10:52:19] <ggm> [some]
[10:52:24] <ggm> Olafur. going to repeat to ML?
[10:52:41] <bruce> 'of course'
[10:53:11] --- eludom has left: Disconnected.
[10:53:16] <bruce> hum in favour of the draft (just to complete the point)
[10:53:19] <ggm> item 3.4. resolver priming. Peter Koch not-as-chare
[10:53:27] <ggm> chair
[10:53:38] <ggm> http://tools.ietf.org/html?draft=draft-ietf-dnsop-resolver-priming-00
[10:53:58] <ggm> more or less copy of original submission, additions for TTL.
[10:54:27] <ggm> coming soon: quad-A in root. v6 only can resolve from top down.
[10:54:34] <ggm> turns out priming process has no BCP
[10:55:49] <ggm> consideration: DNSSEC validation of root servers in priming response?
[10:56:49] --- iljitsch has left
[10:56:51] <ggm> additional info: glue isn't signed. additional info in header same. but editors think this is worth exploring
[10:57:17] <ggm> RObA. Question. why special case? this is just a question. why any different to ordinary resolution, would do dnssec if could do dnssec. whats the magic making it a Q?
[10:57:30] <ggm> Peter. point is, starts at top. trick resolver on startup, then ..
[10:57:31] --- jad has joined
[10:57:37] <ggm> RobA but I don't see how thats different.
[10:57:48] <ggm> MarkA. part of problem is 'net isn't signed' in terms of global internet
[10:57:53] <Jelte> in an utopian world; when there is dnssec everywhere; you'd detect the root server divert as soon as you query them, even if you don't dnssec-validate the priming answer
[10:58:12] <ggm> to verify current servers under root-servers.net. need net signed to have Trust Chain. or two sets of TAs
[10:58:18] <ggm> Peter. giving response to Q down the track.
[10:58:34] <ggm> We're coming to that. basic Q is do we want trust chain or not? then, seek solutions
[10:58:36] --- hotta has joined
[10:58:53] <ggm> Mark at moment, add section WILL have sigs, if .net/servers.net are signed. they aren't glue in this case.
[10:59:08] <ggm> pulling answers out of root-servers.net zone will have testable sigs, so additional will have
[10:59:17] <ggm> this is not a referral response.
[10:59:22] <ggm> Peter not sure I understand your point
[10:59:53] <ggm> Mark glue may be signatureless, but these answers are not glue
[11:00:29] --- SteveC has left
[11:00:32] <ggm> Peter by operational habit, all rootservers authoritative. NS record set comes out of rootzone authoritatively. adrs pick from rootservers.net. if signed, will be attached, will be in additional, PROVIDED, that when you ask, you set DNSSEC ok bit.
[11:00:48] <ggm> still, don;t have full trust chain. Q is, do we expect whole trust chain to be avilable? if yes, how to get there?
[11:01:01] <ggm> abstract from current root-servers.net, situation
[11:01:40] <ggm> RobA, for purposes of discussion, assume all heavy lifting done. if so, I'm not sure what the issue is. So .. explain
[11:01:44] <ggm> Mark. I think there is no issue.
[11:01:53] --- RussMundy has left
[11:02:07] <ggm> Peter. WG says 'no problem' then I'm not nervous
[11:02:21] <ggm> ROb no, not saying no problem, saying 'no magic' -its not different to any other problem
[11:02:27] --- juampe has left
[11:02:42] --- juampe has joined
[11:02:55] <ggm> Peter this is ground statement, do we expect the bit to be set, do we want to prime the response?
[11:03:40] <ggm> RobA. spoofing issue. is that it? but, can still spoof non-DNSSEC.
[11:03:59] <Jelte> it's a DOS whether you check it or not if everything would be dnssec
[11:04:11] <ggm> Olaf.
[11:04:15] <ggm> (Kolkmann)
[11:04:31] <ggm> the attack happens, tallking to rogue auth rootserver. that NS hands me out bad things. I have dnssec, I can catch
[11:04:36] <Jelte> and if it is checked; you'd DOS dnssec servers, and spoof all others
[11:04:48] <ggm> what you possibly would protect is non-dnssec signed data.
[11:05:03] <ggm> besides, I see a circular dependency I haven't wrapped my mind around
[11:05:17] <ggm> and there is a meta-Q. what is special about the root zone from protocol?
[11:05:25] <ggm> I don't think even priming response should be a special case
[11:05:49] <ggm> Peter. this is a philosophical Q. no unique delegation. comes out of union of all hints files in the world, as long as they agree
[11:05:51] <Jelte> but you are kind of moving the problem to root key management (which has to be solved for dnssec anyway)
[11:05:57] <ggm> Olaf. trust anchor configuration.
[11:06:08] <ggm> Jelte: if you want things said at mike, please say so and somebody in room will say
[11:06:21] <Jelte> well olaf pretty much said all my points :)
[11:06:37] <ggm> Olafur, does it make sense? if not, ask again. Rsolver should not depend on this. dont see this as special case. can make recommend, but leave at that. not mandate
[11:06:45] <ggm> Peter different consideration
[11:06:51] <ggm> dont assume current setup
[11:07:21] <ggm> Bruce will this increase the adoption of DNSSEC?
[11:07:25] <ggm> Rob suspect its neutral
[11:07:56] <ggm> Rob I think I hear "there is no magic here" sense of room? [hum seems to agree]
[11:08:05] <ggm> RObA asks if priming query magic, no hums
[11:08:19] <ggm> Peter doesn't really answer my Q yet.
[11:08:26] <ggm> so it doesn't cause harm to validate?
[11:08:47] <ggm> RobA I agree it doesnt cause harm. the decision to do DNSSEC at validation here is no different to deciding to do it anywher eelse
[11:09:14] <ggm> I think the way the Q is phrased is flawed
[11:56:21] --- LOGGING STARTED
[11:57:05] --- jaeyoun has joined
[11:57:10] --- jaeyoun has left
[11:57:29] --- Jaeyoun Kim has joined
[11:58:53] --- dhankins has joined
[11:58:57] --- dhankins has left
[11:59:22] --- lixia has joined
[11:59:39] --- lixia has left
[12:00:15] --- jhlim has joined
[12:00:19] --- dhankins has joined
[12:01:15] --- jhlim has left
[12:02:01] --- liman has joined
[12:02:29] --- Joonhyung Lim has joined
[12:02:29] --- liman has left
[12:03:57] --- Joonhyung Lim has left
[12:04:53] --- ogud has joined
[12:05:04] --- jhlim has joined
[12:05:47] --- ggm has joined
[12:06:07] <ggm> now on DNS management
[12:07:17] <ggm> have done anycast node requirements, DNS2DB and Nominet proposed 'name server control protocol'
[12:07:27] <ggm> (since jabber went haywire)
[12:07:59] <ggm> compiling list of volunteers to review management options.
[12:08:52] --- Antoin has joined
[12:09:04] --- bhoeneis has joined
[12:09:07] --- Suz has joined
[12:09:12] <ggm> Peter. done.
[12:09:45] <ggm> 7) I/O with other WG chairs.
[12:10:43] <ggm> Olafur addresses status of dnsext
[12:11:09] --- shinta has joined
[12:12:44] --- FDupont has joined
[12:14:12] --- dudisaki has joined
[12:15:19] --- FDupont has left
[12:15:23] --- yone has joined
[12:15:44] <ggm> Ed. how to get Quad-A glue into a TLD.
[12:16:04] <ggm> why haven't people been able to just do these kind of things? need to look out for these kind of things, document
[12:16:12] --- FDupont has joined
[12:16:27] <ggm> Peter. suggesting we do outreach?
[12:16:40] <ggm> Ed. want to think about it. want to hear ideas about operational criticisms about how DNS is.
[12:17:10] --- jad has joined
[12:17:29] --- jad has left
[12:17:49] <ggm> Mark A. no more edits due on my draft.
[12:18:34] <ggm> Peter: AOB?
[12:18:38] <ggm> then we close 10 minutes early
[12:18:45] --- FDupont has left
[12:18:51] --- jhlim has left
[12:18:53] --- ogud has left
[12:18:53] --- ggm has left
[12:18:55] --- shinta has left
[12:19:00] --- dhankins has left
[12:19:34] --- Antoin has left
[12:21:37] --- yone has left
[12:23:50] --- marka has joined
[12:24:31] --- Suz has left
[12:26:34] --- bhoeneis has left
[12:45:53] --- marka has left
[12:49:47] --- Jaeyoun Kim has left: Replaced by new connection
[12:50:53] --- Jaeyoun Kim has joined
[12:52:58] --- Jaeyoun Kim has left
[13:07:27] --- dudisaki has left
[13:53:48] --- mjo has joined
[13:54:27] --- mjo has left
[14:14:44] --- jaap has joined
[14:17:04] --- jaap has left
[14:56:47] --- Rickard has joined
[15:01:01] --- Rickard has left
[20:40:31] --- guonian has joined
[20:42:49] --- guonian has left
[21:02:19] --- sunguonian has joined
[21:28:46] --- sunguonian has left