[12:47:55] --- ogud has joined
[12:48:15] --- marka has joined
[12:49:14] --- explorer has joined
[12:49:19] <explorer> Hmm, ok, so I can :)
[12:51:07] --- marka has left
[12:51:31] --- explorer has left
[12:51:32] --- mgraff has joined
[12:51:34] --- mgraff has left
[14:26:31] --- suresh_k@jabber.org has joined
[14:27:08] --- suresh_k@jabber.org has left
[14:40:06] --- ogud has left
[15:05:39] --- paulwouters@jabber.org has joined
[15:21:39] --- ogud has joined
[15:22:13] --- ogud has left: Replaced by new connection
[15:29:17] --- lindy has joined
[15:30:21] --- lindy has left
[15:32:42] --- rstory has joined
[16:19:51] --- ogud has joined
[16:52:01] --- Thierry has joined
[17:04:10] --- ogud has left
[17:07:07] --- mgraff has joined
[17:07:19] --- mgraff has left
[17:24:25] --- oatwillie has joined
[17:30:45] --- Jelte has joined
[17:31:50] <Jelte> hello
[17:32:06] <paulwouters@jabber.org> hey Jelte
[17:32:24] <paulwouters@jabber.org> fixed ldns yet? :)
[17:34:01] <Jelte> was it broken? :) there's a new patch release about ready
[17:36:57] <Jelte> the audio feed of the harbor island II room is abysmal
[17:40:15] <oatwillie> there is a feed that is useful?
[17:41:45] <paulwouters@jabber.org> the audio was good when i listened to it.
[17:41:52] <paulwouters@jabber.org> perhaps it gets better when they start
[17:42:30] <paulwouters@jabber.org> oh yeah. notw it is really bad
[17:42:59] <oatwillie> i'm not getting anything
[17:43:24] <paulwouters@jabber.org> go via http://videolab.uoregon.edu/events/ietf/ietf67-local.m3u
[17:44:09] <oatwillie> ok... the link i ended up @ was/is http://videolab.uoregon.edu/events/ietf/ietf671.m3u
[17:44:47] <paulwouters@jabber.org> sounds just as awful
[17:45:39] <oatwillie> i'm getting nothing on either link... the big quicktime w/ ??
[17:46:11] <paulwouters@jabber.org> i am using OSX.
[17:46:20] <paulwouters@jabber.org> with itunes. it just works
[17:46:56] <Jelte> ubuntu with totem plays it fine too
[17:47:06] <Jelte> apart from the quality that is :)
[17:52:12] <paulwouters@jabber.org> jelte: no nsd-2.x to nsd-3.x conversion script yet?
[17:52:46] <paulwouters@jabber.org> I should package nsd-3 for Fedora Extras, but I'm kinda nervous about breaking nsd-2 servers.
[17:53:47] <Jelte> no :/
[18:03:24] --- rlegene has joined
[18:04:06] <rlegene> what time is it in San Diego now?
[18:04:15] <oatwillie> 15:05
[18:04:22] <rlegene> Thank you.
[18:04:38] <paulwouters@jabber.org> i really hope they will fix channel 1 before dnsext meeting
[18:04:52] <oatwillie> did anyone report it to Joel?
[18:05:13] <paulwouters@jabber.org> not me?
[18:05:53] --- jakob@kirei.se has joined
[18:06:23] --- dblacka has joined
[18:06:39] --- rlegene has left
[18:06:39] --- robert @ dk has joined
[18:06:39] --- jakob@kirei.se has left
[18:06:59] --- jakob has joined
[18:07:27] --- robert @ dk is now known as robert@dk-hostmaster.dk
[18:10:51] <paulwouters@jabber.org> blech. audio in this room is still very borken
[18:11:07] <robert@dk-hostmaster.dk> oh maybe they are very quiet
[18:11:28] <dblacka> or, nowhere near the microphone
[18:11:39] <paulwouters@jabber.org> no. it is the same static as when the previous talk was still going
[18:12:03] <paulwouters@jabber.org> dkim on channel7 worked fine this morning
[18:12:12] <oatwillie> sigh
[18:12:32] <robert@dk-hostmaster.dk> The audio website says :
[18:12:33] <robert@dk-hostmaster.dk> NOTES 2006 Nov 11 Audio on Channel 1 and 7 are noisy. We are not able to resolve this problem.
[18:12:36] <oatwillie> anyone local that can go beat the NOC?
[18:12:46] <robert@dk-hostmaster.dk> (november 11???)
[18:13:01] <oatwillie> the ietf does time travel
[18:13:26] <robert@dk-hostmaster.dk> well, there should be engineers present
[18:13:46] <robert@dk-hostmaster.dk> funny how we can run the internet but never get a good audio feed.
[18:13:56] <robert@dk-hostmaster.dk> of course - people using the mikes will help :)
[18:14:18] --- scott_rose has joined
[18:14:29] --- ggm has joined
[18:14:40] --- shigeya has joined
[18:14:41] --- fneves has joined
[18:14:51] --- robert@dk-hostmaster.dk is now known as robert@dk-hostmaster.dk_remoteparticipant
[18:14:57] --- asullivan has joined
[18:15:03] --- Antoin has joined
[18:15:07] --- ggm has left
[18:16:04] --- Jim Galvin has joined
[18:17:14] --- msj has joined
[18:17:30] --- hotta has joined
[18:18:12] --- wouter has joined
[18:20:18] --- otmar has joined
[18:20:51] --- glozano has joined
[18:21:29] --- marcos has joined
[18:21:54] --- healthyao has joined
[18:22:08] --- stevecrocker@jabber.shinkuro.com has joined
[18:22:22] <paulwouters@jabber.org> well, the quality is very very poor :(
[18:22:22] --- Jaeyoun Kim (KRNIC, NIDA) has joined
[18:22:29] <Jelte> well that was understandable through the noise :p
[18:22:35] <paulwouters@jabber.org> barely
[18:22:52] --- liman has joined
[18:23:25] --- mrichardson has joined
[18:23:38] --- fujiwara has joined
[18:23:38] <mrichardson> hi.
[18:23:42] <jakob> perhaps someone can close the doors back...
[18:23:46] --- ggm has joined
[18:24:00] <ggm> Doc status
[18:24:13] --- marka has joined
[18:24:19] <ggm> wildcard clarify, tsig, dhcid RFCs all out
[18:24:27] <ggm> MDNS is in RFC-ED Q
[18:24:58] <ggm> next 2 months expectd to complete. thanks to all, esp. AD
[18:25:05] <ggm> Docs advancing.
[18:25:17] <ggm> NSID nameserver ID option. in IANA state.
[18:25:28] --- raj has joined
[18:25:29] <ggm> requested registry missing. working with IANA to get that fixed
[18:25:49] <ggm> waiting for server-id requrements doc. not yet with IESG. so blocked until advances
[18:25:55] <ggm> time to nuke the chairs in the other group
[18:26:00] --- koji has joined
[18:26:13] <ggm> dnssec experiments in [discuss] state. Olaf working with AD, shepards.
[18:26:16] <ggm> resolving soon
[18:26:19] <ggm> [this is Olafur speaking btw]
[18:26:25] --- pk has joined
[18:26:34] <ggm> OPT-IN is going to RFC-ED. normative ref in Experiment.
[18:26:39] <ggm> could be out before next meeting.
[18:26:54] --- mgraff has joined
[18:27:03] <ggm> DNSKEY, RRSIG use of SHA-256,
[18:27:13] --- bhoeneis has joined
[18:27:15] --- mo7sen has joined
[18:27:16] <ggm> talked in Vancouver. chairs asked "want to work on it?"
[18:27:23] <ggm> feedback was "not much interest"
[18:27:34] <ggm> officially advancing to "almost dead" state. off-track now
[18:27:35] --- johani@autonomica.se has joined
[18:27:41] <ggm> Last Calls
[18:28:02] <Jelte> i am still willing to restart work on it when interest resurfaces :p
[18:28:19] <ggm> most of the docs have some issues, going to require updates. DSA keying, Diffie-Helmann, Rollover, Transition mech, RFC2929bis
[18:28:24] <ggm> [if you want stuff said, say so]
[18:29:06] --- Suz has joined
[18:29:08] --- johani@autonomica.se has left: Logged out
[18:29:12] <ggm> [Olaf] good time to ask, any Qs about docs in discussion?
[18:29:27] <ggm> WG Documents.
[18:29:31] <ggm> Sam Weiler:
[18:29:45] <ggm> is 2929bis on agenda later or only now?
[18:29:47] <paulwouters@jabber.org> (and if you are not very clear, we really can't hear it)
[18:29:48] <ggm> Olafur not on agenda
[18:29:51] <Jelte> please speak *very* clearly there is a *lot* of noise
[18:29:59] <ggm> I will advice in a 'mo
[18:30:08] <ggm> Can we do the template informally? no need to re-rev the doc?
[18:30:15] <ggm> Olafur will take under advicement
[18:30:26] <Jelte> sam here is a good example of totally not understandable :)
[18:30:35] <ggm> message sent.
[18:30:40] <Jelte> thanks
[18:30:48] <robert@dk-hostmaster.dk_remoteparticipant> Jelte: You mean because of the mike?
[18:30:50] <ggm> Olafur attempting to repeat Sams msg
[18:31:00] --- weiler has joined
[18:31:23] <ggm> 2672bis, DNAME clarification document.
[18:31:32] <ggm> Wouter speaking.
[18:31:54] --- jad has joined
[18:31:57] --- Doug Barton has joined
[18:32:07] <Jelte> well there is a lot of static noise, and maybe the mic too (i can hear the chairs, but that's about it :) )
[18:32:19] <ggm> background on DNAME briefly, go over issues, then try to get some resolution on issues
[18:32:25] --- bob has joined
[18:32:36] <ggm> describing DNAME.
[18:32:40] --- roy@uk has joined
[18:32:54] <ggm> [surely I don't have to try and summarize that in this channel! :-)]
[18:32:55] <weiler> when I was at the mike, I didn't hear myself in the PA system either, so it may just be mixer levels. anyone know where the mixer is?
[18:32:59] --- oatwillie has left: Logged out
[18:33:07] --- patara has joined
[18:33:18] <ggm> "like CNAME but different"
[18:33:37] <ggm> Issue overview.
[18:33:58] --- P_Allietti has joined
[18:34:14] <ggm> 1) discussion in other docs. 3363 givs ip6 recommendation. should remove.
[18:34:52] <ggm> 2) delegation tool use. "copy of zone" -but there are problems. some sub-issues. apex of DNAME is not redirected
[18:35:01] <ggm> everything below is, owner isn't redirected to target.
[18:35:21] <ggm> MX,NS PTR recs, expect canonicals as target, DNAME not canonical.
[18:35:41] <ggm> DNAME doesn't do zone-cut. (rephrase of general issue)
[18:35:45] <ggm> 3)DNSSEC
[18:36:02] <bhoeneis> http://www3.ietf.org/proceedings/06nov/slides/dnsext-1.pdf
[18:36:12] <ggm> minor(ish) issues. NSEC bit reminder, DNSSEC created after DNAME.
[18:36:14] <ggm> [tanks]
[18:36:23] <ggm> this is slide 3
[18:36:35] <ggm> 4) DNAME RR always in reply.
[18:36:41] --- Jyrki.Soini has joined
[18:36:44] <ggm> 5) CNAME RR ttl should be longer
[18:37:20] --- Olaf (Co-Chair) has joined
[18:37:22] <ggm> 6) signalling issue. EDNS version issue, name compression . but EDNS v1 doesn't exist
[18:37:23] --- oatwillie has joined
[18:37:45] <ggm> 7) CiDR blocks in in-addr.arpa DNAME applicable?
[18:38:02] <ggm> 8) wildcard DNAME. "getsmore interesting"
[18:38:03] --- Doug Barton has left
[18:38:15] <ggm> 9) corner cases -eg CNAME re-synthesis?
[18:38:48] <ggm> slide 4. Issue list.
[18:39:14] --- Doug Barton has joined
[18:39:34] <ggm> 4592 clarified no DNAME at wildcards. 3363 is going to require revision.
[18:39:47] --- mikemlb has joined
[18:39:51] <ggm> delegation tool use. propose to say no, but it could be operational, not tech-RFC
[18:40:13] <ggm> DNAME as apex, not redirected itself, propose to clarify.
[18:40:23] --- Hyung Jin Kim has joined
[18:40:34] --- suresh_k@jabber.org has joined
[18:40:41] <ggm> DNAME in outgoing packets always. -proposal is, if !EDNS, exclude DNAME. (compatibility issue)
[18:40:48] --- narten has joined
[18:41:18] <ggm> slide 5 issues list continued
[18:41:29] <ggm> MX/NS, canonicality. same again: not allowed.
[18:41:45] <ggm> DNSSEC considerations, proposal to check DNAME bit in NSEC.
[18:42:00] <ggm> Signalling of understanding, input is needed. what to do?
[18:42:26] <ggm> DNAME not a zone-cut, see above "not allowed" close issue
[18:42:31] <ggm> slide 7
[18:42:38] <ggm> Issue list (cont)
[18:42:49] <ggm> DNAME/CiDR blocks, this is out of scope, drop this here.
[18:43:09] <ggm> Name compression, proposal will depend on signalling consideration.
[18:43:31] --- bob has left
[18:43:33] <robert@dk-hostmaster.dk_remoteparticipant> I see that as slide 6
[18:43:43] <ggm> CNAME ttl issue, propose to increase but needs input.
[18:43:50] <ggm> [you are right. I skipped one. my bad]
[18:43:55] <robert@dk-hostmaster.dk_remoteparticipant> np
[18:44:12] <ggm> CNAME TTL, need input.
[18:44:28] <ggm> slide 7 issues (cont)
[18:44:34] <ggm> NSEC3/DNAME -need input
[18:44:34] --- onakayu has joined
[18:45:05] <ggm> wouter thinks this is not a problem, but if you disagree say so
[18:45:31] <ggm> PTR & DNAME. proposal, same as NS/MX thing. -feedback is "DNAME is not canonical name" - move on.
[18:45:47] --- weiler has left
[18:45:52] <ggm> Corner cases. -resynthesis. no discussion on ML. input needed.
[18:46:04] --- weiler has joined
[18:46:06] <ggm> Thus endeth the current state.
[18:46:17] <ggm> [Olaf] poll readership [non-zero]
[18:46:24] <ggm> Joao at mike. CNAME synthesis.
[18:46:34] <ggm> rather than increase TTL, could we drop CNAME synthesis.
[18:46:48] <ggm> when asked to do CNAME in root, all ops said "impact ops" -no real benefit.
[18:46:57] <ggm> perhaps we can drop altogether. better than TTL raise
[18:47:16] <ggm> Peter Koch
[18:47:31] <ggm> first, like to suggest do not introduce changes in DNAME behaviour which might appear reaction to usage.
[18:47:32] <robert@dk-hostmaster.dk_remoteparticipant> To drop what? DNAME in every sense?
[18:47:43] <ggm> Second, Q for clarification. how to deal with issues in the line?
[18:47:59] <ggm> [Olaf only 5 min of agenda time so no, -important, highlight, but move to list]
[18:48:11] <ggm> NO just drop CNAME (and DNAME) synthesis I think
[18:48:19] <robert@dk-hostmaster.dk_remoteparticipant> k
[18:48:28] <robert@dk-hostmaster.dk_remoteparticipant> Maybe better do drop DNAME though :)
[18:48:29] <ggm> Peter E2E issues.
[18:48:35] <ggm> compression broken
[18:48:46] <ggm> text in 2672 is broken. need versioning.
[18:49:01] --- marka has left
[18:49:02] <ggm> Mark Andrews
[18:49:15] <oatwillie> DNAME is pretty cool... but not being backward compatable, likely true that we should drop it
[18:49:16] <ggm> back when DNAME was designed, versioning was to permit CNAME removal.
[18:49:22] <ggm> required cache to synthesize.
[18:49:31] <ggm> cache synthesis ALWAYS in the design,. expected.
[18:49:41] <ggm> be careful. answers to Qs interrelated
[18:49:44] <ggm> Ed Lewis
[18:49:57] <ggm> CNAME has name compression. how many do we save by not sending synt. CNAME?
[18:50:02] <ggm> Olaf/RobA depends on the name ed.
[18:50:15] <ggm> Wouter very good. if name well compressed, then as good. depends
[18:50:16] --- joshlitt has joined
[18:50:17] <ggm> Ed.
[18:50:27] <ggm> Answer depends if CNAME to be dropped or not. if not many bytes leave in
[18:50:38] <ggm> Issue. DNAME as deleg. tool. where did that come from?
[18:50:47] <ggm> never heard term used that way before
[18:50:49] <oatwillie> ip6.foo
[18:50:49] <ggm> Wouter.
[18:50:54] <ggm> unfortunate choice of wording
[18:51:03] <ggm> mirrors of DNS
[18:51:06] <oatwillie> remapping ip6.int to ip6.arpa
[18:51:10] <ggm> Olaf used as aliasing tool
[18:51:22] <ggm> Ed. put comments into ML about this won't go over again
[18:51:35] <ggm> Wouter didn't change name of title so people could follow context
[18:51:46] <ggm> Ed DNAME always in reply? if DNAME is followed, GOT to be there, CNAME or not.
[18:51:55] <ggm> esp. with DNSSEC. sign DNAME not synth CNAME
[18:51:58] <ggm> Olaf end of line
[18:52:05] <ggm> Olaf. need to progress.
[18:52:08] <ggm> need activity to answer issues
[18:52:29] <ggm> WG needs to work. read. comment on ML. protocol-wise.
[18:52:33] <ggm> Next Topic.
[18:52:36] <ggm> NSEC3 work
[18:52:42] --- marka has joined
[18:52:45] <ggm> David Blacka to the mike
[18:52:49] --- suresh_k@jabber.org has left
[18:53:01] --- suresh has joined
[18:53:31] <bhoeneis> http://www3.ietf.org/proceedings/06nov/slides/dnsext-2.pdf
[18:53:32] <ggm> workshop dulles, draft now at 08. most issues addressed
[18:53:36] <ggm> [thks]
[18:53:43] <bhoeneis> [URwelcome]
[18:54:12] <ggm> tested signalling, in and out of NSEC3
[18:55:04] <ggm> next slide.
[18:55:11] <ggm> did find some issues.
[18:55:28] <ggm> non-NSEC3,
[18:55:38] <ggm> (issue 24)
[18:55:44] <ggm> sorry issue 26
[18:55:56] <ggm> issues 24,25,27 also found.
[18:55:58] --- geoff has joined
[18:56:07] <ggm> next slide. changes from 06 to 08
[18:56:21] <ggm> NSEC3PARAM RR added in 07
[18:56:42] <ggm> no direct query to NSEC3.
[18:56:55] <ggm> validators ignore unknown HASHalg
[18:57:07] <ggm> Max iterations table based on verify speed.
[18:57:10] <ggm> added other text
[18:57:16] <ggm> next slide, more changes
[18:57:34] <ggm> update 2672 allow NSEC 33 under APEX DNAME.
[18:57:43] <ggm> next slide, Issues.
[18:57:48] <ggm> there is an issue tracker.
[18:58:04] <ggm> almost all open issues dealt with.
[18:58:12] <ggm> the open issue, significance of alg. numbers.
[18:58:13] --- scott_rose has left: Replaced by new connection
[18:58:17] <ggm> editors lost the plot on what it meant
[18:58:25] --- scott_rose has joined
[18:59:00] <ggm> next slide next steps.
[18:59:03] <ggm> "one more roll of the dice"
[18:59:06] <ggm> (version)
[18:59:10] <ggm> minor clarity edits.
[18:59:15] <ggm> address the open issue 24
[18:59:17] <ggm> think we're done.
[18:59:18] <ggm> Olaf.
[18:59:22] <ggm> chairs also think this work is done.
[18:59:31] <ggm> will last-call when see new rev. but having said that...
[18:59:38] <ggm> any [DISCUSS] on this right now on NSEC3?
[19:00:17] <ggm> Mark Andrews.
[19:00:26] <ggm> need to put text in, against DNAME and NSEC3
[19:00:38] <ggm> Olaf please submit text, with argument to ML. so can create issue. this week
[19:00:49] --- stevecrocker@jabber.shinkuro.com has left: Logged out
[19:01:15] <ggm> next topic. DNSSECbis updates
[19:01:26] <ggm> http://www3.ietf.org/proceedings/06nov/slides/dnsext-1.pdf
[19:01:31] <ggm> Sam Weiler
[19:01:35] <ggm> doc stable for months.
[19:01:41] <ggm> 2 changes in recent revision, from old email
[19:01:47] <ggm> some controversy from this
[19:02:25] <ggm> can we avoid an issue tracker and do it on-list?
[19:02:28] <ggm> Olaf. sure, if manageable
[19:03:05] <ggm> Q with this doc. can we freeze? is we done? or strong opinion to wait?
[19:03:18] <ggm> Roy Arendts
[19:03:25] <robert@dk-hostmaster.dk_remoteparticipant> that PDF for me is Wouters.
[19:03:29] <robert@dk-hostmaster.dk_remoteparticipant> 's
[19:03:43] <ggm> I missed what he said. sorry.
[19:03:51] <ggm> MarkAndrews. need to keep open for another year at least
[19:03:56] <ggm> more stuff to fall out next year
[19:04:05] <ggm> Olaf.
[19:04:12] <ggm> new agenda section.
[19:04:23] <marcos> roy@uk promised to send input to Sam this week. He'll do so.
[19:04:35] <ggm> New work.
[19:04:44] <ggm> how to avoid spoofing and forgery
[19:04:46] <ggm> doc from bert.
[19:04:53] <ggm> collected wisdom from other impls.
[19:05:14] <ggm> doc goal is to be a BCP
[19:05:28] <ggm> [I don't know which of the agenda links this is.]
[19:05:44] <ggm> how to ask Q in safest manner, guidance to ops, improve current practices
[19:05:56] <ggm> some maths on the theory on forgery probabilities
[19:06:07] <ggm> status: impl out there complying to proposals.
[19:06:09] <Antoin> http://www3.ietf.org/proceedings/06nov/slides/dnsext-5.pdf
[19:06:14] <ggm> some comply with all, some with only some
[19:06:16] <ggm> [ta]
[19:06:29] <ggm> noting the single-source port issue.
[19:06:45] <ggm> Olafur, this is within charter, asking if worth adoption?
[19:06:56] <ggm> needs to see threshold reached. not enough feedback
[19:07:13] <ggm> Peter Koch
[19:07:26] <ggm> see little interop issues in the doc. protocol stuff.
[19:07:34] <ggm> QUestion how on stds track. but that is second Q.
[19:07:41] <ggm> Olafur publish as BCP yes
[19:07:42] <ggm> Peter
[19:07:57] <ggm> as said on ML. write up, Bert have done, is good. but, still, don't see this as RFC.
[19:08:14] <ggm> its what you do on one side of the proto pingpong
[19:08:26] <ggm> more or less documenting pracice recommended by 'certain parties' for quite some time. not news.
[19:08:33] <ggm> Olafur no, not new, but makes easy to find.
[19:08:39] <ggm> Peter, but operational issues/consequences.
[19:08:50] <ggm> a majority of resolvers src from 53.
[19:08:58] <ggm> "don't want to do that"
[19:09:01] <ggm> but thats what it is.
[19:09:42] <ggm> just recommending "open it, allow, don't src from 53, whatever' -will it make operators headaches. -have to reconfig firewalss, security policies. its more than just resolver impl and guidelines
[19:09:49] <ggm> this is missing from doc, if going forward.
[19:09:55] <ggm> Olaf. this is bCP for impl, but not for operators.
[19:10:08] <ggm> Peter. saying ops is not yet in there. 1 or 2 docs, open for discussion
[19:10:18] <ggm> Ed Lewis. Q on ML, doc should be item.
[19:10:19] --- patara has left
[19:10:22] <ggm> 3 topics.
[19:10:25] <ggm> Ed why expand scope?
[19:10:28] <ggm> don't see the Q now.
[19:10:36] <ggm> Olafur fb was "keep it lean and ,mean"
[19:10:46] <ggm> Ed have read, obs. of 'whats good to do in DNS' -good to document.
[19:11:00] <ggm> but to WG doc, depends if WG feels collaboration needed to fix doc.
[19:11:05] <ggm> I hear no real need.
[19:11:22] <ggm> .[bugger I want to go to mike but I can't scribe at same time]
[19:11:28] <ggm> nevermind
[19:11:36] <ggm> Olaf take to individ. submit track would come back.
[19:11:46] <ggm> Ed some go to IESG without coming to group
[19:11:58] <ggm> Olafur of those who have read, could we adv. as-is?
[19:12:06] <ggm> Olaf no hands to that. half room read.
[19:12:09] <ggm> Olafur so doc needs work
[19:12:18] <ggm> Olaf how many who read willing to edit, help. 1-2 persons.
[19:12:31] <ggm> missed name
[19:12:44] <ggm> draft more operational than proto/impl. dnsop is best WG
[19:12:46] <robert@dk-hostmaster.dk_remoteparticipant> Mohsen I think
[19:12:50] <ggm> yes thats it
[19:12:52] <ggm> ta
[19:13:04] <ggm> Olafur raises some op. issues yes. but in context of impls
[19:13:17] <ggm> number of impl. right now cannot use more than 1 port. recommends they do
[19:13:17] <marcos> Mohsen Suissi
[19:13:21] <ggm> Peter
[19:13:27] <marcos> Souissi
[19:13:36] <ggm> dont think there is any point in defer to fri, then repeat.
[19:13:48] <ggm> to make clear, fine to have in this WG.
[19:13:57] <ggm> Ed.
[19:14:08] <ggm> I've made my input.
[19:14:19] <ggm> Olaf. will see if enough traction on ML
[19:14:22] <ggm> 5 ppl commit to work.
[19:14:36] <ggm> once stable, will last-call. if meet threshold. during LC need 5 reviewers
[19:14:39] <robert@dk-hostmaster.dk_remoteparticipant> But if it's going for documenting what to do (i.e. BCP) why dnsext and not dnsop?
[19:14:55] <robert@dk-hostmaster.dk_remoteparticipant> (not that important)
[19:15:16] <ggm> RobA no slides, talking relaxed gratuitous TSIG
[19:15:26] <ggm> short summary.
[19:15:38] <ggm> once upon a time...
[19:15:53] <ggm> signing req meant signed response. if no signed Req then no signed resp.
[19:16:03] <ggm> later. GSSTIG, generic GSS wrapper,
[19:16:15] <ggm> 27 levels deep nesting to kerberos, auth DNS transactions
[19:16:20] <ggm> was used.
[19:16:22] <ggm> is used.
[19:16:32] <ggm> core technology (kerberosGSSAPI that is)
[19:16:41] <ggm> F/OSS interop successes, minimal interop
[19:16:54] <ggm> ISC were asked to look at it, discoverd bizarre things.
[19:17:13] <ggm> spec impl is not what is implemented. incomplete
[19:17:23] <ggm> follow spec, cannot talk to ANY service as-is.
[19:17:29] --- narten has left
[19:17:46] <ggm> unfortunately. spec takes you where you don't want to go. rejection inevitable.
[19:17:49] <ggm> appears pointless.
[19:18:05] <ggm> no security benefit. MS and others asked for changes to spec, not an unsafe thing to do.
[19:18:25] <ggm> omit, works fine.
[19:18:31] --- jad has left
[19:18:46] <ggm> none of the required impls require it. so this doc makes it explicitly optional. one msg in exchange can be unsigned
[19:18:59] <ggm> Q for room is, are there 5 people, not working for companies, interested in reviewing?
[19:19:04] <ggm> issue been dormant.
[19:19:11] <ggm> hands raise
[19:19:14] <ggm> Olaf takes names
[19:19:30] <ggm> the finger points, and moves on.
[19:19:38] <ggm> RobA
[19:19:51] <ggm> have to change spec come what may
[19:19:59] <ggm> bernards reading, dropping is fine.
[19:20:05] <ggm> seems way to go subject to review
[19:20:09] <ggm> Olaf thanks the volunteers
[19:20:30] <ggm> Donald Eastlake on DNS cookies
[19:20:45] <Antoin> http://www3.ietf.org/proceedings/06nov/slides/dnsext-0.ppt
[19:21:04] <ggm> DNS cookies provide weak auth.
[19:21:15] <ggm> minor change to RR, extension stuff
[19:21:22] <ggm> reduced forged source IP traffic.
[19:21:34] <ggm> reduces cache load, poisoning attack risks
[19:21:43] <ggm> ascii art of option-RR
[19:21:52] <ggm> (will require a code assignment TBD)
[19:22:11] <ggm> slide 'resolver warm fuzzies'
[19:22:28] <ggm> put in plainttext. if not on path, cannot see, so cannot spoof. prevents non-src pkts coming in.
[19:22:43] <ggm> enforceable policy. cookie in Q, function of secrret known to resolver, IP of server.
[19:22:48] <ggm> draft recommends, HMAC/MD5
[19:23:08] <ggm> checked, MD5 is ok, but prefer SHA1 (security directorate)
[19:23:18] <ggm> floor: its a local decision,k you check your own cookie
[19:23:30] <ggm> Donald do NOT send identical cookie to everyone. forbidden.
[19:23:50] <ggm> cached, update when seen to change
[19:24:14] <ggm> server side fuzzies
[19:24:30] <ggm> server use secret too, resolver IP. same crypto alg.
[19:24:35] <ggm> can enforce, require, always send, disable
[19:25:00] <ggm> server can use weak auth, can just drop
[19:25:08] <ggm> sorry short error msg. NOT drop.
[19:25:29] <ggm> timing diag.
[19:26:19] <ggm> Complexities
[19:26:29] <ggm> simplified explanation, but NAT makes more complicated
[19:26:44] <ggm> multiple resolvers behind NAT, all have different cookies, but NAT obfuscates.
[19:27:06] <ggm> mix resolver cookie into server cookie. can de-obfuscate, no need to cache resolver-side, server can
[19:27:28] <ggm> anycast servers, need to have same cookie. recommendation is to use same server secret
[19:28:00] <ggm> interest in making WG draft has been expressed
[19:28:14] <ggm> good comments from ML
[19:28:15] <ggm> RobA
[19:28:24] <ggm> objection not changed: this is 20 years too late
[19:28:29] <ggm> Donald.
[19:28:30] <ggm> yes.
[19:28:51] <ggm> but I know people want this, important, complained other DNS security, characterized as load on server. cheap. helps.
[19:29:10] <ggm> Olafur. noted request for WG to consider.
[19:29:14] <ggm> will ask ML for guidance.
[19:29:19] <ggm> Peter K
[19:29:35] <ggm> strikes me, thnk DNSSEC ready, several of these proposals pop up, solve same problem.
[19:29:45] <ggm> are we sending signal "don't believe in DNSSEC" and need these things?
[19:29:51] <ggm> Olafur
[19:30:03] <ggm> aim of proto is to reduce large packets being reflected off DNS entities
[19:30:19] <ggm> Donald. 2 kinds of dns security, origin security, and TSIG. this is weak TSIG. not the first stuff.
[19:30:23] <ggm> MarkAndrews
[19:30:34] <ggm> re-iterate comment Donald made
[19:30:47] <robert@dk-hostmaster.dk_remoteparticipant> inaudible anyway
[19:30:56] <ggm> he didn't say anything. it was a 'me too'
[19:31:02] <ggm> hands up for read: 10ish people
[19:31:05] <Jelte> i read the previous version
[19:31:07] <ggm> Olaf. last agenda item
[19:31:14] <ggm> glad we have tme to discuss.
[19:31:20] <ggm> Mike St Johns to the mike
[19:32:03] <Antoin> http://www3.ietf.org/proceedings/06nov/slides/dnsext-3.pdf
[19:32:04] <ggm> Olaf is filling time being sociable
[19:32:12] <ggm> Mike St Johns went to refresh his batteries or something.
[19:32:19] <ggm> floppy disk is being exchanged
[19:32:26] <ggm> mike check from mike
[19:32:42] <ggm> apologies (slightly) for the presentation.
[19:33:03] <ggm> should be single-thread. this is both why, and details.
[19:33:12] <ggm> sig-only DNSSEC.
[19:33:17] <ggm> slide on terms
[19:33:27] <ggm> PNE and AKA defined
[19:33:34] <ggm> PNE vs sig-Only (SO)
[19:33:43] <ggm> lighter weight system, without purtubing current system.
[19:33:57] <ggm> DNS security minus all the provable non-exist NSEC3 stuff
[19:34:09] <ggm> get rid of it, get opportunities. get sigs off-tree.
[19:34:20] <ggm> can do same type of trust in certs, webserver style.
[19:34:36] <ggm> what you cannot do, cannot do intermediate validation in resolver in middle. only end-client
[19:34:48] <ggm> PNE gives us?
[19:34:50] <ggm> (slide)
[19:34:55] <ggm> only 2 state differntiation
[19:35:06] <ggm> bogus, or unsecure
[19:35:09] <ggm> thats all it gives you
[19:35:42] <ggm> think about what cust. wants, validated or unvalidated, all three invalids collapse in customer view as 'bad'
[19:35:53] <ggm> there was the 'indeterminate' state. but its really a sub-state of bogus.
[19:35:57] <ggm> have to determine it as bad.
[19:36:12] --- narten has joined
[19:36:18] <ggm> unknown is 'no superior trust anchor' has to be treated as unsigned
[19:36:39] <ggm> if data can be validated, PNE info is never touched., if you have trust chain, never see NSEC/NSEC3
[19:36:46] <ggm> off-mike comment I missed
[19:37:03] <ggm> [slaps own hand for heckling]
[19:37:11] <ggm> what does client see?
[19:37:21] <ggm> client cares valid, or unseen/invalid. 2 state
[19:37:47] <marcos> i don't believe this is all the client cares
[19:38:10] <ggm> if sig, CD bit set, then gets valid/unvalid. PNE does secure, bogus, or unsecure/unknown.but with the CD, doesn't matter.
[19:38:16] <ggm> what does PNE cost.
[19:38:32] <ggm> NSEC/NSEC3 cost, can't do inserts.
[19:38:43] <ggm> rules on 'how data MUST be signed'
[19:38:50] <ggm> can't do off-tree sigs.
[19:38:59] <ggm> 13 years (and counting)
[19:39:17] <ggm> more fragile DNS, (one error in sign, entire branches disappear)
[19:39:27] <ggm> complex validation alg. for bogus state
[19:40:10] <ggm> Mike says the alg for bogosity is too complex, 20 walkthroughs led him to different understandings each time
[19:40:15] <ggm> what PNE can do, SO cant
[19:40:25] <ggm> intermediate resolver validation.
[19:40:31] <ggm> some wildcard limitations
[19:40:46] <ggm> short cuts to some lookups, when you know data doesnt exist
[19:41:02] <ggm> int. resolver thing. 14 years ago, went to <missed it>
[19:41:12] <ggm> manager said "want net security" proposal ws DNS security
[19:41:33] <ggm> year-in to process, design discussion, one of the things was "want DNSSEC, without end-sys modification"
[19:41:47] <ggm> seemed reasonable at the time, intermediate went in, driving requirement for provable non-exist.
[19:42:02] <ggm> unclear if you can do anything reasonable, in terms of validation in intermediate resolver
[19:42:06] <ggm> what can SO do PNE cannot?
[19:42:09] <ggm> off-tree sigs.
[19:42:13] <ggm> lots of island of trust, quickly
[19:42:22] <Jelte> cache poisoning protection maybe?
[19:42:22] <ggm> no dependency on parent sign.
[19:42:54] <ggm> if no intermediate validation, can have simpler recursive server
[19:43:43] <ggm> per-app validation.
[19:43:47] <ggm> Proto diffs.
[19:43:59] <ggm> two new RR types. DSSO, same as DS, indicating SO only zone
[19:44:01] --- mikemlb has left: Logged out
[19:44:20] <ggm> OSIG off-tree sig. go off, get it signed by external entitiy, change can be done.
[19:44:28] <ggm> Auth Server changes
[19:44:41] <ggm> need to handle DSSO, OSIG. based on DS, RRSIG
[19:44:52] <ggm> PNE today, can do SO 'leaf' -not further delegs.
[19:45:32] <ggm> Recursive server changes
[19:45:39] <ggm> server does PNE. (assumption)
[19:45:46] <ggm> ad DSSO/OSIG handling.
[19:45:59] <ggm> client sets CD bit. (could be a bug in 4035)
[19:46:03] <ggm> Validation notes
[19:46:19] <ggm> validator can flow through PNE, ignore, do off-tree in SO
[19:46:37] <ggm> no downgrade attacks. same method of validation algs client side. chain not met, chain is broken, don't get validated
[19:46:41] <ggm> SUmmary.
[19:46:43] <ggm> simpler.
[19:47:55] <ggm> lots have read.
[19:47:59] * Jelte raises hand
[19:48:01] <ggm> 20-30 people
[19:48:07] <ggm> Mike how many positive?
[19:48:11] <ggm> {some}
[19:48:15] <ggm> neg?
[19:48:18] <ggm> {more}
[19:48:24] <ggm> Mike so not "there yet"
[19:48:27] <Jelte> "sceptical" :)
[19:48:29] <ggm> JOhan
[19:48:48] <ggm> not having read draft, and confused, immediate Q. without provable deny of exist, what is to stop spoofs?
[19:49:16] <ggm> Mike what does client do?
[19:49:33] <ggm> have been asking repeatedly, example of app, where its going to do different things
[19:49:57] <ggm> Mike, asking for client/app going to do differen tthings based on the 3 states PNE can discriminate, cannot find one
[19:50:02] <ggm> Johan. secure box becomes smaller
[19:50:13] <ggm> Mike no, its no change. chain from TA is the prime thing.
[19:50:22] <ggm> Johan attacker can make that happen
[19:50:26] <ggm> Mike no worse. can stop you anyway
[19:50:35] <ggm> DNS is set up to deal with data tx errors.
[19:50:41] <ggm> can get small scale attacks on sys yes.
[19:51:17] <ggm> RobA
[19:51:23] <ggm> read draft. (insted of eating lunch)
[19:51:28] <ggm> will try not to be grumpy
[19:51:36] <ggm> don't believe the premise of doing without deny exist.
[19:51:47] <ggm> specific cases where prot rely on it, apps rely on it. been down it
[19:51:52] <ggm> with sitefinder. MX rec.
[19:51:57] <ggm> MX doesnt exist, fall back to A.
[19:52:09] <ggm> whats the threat of mail to host named, instead of other place? change of proto
[19:52:12] <ggm> (in mail land)
[19:52:22] <ggm> need to know
[19:52:33] <ggm> Mike no changed impl. proto DNS/Mail proto stays same
[19:52:36] <ggm> Roba mail flow changed.
[19:52:42] <ggm> Mike agree. change in behaviour
[19:53:05] <ggm> Roba wildcards.
[19:53:20] <ggm> wildcard proofs were 'fun' -back in study for 3 years if you destroy the proofs
[19:53:35] <ggm> Mike. in draft, state, "things under places covered by wildcard, desrve what you get"
[19:53:40] <ggm> safer, cheaper, tell them not to do it
[19:53:44] <ggm> cant figure threat
[19:54:03] --- roy@uk has left: Logged out
[19:55:12] <ggm> Mike unclear intermediate val makes any sense. prvable cost:benefit of noexist. hard
[19:55:29] <ggm> RobA dont know the uses
[19:55:32] <ggm> Mike not seen in 10 years
[19:55:45] <Jelte> can't you use intermediate validation for cache poisoning prevention? or does this have a mechanism for that too?
[19:55:47] <ggm> RobA subtext in what said, must to endpoint validation
[19:55:56] <ggm> ppl depnding on this, installed base stuff.
[19:56:07] <ggm> Mike may disagree but go ahead
[19:56:21] <ggm> ROba intriuged by off-tree. encourage to split. draft on off-tree, scared by the rest
[19:56:38] <ggm> Mike off-tree, basic requirement for PNE, stirct hierarchy. presence of TA, trhow you into secure space
[19:57:58] <ggm> [missed robs last point]
[19:58:11] <ggm> Mike seen to many changes. 3 more years in from last crisis, still not done.
[19:58:24] <ggm> don't think we're going to be out of this soon. (almost said iraq...)
[19:58:28] <ggm> Ed
[19:58:29] <ggm> Q
[19:58:42] <ggm> why is off-tree sign something PNE cannot do.
[19:58:53] <ggm> mike presence of the TA indicates secure part of tree.
[19:59:35] <ggm> if you try and do off-tree, with no TA on stjohns.com, TA is in trustanchor.com, down a chain. have off-tree sig pointing over, resolver, doesn't get indication this part of zone is signed. cant put into bogus state. basically using SO
[19:59:47] <ggm> Ed reason thrown by this, say get sig back from PNE, it tells me who signed.
[19:59:59] <ggm> can go anywhere to validate that. policy can do that
[20:00:22] <ggm> going way back, off-tree was in DNSSEC, droped in an RFC, trying to write code, didn't know how to write policy lang parser to do that. go with on-tree
[20:00:30] <Jelte> you don't want possibly eternal (ly faked) chains
[20:00:39] <ggm> [6 ppl at the mike]
[20:01:05] <ggm> Mike notionally in secure state until get unsecured deleg
[20:01:12] <ggm> Ed take answer and go backwards to TA
[20:01:27] <ggm> Mike start out in tree with no TA, get answ, RRSigs deleted, don't know to do it.
[20:01:38] <ggm> Sam Weiler
[20:01:50] <ggm> thought I heard assertion PNE requires intermediate val?
[20:01:53] <ggm> Mike no, didn't say that/
[20:02:00] <ggm> intermediate val. requires PNE. other way round
[20:02:10] <Suz> MSJ: doesn't anyone want to get up to the mike to *support* me?
[20:02:23] <ggm> yes I missed that too.
[20:02:34] <ggm> Mike ppl talk about PNE as intermediate val.
[20:02:41] <ggm> Sam not colleagues at sparta, doing at end-client
[20:02:52] <ggm> Mike but its been server stuff for most. mandatory or not in recursive srv?
[20:02:55] <ggm> Olaf no not mandatory
[20:02:58] <ggm> Sam back to picture
[20:03:05] <ggm> like picture
[20:03:15] --- Thierry has left: Replaced by new connection
[20:03:15] <ggm> what do you imagine app do with unvalid state data?
[20:03:17] <ggm> Mike not use it.
[20:03:17] --- Thierry has joined
[20:03:37] <Jelte> hehe
[20:04:11] <ggm> sorry, this is moving too fast for me to type
[20:04:26] <Suz> lots of, errr, lively discussion
[20:04:35] <ggm> Wes from sparta
[20:04:46] <Jelte> luckily that was followable :)
[20:04:48] <ggm> asked repeatedly for apps doing diff with insecure vs secure
[20:05:16] <ggm> told you multiple times, my apps do something different. when I fall out of trusted tree into provably insecure. I do other stuff. you say "unwise" but, I code around it.
[20:05:28] <ggm> cannot do policy for every zone out there, what is signed or not.
[20:05:48] <ggm> with DSSO, can strip out, I have to encode expectationsinto policy. unwilling to do iff parent can do it properly.
[20:05:53] <ggm> altready trust parents to do other stuff
[20:06:01] <ggm> Mike but deletion of those mean dont get data, then back where you are.
[20:06:15] --- mgraff has left
[20:06:16] <ggm> Wes but I get somewhere insecure, and can exploit it. want to use policy bit
[20:06:22] <ggm> Mike make me an app and show me.
[20:06:24] <ggm> Wes I have one.
[20:06:35] <ggm> Firefox does that now
[20:06:55] <ggm> Olafur new Q only
[20:07:00] <ggm> Peter K. one Q. from reading draft
[20:07:07] <ggm> would PNE children of SO work?
[20:07:13] <ggm> Mike yes. PNE can be child of SO
[20:07:18] <ggm> sO resolver is going to ignore
[20:07:29] <ggm> PNE resolver is going to refuse, treat as unsecure without TA
[20:07:56] <ggm> PeterK. increased use of DNS for indirection. NAPTR etc
[20:08:08] <ggm> Rob said MX is a problem. NAPTR is even worse.
[20:08:18] <ggm> Mike have suspicions.
[20:08:19] --- weshardaker has joined
[20:08:41] <ggm> NAPTR, signed or unsigned, can use it. MX, accept or use A, different TBD. app specific. not DNS thing
[20:09:31] <ggm> Mike mailsrevers right now dont validate.
[20:09:44] <robert@dk-hostmaster.dk_remoteparticipant> I have a feeling there's no strong sentiment in the room for the wg to take on this document.
[20:09:47] <ggm> when you write changes for mailserver following MX, say "ask DNS" -how to use DNSSEC, policy is...
[20:09:58] <ggm> [that would be correct. he isn't getting support from the floor]
[20:10:15] <ggm> Mike PNE is useful. but high cost. not sure cost:benefit works
[20:10:18] <ggm> Peter. might be right
[20:10:37] <ggm> without PNE would deploy quicker, but challenge if apps can make as much use as can need to DNSSEC is less use.
[20:10:44] <Jelte> i'm not sure, it could be a healthy scepticism for a proposal like this :)
[20:10:45] <ggm> Mike how many apps ask more thanone primary rec type?
[20:10:56] --- bhoeneis has left
[20:11:01] <ggm> some ask one, then ask another, mail is one of the few which does fallbacks, and its an artifact ofhistory
[20:11:06] <ggm> not in SMTP, in base mail stuff
[20:11:09] <ggm> RObA
[20:11:16] <ggm> olafur cuts mike after this
[20:11:28] <ggm> concerned, havent looked in detail but SRV usage might be in same boat.
[20:11:42] <ggm> MX is like SRV not the same, but could be non-trivial effects on impl.
[20:12:00] <Jelte> what about AAAA falling back to A for hostname lookups?
[20:12:04] <ggm> changes model enough, goal is to get out quickly, by 2010 may hav efigured it out
[20:12:09] <ggm> interop issues
[20:12:14] <ggm> Mike might still beat NSEC3
[20:12:31] <ggm> Olafur Q for Mike
[20:12:35] <ggm> what do you want WG to say?
[20:12:48] <ggm> Mike I'd like them to think about it. some good points
[20:13:03] <ggm> nobody is saying "omg biff" (actually I did he said)
[20:13:17] <ggm> one of the pieces, you can deploy with PNE, end sys can get some benfits. maybe
[20:13:27] <ggm> like people to think, do more than knee0jerk
[20:13:44] <ggm> problem seen in DNS, simple proto, datastore, few special recs
[20:13:44] <robert@dk-hostmaster.dk_remoteparticipant> ?
[20:14:11] <ggm> now more special recs, more complex processing.
[20:14:26] <ggm> kept silent over some stuff, but thought why? breaking normal DNS.
[20:14:34] <ggm> forbids on wildcards why? part of normal dns.
[20:14:46] <ggm> keep special casing stuff. keep DNSSEC simple, keep DNS as datastore.
[20:14:49] <ggm> Olaf
[20:14:57] <Jelte> same for plain nsec btw
[20:15:06] <ggm> think the call for review of work, looking at it in detail is a call I urge WG to follow
[20:15:11] <ggm> Olaf one of my fears is that
[20:15:16] --- narten has left
[20:15:48] --- Antoin has left
[20:15:51] <ggm> if we don't make up minds soon if this is to persue, then we as WG/IETF/in-room are sending msg, "wait, for DNSSCbis" until done, etc if we fail, with new proposed path, added huge delay to DNSSECbis as-is
[20:16:00] <ggm> important we make up mind fast, in this WG, if willing to persue.
[20:16:06] <ggm> hope we have closure on this issue before next IETF
[20:16:13] <ggm> please take discuss to ML. review
[20:16:16] <ggm> provide args
[20:16:28] <ggm> by next IETF, hope. can get consensus on forward or refuse draft as WG item
[20:16:35] <ggm> can we agree on this way forward?
[20:16:39] <ggm> Wes
[20:16:44] --- Jyrki.Soini has left
[20:16:50] <ggm> given people have given it thought, concept
[20:17:12] <ggm> worth show of hands now to guage? we have been thinking
[20:17:24] <ggm> Olaf did a sort-of, at beginning, saw, hands up for pro, not ALL anti
[20:18:08] <ggm> Olafur Q comes up for change, always reject 'almost done'
[20:18:21] <ggm> this might be the 6th time, Q keeps getting raised, worried if give wrong answer each time
[20:18:25] <ggm> Russ mundy.
[20:18:47] <ggm> agree asked multiple times. think, in each iteration, the conclusion for "we needPNE" was not 'almost done' was need PNE.
[20:19:04] <ggm> was not just 'we are close' it was 'do you think we need it' and was yes each time. way we need to think about it.
[20:19:09] <ggm> maybe today we think we don't need PNE. need to know
[20:19:21] <ggm> Mike
[20:19:35] <ggm> wrote draft because each time before, its been a Q. not 'is there a viable alternative'
[20:19:41] <ggm> PNE and intermediat validation are differnt
[20:19:49] <ggm> maybe get rid of intermediate val I am happy
[20:20:00] <ggm> Olaf no rquire for intermediate val.
[20:20:06] <ggm> Mike want to prohibit
[20:20:11] <ggm> Olafur could recommend?
[20:20:14] <ggm> Olaf getting distracted.
[20:20:24] <ggm> Olafur want feedback inside 3 months, persue or not
[20:20:30] <ggm> Olaf before next IETF.
[20:20:32] --- jakob has left
[20:20:37] <ggm> Olafur this is a 00 draft. may change. may improve
[20:20:54] --- Jim Galvin has left
[20:20:54] --- koji has left
[20:21:02] --- asullivan has left
[20:21:03] --- scott_rose has left
[20:21:09] --- dblacka has left
[20:21:13] --- marcos has left
[20:21:14] --- raj has left: Logged out
[20:21:21] --- hotta has left
[20:21:23] <ggm> [done]
[20:21:23] --- suresh has left
[20:21:27] --- P_Allietti has left
[20:21:30] --- weiler has left
[20:21:30] --- glozano has left
[20:21:30] <robert@dk-hostmaster.dk_remoteparticipant> thanks ggm
[20:21:33] <oatwillie> thanks ggm
[20:21:34] <robert@dk-hostmaster.dk_remoteparticipant> very useful
[20:21:39] --- Jaeyoun Kim (KRNIC, NIDA) has left: Computer went to sleep
[20:21:42] --- onakayu has left
[20:21:44] <ggm> sorry I lost the plot from time to time
[20:21:51] --- ggm has left
[20:22:05] --- shigeya has left: Logged out
[20:22:26] --- msj has left
[20:22:48] <Jelte> i was able to follow just about everything i think :)
[20:23:24] --- robert@dk-hostmaster.dk_remoteparticipant has left
[20:23:33] <Jelte> thanks for jabber-scribing
[20:23:35] --- oatwillie has left: Logged out
[20:23:43] --- fneves has left
[20:24:10] --- Jelte has left
[20:27:43] --- Olaf (Co-Chair) has left: Logged out
[20:28:56] --- weshardaker has left: Disconnected.
[20:30:16] --- joshlitt has left
[20:32:01] --- Doug Barton has left
[20:32:46] --- msj has joined
[20:32:53] --- msj has left
[20:35:46] --- Suz has left
[20:37:12] --- hotta has joined
[20:38:05] --- wouter has left: Logged out
[20:39:01] --- Hyung Jin Kim has left
[20:40:55] --- pk has left
[20:41:06] --- healthyao has left
[20:42:34] --- geoff has left
[20:43:45] --- mo7sen has left
[20:46:40] --- marka has left
[20:47:48] --- marka has joined
[20:49:01] --- hotta has left
[20:54:18] --- Thierry has left
[20:54:43] --- healthyao has joined
[20:55:00] --- otmar has left: Replaced by new connection
[21:03:42] --- marka has left
[21:13:07] --- liman has left
[21:14:47] --- Suz has joined
[21:15:48] --- mo7sen has joined
[21:16:55] --- mo7sen has left
[21:19:31] --- fujiwara has left
[21:20:04] --- Suz has left: Replaced by new connection
[21:26:11] --- ogud has joined
[21:32:04] --- healthyao has left
[21:33:19] --- paulwouters@jabber.org has left
[21:52:24] --- ogud has left
[23:14:35] --- mrichardson has left