[00:12:55] --- shane_ripe has joined
[00:25:56] --- ggm has joined
[00:26:09] <ggm> agenda modified from published state.
[00:26:16] <ggm> in light of monday meeting
[00:26:33] --- dthaler has joined
[00:26:50] <ggm> scenarios: tunnelling analysis. -intro
[00:26:50] --- Bob.Hinden has joined
[00:27:03] <ggm> try to look at scenarios in a bit more detail
[00:27:11] <ggm> get some cases of those scenarios on the table. in next few slides
[00:27:17] --- sakai has joined
[00:27:19] <ggm> [ptrs to slides online welcome]
[00:27:29] <ggm> loot at properties of solutions.
[00:27:32] <ggm> /sloot/look/
[00:27:42] <ggm> looking for consensus here, or soon afterwards
[00:27:51] <ggm> before San Diego
[00:28:04] <ggm> [Pekka speaking]
[00:28:21] <ggm> specs not selected in this process, ok to describe current impl. informational/experimental to RFC ed
[00:28:37] <ggm> would include applicability statement , AD statement or something like that
[00:28:42] <ggm> comments?
[00:28:48] <ggm> on intro in particular?
[00:28:55] <ggm> 3GGP nets.
[00:29:02] <ggm> two rather 'creative' scenarios.
[00:29:13] --- arifumi has joined
[00:29:16] <ggm> 1st is when you roam into V4 only net, need tunnel back home to continue v6 access
[00:29:40] <ggm> 2nd, solved using same mech. 3gpp operator has not yet deployed v6 pdp context (recommendation in 3gpp)
[00:30:03] <ggm> assumption (in 2nd case) some ops, havent gone with native support may do some other mechanism eg lightweight, easier to deploy.
[00:30:17] --- moc has joined
[00:30:21] <ggm> no support at all from 3gpp op is out of scope. like a transition env.
[00:30:43] <ggm> issue. its a node2node direct tunnel inside 3gpp net. conclusion is that its nice to have, not MUST but something useful
[00:31:13] <ggm> unman nets
[00:31:28] <ggm> isp doesnt support, user get 6 automatically.
[00:31:50] <ggm> contract or signup or whatever, with some other ISP further upstream/elsewhere, eg higher security
[00:32:09] <ggm> long tunnels are bad.
[00:32:34] --- rei has joined
[00:32:40] <ggm> second major scenario. ISP want to support, but acs router on link, homeg/w in unman doesnt to v6 for some reason
[00:32:55] <ggm> solution from previous case works here, .
[00:33:06] <ggm> major issues. NAT/dyn4 needs continuing support
[00:33:20] <ggm> no isap support == direct tunnels, infrastructure
[00:33:38] <ggm> node2node? might be free eg 6to4/Teredo. hard with NAT
[00:33:51] <ggm> ISP scenarios -not included here.
[00:34:42] <ggm> Ent nets. - <sorry missed his words> but basically nothing to say at this time
[00:35:11] <ggm> Optional additional scenarios -IP mobility, move signalling requirement. time low requirement 4in6 for some period required
[00:35:20] <ggm> Comments on scenarios?
[00:35:53] <ggm> agreement scenarios described here are appropriately analysed?
[00:35:55] <ggm> BobH
[00:36:02] --- duidsaki has joined
[00:36:17] <ggm> first Q.mentioned at first session. still believe WG can move forward in parallel with this process.
[00:36:43] <ggm> deployed, being used, enough of a test. no need to delay to August
[00:36:46] <ggm> Pekka
[00:36:54] <ggm> not sure any implication of delay until next IETF
[00:38:19] <ggm> Bob: want to talk about discussion process with AD to publish. sequential process
[00:38:42] <ggm> Chair no. can be proposed as inf. or exp. individ submissions right now.
[00:38:49] <ggm> then what we'll do is pick up preferred solution.
[00:39:08] <ggm> BobH quite reasonable, to say 'advance to std' but do think imp. after all this time we publish open spec for things widely deployed
[00:39:13] <ggm> Chair thats what it says.
[00:39:21] <ggm> Bert.
[00:39:30] <ggm> Ops AD but not prime this WG>
[00:40:34] <ggm> chairs asking Q about this stuff on slide. not going forward. had this policy not allow indiv. docs to RFC-ED would be end-run around WG. have discussed with chair, indeed now time to allow such docs to go forward as indiv. docs, no longer consider as end-run. Proviso: disclaimers. IETF still working on standardized soln.
[00:40:37] <ggm> Pekka ie he says ok
[00:40:54] <ggm> Bert Q want to pose to WG. now? dunno. first asking about analysis right?
[00:41:14] <ggm> Tony: WG allowed to work on these docs. can go as ind.
[00:41:20] <ggm> Bert. hear what you say
[00:42:00] <ggm> Bert. look at slide. says do a bunch of stuff, then look at std one or more docs. at this point in time, if people want to go ahead and publish thats fine. good in fact. my personal view. have formally published a publically avail doc on the impls.
[00:42:12] <ggm> Tony spend 2.5 yrs getting to second to last bullet. we should just get it done.
[00:42:33] <ggm> Chair bit of confusion. will re-iterate. have produced stable analysis docs. understand scenarios.,
[00:43:07] <ggm> understand analysis of scenarios. what we are starting to do now is develop mechs which suit those analyses. will allow people to post as indiv. submissions those proposals now implemented, in the market.
[00:43:16] <ggm> hopefully this clears up more than it confuses. Dave next
[00:43:29] <ggm> Dave Thaler.
[00:43:54] <ggm> Eric. current impl, or potential extensions not yet impl. dont know what we're trying to do. may be different from current versions of the draft out there.
[00:44:08] <ggm> Pekka exactly. not sure what process. encourage people to submit current impl, not could be.
[00:44:16] <ggm> Erik if the WG agrees with that. capturing current impl is good thing.
[00:44:38] <ggm> Dave Thaler. characterized scenarios sufficiently?
[00:44:50] <ggm> didnt understand ... not neccessarily the other way round (on a slide)
[00:45:40] <ggm> scenarios with no help, characterized these enough well no.
[00:46:02] <ggm> ent want as little overhead as possible. isps want as little maint/inf. cost as possible. also applies to ent. good enough.
[00:46:13] <ggm> pekka not today. contrib to enterprise people
[00:46:53] <ggm> <missed this one. sorry>
[00:47:07] --- moc has left: Replaced by new connection
[00:47:08] --- dthaler has left: Replaced by new connection
[00:47:09] <ggm> chair personal op. document those implementations.
[00:47:10] --- dthaler has joined
[00:47:25] <ggm> pekka,. point is to ensure interop. thats whats interfering at the moment.
[00:48:08] <ggm> pekka. at least some input to mech selection process. difficult to say
[00:48:24] <ggm> Chair lets not talk hypothetically too much longer
[00:49:10] <ggm> <?2> cross refs this doc and diffferent docs for scenarios . recommend referencing docs when dealing with tunnelling mechnaisms. eg for ISP scenario talk not about tunnelling. are you recommending we reference this document as a complete analysis for tunnelling mechanisms?
[00:49:26] <ggm> Pekka. asking about how to capture this presentation we are having here, how intergrated into analysis doc.
[00:49:35] <ggm> Yes. we would integrate the stuff with the analysis doc.
[00:49:45] <ggm> Chair just our propsal. this is what we THINK the WG thinks
[00:50:00] <ggm> next presentation
[00:50:27] <ggm> Pekka. have to cancel the application transition doc. timing issue. doc currently in WG last call
[00:52:20] <ggm> IPv6 transition for mobile nodes
[00:52:42] <ggm> mob 4 users. how to take to mob v6.
[00:53:05] <ggm> also have. mob6. how to provide seamless roaming.
[00:53:33] <ggm> currently focussed on 6 transition in terms of stationary node deployments
[00:54:41] <ggm> transition issues.
[00:55:04] <ggm> meant to be temporary not permanent. -maybe not allow some permanent helper.
[00:55:11] --- jm has joined
[00:56:33] --- moc has joined
[00:57:04] <ggm> I don't have URL for slides. sorry.
[00:57:57] <ggm> handover performance same as for base specs, not optimized, more than base spec provides. other performance implications in terms of what approach taken with packets on radio. other issues being discussed in hallways, come up at BoFs
[00:58:09] <ggm> now animated scenarios. see slides
[00:59:05] <ggm> proposal to move forward.
[00:59:21] <ggm> mob transition doc in short time period. work? BoF? ML?
[00:59:27] <ggm> Pekka: comments or more consideration?
[01:00:24] --- tskj has joined
[01:00:33] <ggm> Thomas Narten at the mike. Q about mob access, asking where to take discussion. mobileIP or here? or somewhere else. guidance now where to start
[01:00:37] <ggm> Thomas. defer. coordinate
[01:00:51] <ggm> v6ops most transition. others not set up for it. want to think.
[01:00:58] <ggm> Dave Thaler. Q on presentation.
[01:01:08] <ggm> wasn't clear what significant difference was when adding mobility.
[01:01:25] <ggm> what is fundamental distinction.
[01:01:32] <ggm> Pekka its possible with existing mechanisms.
[01:01:40] <ggm> Dave so maybe dont need BOF. just say "use existing"
[01:01:54] <ggm> Author: needs analysis. the landscape. come to that conclusion, if appropriate.
[01:02:06] <ggm> <sigh no idea who this is>
[01:02:17] --- bkhabs has joined
[01:02:57] <ggm> handover can be too slow to be anything but painful. M-IP specific analysis needed to see what overhead we get in tunnelling/handoff if we don't do a mob speciific soln.
[01:02:59] <ggm> Erik
[01:03:35] <ggm> hard to balance is additional complexity. conflating tunnel for mobile IP is going to make complexity significantly higher. (than if layered ?) have to figure out how to compare.
[01:03:55] --- dlpartain has joined
[01:03:56] <ggm> <nideawho> have implemented one of these. one more extension not so much complexity.
[01:04:16] <ggm> Chair is this analysis good or useful? cannot say where to do it yet.
[01:04:26] <ggm> encourage authors to do a draft
[01:04:44] <ggm> TJ nighton. understanding in designing 6, mobility was important. should definitely be considered
[01:04:46] <ggm> Pekka.
[01:04:53] <ggm> update on transition mechanisms
[01:05:00] <ggm> with IESG as PS.
[01:05:04] <ggm> resolve comments
[01:05:50] <ggm> want impl/interop reports before DS.
[01:06:14] <ggm> transmech changes. lots. not going through now.
[01:06:39] <ggm> Impl/Interop. must be verified in excruiciating detail to get DS.
[01:07:37] <ggm> organizing actual testing is out of scope. interested in coordinating, contact chairs
[01:08:00] <ggm> [ETSI have a bloke here who came to speak to CRISP about interop on that stuff. so there are bods at IETF who like this kind of space]
[01:08:41] <ggm> WG call if using template good idea.
[01:08:48] <ggm> sorry I mean room call.
[01:08:55] <ggm> nobody voting. [laughter]
[01:09:50] <ggm> BobH talked about requirements for DS. but talked before about pub as exp/inf.
[01:10:05] <ggm> Pekka this was about base doc for tunnelling. sent for pub as PS. wishing to move forward.
[01:10:07] <ggm> Bob sorry,. lost context
[01:10:49] <ggm> Fred Baker. 3 slides. on renumbering
[01:11:21] <ggm> doc changes. general copy edits. note about cache with no timeout
[01:11:39] <ggm> how to not shoot yourself in the foot renamed/renumbered.
[01:11:48] <ggm> dyn DNS explanation expanded
[01:11:56] <ggm> next steps. seek review.
[01:12:13] <ggm> try procedure out. research proposals out there. being chased down.
[01:12:16] <ggm> "fingers crossed"
[01:12:19] <ggm> Erik
[01:12:25] --- bkhabs has left
[01:12:38] <ggm> sorry for not sending on ML. in context of multi6. constraints on consistency of reverse and fwd.
[01:12:42] <ggm> need additional steps
[01:12:59] <ggm> havent written down.
[01:13:01] <ggm> Fred. please do so
[01:13:05] <ggm> Rob Austein.
[01:13:21] <ggm> Erik. agree good to write. but first time in recorded history,.
[01:14:00] <ggm> Ralph Droms. larger problem. fundamental problems with ownership of reverse zone, roaming to diff admin domain. hard to understand how trust relationships using stateless autoconf can then do the update into the domain reverse owned by other admin. in which he resides. fundamental.
[01:14:13] <ggm> Erik. dont show up when do SITE renumber. site has authority.
[01:14:29] <ggm> 6to4 relay traffic. Pekka.
[01:14:35] <ggm> stats and observations.
[01:14:59] --- jakob has joined
[01:15:06] <ggm> AS1741 runnig pub 6to4 gw. nordic nets prime source. some north US. users
[01:15:16] <ggm> says something about relay deployment in USA.
[01:15:25] <ggm> another in CH. preferable to some acad. nets
[01:15:50] <ggm> 15min traffic measure 20-100kbit/sec peaks up to 10mbit/sec
[01:15:57] <ggm> 5-100 pps
[01:16:01] <ggm> peaks to 2000pps
[01:16:07] <ggm> traffic low, but peaks are valid not DDoS
[01:16:23] <ggm> no abuse reported. no DDoS attacks detected.
[01:16:35] <ggm> other 6to4 relays have reported,. 10-20mbit/sec worst
[01:19:28] --- ggm has left
[01:19:40] --- ggm has joined
[01:19:45] <ggm> probes growing.
[01:19:54] <ggm> hosts/nets excluding probes
[01:20:25] <ggm> around 15000/mo using g/w -widely distributed. half have their own /16 (diverging, from more than one /16)
[01:22:26] <ggm> low amount of apps. many hosts doing a lot of certain kinds of traffic ICMP important to assist v6
[01:22:35] <ggm> some using SMTP v6 to get round SMTP v4 blocks
[01:23:21] <ggm> comments/questions
[01:23:35] <ggm> Erik
[01:23:54] <ggm> so.. attracting traffic, coming over 4. or adv. 2002::/16
[01:23:57] <ggm> Pekka doing both
[01:24:16] <ggm> from one side, not the other, tells you something about the population of usage
[01:24:32] <ggm> TOny Hain. can tell you its in active use, using it right now. other end is 6to4 for me right now.
[01:25:05] <ggm> missing sequencing issue. nodes behind NAT using Teredo to get out, then switch. probably making assumptions about stuff 'not out there' but not seeing all the traffic, doing it direct. the ones might be doing it, do somehting else because they cant
[01:25:17] <ggm> Jordi disagree with only traffic between nodes.
[01:25:49] <ggm> I travel a lot. use different nets, GPRS. usually come to suprise come to expect, 80% get access via 6to4 relay. its happening. not enough to be very effective, longer delays, but its working.
[01:26:02] <ggm> dont agree its separating users.
[01:26:24] <ggm> Pekka. 6to4 can be used behind NAT, doing 41 forw. config 6to4 smartly enough to deal with..
[01:26:49] <ggm> Jordi. no nono. sometimes you attach to net, get public IP v4. reach 6to4 without configuring anything. not related to proto 41. in that case not behind NAT.
[01:27:11] <ggm> Pekka. what I said. 6to4 anycast in net. wherever you are you can reach one. close? diff q.
[01:27:40] <ggm> KRE. -when you look at TCP traffic through 6to4 relays, got any idea if being initiated by 6to4 or inbound? ie srevers or endhosts?
[01:27:57] <ggm> Pekka. dont think I analysed. feel significant % towards 6to4. does have servers
[01:28:41] <ggm> RObA. been running 6to4 at homesite. traffic patterns. leave it turns on all time. MTA uses it. DNS uses. bulk. I have to sit there and watch. slow. slower than SSH over v4. not fault, too many hops. not entirely suprised is what people do interactive vs bulk.
[01:29:39] <ggm> CHair. now back at scenarios analysis
[01:30:06] <ggm> propose way to go forward with transition mechanisms. table. may or may not be correct.
[01:30:10] <ggm> sorry, no URL for table
[01:31:44] --- jakob has left
[01:32:03] --- xag has joined
[01:32:21] <ggm> chairs discussing elements on a table of required/not-required issues with each scenario.
[01:32:44] <ggm> NAT traversal, Direct connect, ISP-Reg, Secure, Simple, Low Overhead
[01:33:09] --- sra has joined
[01:33:11] <ggm> range of MUST/Nice/Not-needed. you need to see the table., presumably its available somewhere
[01:36:57] --- moc has left
[01:36:59] <ggm> Qs to slides.
[01:37:11] <ggm> <?> define secure.
[01:37:42] <ggm> Pekka good question. mainly looking at how the proto has been specified, if it can open itself to be abused, make easier for someone else to attack the user of that mechanism
[01:37:55] <dthaler> let me try
[01:38:07] <ggm> comment. TSP supports user auth,. so can be considered to address ?
[01:38:13] <dthaler> nat direct isp secure simple low overhead implemented widely deply teredo Y Y N Y N N Y Y isatap N Y@ Y n/r R Y Y Y tsp Y N Y Y R N Y R step Y N Y Y y/r Y N N
[01:38:36] <ggm> well done. you have more patience than me. why dont the f^$#&*$ chairs just post a URL (sigh)
[01:39:18] <dthaler> y = yes, n = no, r = relative support, @ = does support intra-site
[01:39:19] <ggm> didnt thnk multiple vendors doing TSP.
[01:39:34] <ggm> Erik lets go forward. some notion of supporting authenticated tunnels.
[01:39:46] <ggm> Pekka yes. authtunnel could be done automaticailly with some impls on the table
[01:39:59] <ggm> eg ovr V4IPSEC
[01:40:16] <ggm> consider that isn't something users can deploy, at least most of them
[01:40:36] <ggm> Erik. is thre a notion about presenting credentials. or more anonymous. that distinguishment might be worth while
[01:41:39] <ggm> Q about previous slide. trying to understand unman1b
[01:41:47] <ggm> Tony. send to list
[01:41:51] <ggm> Pekka yes, just a proposal.
[01:42:00] <ggm> summary
[01:42:28] <ggm> obtained by combining matrices.
[01:42:36] <ggm> unman1a rquires teredo or something like that.
[01:42:41] --- tuy has joined
[01:42:49] <ggm> unman1b requires STEP or TSP. ISTAP not applicable because of net requirement
[01:43:04] <ggm> 3GGP1. STEP or ISTAP. nor no ISATAP if sec required
[01:43:23] <ggm> 3gpp2 can be filled by STEP or ISATAP. only ISATAP if direct connect MUST requirement
[01:43:45] <ggm> lowest common denominator. Teredo and STEP. with Teredo and TSP coming a bit behind
[01:43:56] <ggm> Dave. tend to agree with conclusion, but one bullet not quite accurate.
[01:44:25] <ggm> could argue teredo fits, had yes in not needed. need another alterntative. would indeed fix case two
[01:44:37] <ggm> Pekka doesnt fulfill simplicity requirement but useful addition
[01:44:40] <ggm> Agree.
[01:45:06] <ggm> Dave: multiple metrics of simple. dont know if I agree. but in one I do, not in others. for completeness
[01:45:15] <ggm> Chair room for error. done at 2am
[01:45:25] <ggm> Fed. Templin. what version of ISATAP draft looking at.
[01:45:36] <ggm> Chair latest -20 version. points before, covered.
[01:45:42] <ggm> Chair covered, doesn't work.
[01:45:45] <ggm> Fred lets make it work
[01:46:00] <ggm> Chair only way to make it work, need direct tunnelling, would be Teredo. walk the same path.
[01:46:42] <ggm> This is not final solution for analysis.
[01:46:53] <ggm> Fred looking at ISATAP without NAT traversal == subset of draft
[01:47:20] <ggm> Dave. I think graph is correct. not against -20 but against whats deployed. I am happy with graph
[01:47:27] <ggm> Qs to the WG.
[01:47:45] <ggm> does the proposal about inf/exp. publication make sense? -describing current implementations?
[01:48:56] <ggm> Tony Hain. seeking clarification. think clarified.
[01:49:08] <ggm> Chair publish as experimental now, continue to work.
[01:49:15] <ggm> Tony opportunity to comment before?
[01:49:44] <ggm> dont believe that we need to go to experimental to do Std doc. have lots published, and thn replaced if issues. we can document whats out there now, as stds track. dont have to go down exp path to publish
[01:49:47] <ggm> CHairs aware.
[01:49:55] <ggm> TOny not clear. seem to want to publish draft stds
[01:50:33] <ggm> Spencer Dawkins. confused earlier in session. Q about indiv. drafts matched current deployment or contained proposals for enhancements, dont want to publish right now. curious. talking about drafts which are these one, or other.
[01:50:37] <ggm> Chair see Q. valid Q. good Q.
[01:50:56] <ggm> chair not aware of status. some have continued working while blocked.
[01:51:06] <ggm> personal, not chair view, document whats out there now.
[01:51:22] <ggm> would be useful for community what is deployed now.
[01:51:47] <ggm> going to show of hands.
[01:51:53] <ggm> [mass of room yes]
[01:52:00] <ggm> [nem con]
[01:52:05] <ggm> ok 3.
[01:52:08] <ggm> chair rough consensus
[01:52:21] <ggm> Q2. is analysis going in right direction?
[01:52:55] <ggm> good show hands yes.
[01:53:15] <ggm> [nem con]
[01:53:18] <ggm> good consensus
[01:53:46] <ggm> Q3 unman requires Teredo. a) case. WG consensus to adopt that?
[01:53:49] <ggm> Jordi
[01:54:14] <ggm> I think probably interesting to see all the Qs before deciding. deciding some of the Q when know what is afterwards. not clear.
[01:54:33] <ggm> ok. now all Q revealed.
[01:54:53] --- bonninjm has joined
[01:54:54] <ggm> Dave. want to clarify. right direction but incomplete, need enterprise.
[01:55:19] <ggm> Bert. not sure.
[01:55:41] <ggm> think unman1A requires Teredo. could be better said Teredo is the only one which reaches unman1A requirement.
[01:56:06] <ggm> WG consensus for adopting Teredo. ... ERik
[01:56:53] <ggm> Erik. can say yes but have pricetags. these Q make sense. help winnow down set of things to build/specify but doesnt tell us about bigger picture.
[01:57:46] <ggm> when we say 'adopt teredo' it doesn't mean work ends
[01:58:10] <ggm> Tony on right direction. doing in room is wrong mechanism. this part shjould be done on list. or subgroup. package. put to list. lot of things
[01:58:30] <ggm> discussion of 'one mech or many' is whole different discussion.
[01:59:04] <ggm> Pekka. desireable to get down to one . get feel from WG opinions about importance ornot
[02:02:33] <ggm> DavidK Mailing List will decide
[02:02:49] <ggm> Might want to ask, start asking Q, talk about final Q later when all ideas in.
[02:02:57] --- memo56 has joined
[02:03:13] <ggm> enough work to adopt Teredo now. show hands.
[02:03:21] <ggm> [sparcer than before]
[02:03:25] <ggm> 9 hands.
[02:03:30] <ggm> who thinks not the time yet
[02:03:42] <ggm> [similarly sparce]
[02:03:57] <ggm> Davidk people who want discussed on ML.
[02:04:47] <ggm> people not saying much
[02:05:05] <ggm> erik. for me, practical matter, getting written down, spec as good as can be, right thing to do here.
[02:05:18] <ggm> what is the prize. make this stuff, minimize risk of partitioning the 6 net.
[02:05:51] <ggm> Tony
[02:06:10] <ggm> agree with eric. need to know price. not stuck
[02:06:25] <ggm> Pekka. after discussion. take to List
[02:07:33] <ggm> WG consensus on adopting Teredo
[02:07:39] <ggm> DavidK lets not do this now.
[02:07:42] <ggm> move on
[02:08:25] <ggm> Shaun. looking at diff transition mechanisms. experience we have, many engineers, literature not very extensive. about cost, complexity.
[02:08:30] <ggm> get us more documents.
[02:09:35] <ggm> does WG feel we have to find one solution
[02:09:51] <ggm> do we need more than one solution. fair Q to ask.
[02:10:05] <ggm> might be hybrid. not neccessarily existing one
[02:10:21] <ggm> Jordi. insist what I mentioned on monday. only one solution is not enough when you move
[02:10:39] <ggm> DavidK IDs have preference for minimal amount.
[02:10:47] <ggm> big cost to implement multiples. minimize is better
[02:12:33] <ggm> Jordi may be 4 solutions. maybe 6 or 7. not real life solutions for all situations. of course prefer all 4 improved, to be able to survive in any net. would be good
[02:13:27] <ggm> [sorry. I have to go shortly. if this meeting doesnt finish by 5:30 I will go -ggm]
[02:13:50] <ggm> Fred. clarify. must we find one solution? nebulous. possible to find one? answer is yes
[02:13:51] --- memo56 has left: Replaced by new connection
[02:14:35] <ggm> DavidK. last part of remark. like to minimize, not interested in solutions which solve all the worlds problems for high complexity
[02:15:13] <ggm> Pekka. want to know what WG thinks. 1, 2, 3, 4. personally think 4 would cover everything.
[02:15:49] <ggm> [ggm heckles. I want to go home]
[02:15:56] <ggm> Chair. now on list.
[02:16:19] <ggm> Q. cost analysis needed?
[02:18:23] <ggm> have to gosorry,. </B>
[02:18:33] <ggm> have to go. sorry. no more jabber from me here.
[02:18:35] --- ggm has left
[02:19:41] <dthaler> Quarantine Security Model up now draft-kondo-quarantine-overview-00.txt
[02:19:55] <dthaler> legacy firewalls don't support ipv6, how to deal with
[02:20:20] <dthaler> 3 step quarantine model
[02:20:36] <dthaler> 1. quarantine security credentials of node when it is connected to network
[02:20:49] <dthaler> 2. connect the node to a different network based on the result
[02:20:54] <dthaler> (missed 3rd step)
[02:22:14] --- rei has left
[02:25:40] --- gih has joined
[02:27:04] --- gih has left
[02:28:22] --- jm has left
[02:28:26] --- tskj has left: Disconnected.
[02:28:44] --- duidsaki has left
[02:29:09] --- xag has left
[02:29:16] --- sakai has left
[02:34:54] --- sra has left: Disconnected
[02:34:54] --- gih has joined
[02:35:10] --- gih has left
[02:37:26] --- AWGY has left: Disconnected
[02:37:41] --- tuy has left
[02:40:19] --- bonninjm has left: Disconnected
[02:40:35] --- arifumi has left: Disconnected
[02:47:00] --- dthaler has left: Disconnected
[02:53:10] --- Bob.Hinden has left: Disconnected
[03:02:16] --- dlpartain has left
[03:03:03] --- shane_ripe has left: Disconnected
[04:18:02] --- bonninjm has joined
[04:24:28] --- bonninjm has left: Disconnected
[04:28:05] --- tskj has joined
[04:37:55] --- Bob.Hinden has joined
[04:38:32] --- AWGY has joined
[04:43:15] --- arifumi has joined
[04:49:08] --- AWGY has left
[04:51:34] --- arifumi has left
[05:38:49] --- bonninjm has joined
[06:18:48] --- Bob.Hinden has left
[06:40:19] --- tskj has left
[07:59:14] --- LOGGING STARTED
[08:00:58] --- bonninjm has joined
[09:28:57] --- bonninjm has left: Disconnected