[03:55:26] mawatari joins the room [04:43:50] Warren Harrop joins the room [04:52:41] cbyrne joins the room [04:53:26] rbonica joins the room [04:54:21] frodek joins the room [04:55:39] dromasca joins the room [04:57:45] Mohsen joins the room [04:58:17] Does anybody have the URL of this lovely cartoon plz? [05:01:46] Simon Perreault joins the room [05:01:51] I will behave well in order to deserve the URL for this cartoon [05:03:07] fdupont joins the room [05:03:50] dudisaki joins the room [05:03:56] Dave Thaler joins the room [05:03:57] joel jaeggli joins the room [05:04:30] ya dong - snisp and cnnog introduction [05:05:04] breathing on the mic makes it hard to hear [05:05:06] audio distorting badly [05:05:45] hope that's better [05:06:03] ꈲ joins the room [05:06:37] otter_denver joins the room [05:09:00] Colman Ho joins the room [05:11:24] Bjoern A. Zeeb joins the room [05:13:45] Joonhyung Lim joins the room [05:14:33] tomtaylor joins the room [05:15:55] fred - survey disussion [05:16:29] fisher joins the room [05:16:33] brian capenter - framework for ipv4 transition scenaiors [05:17:34] assumptions there will be a series of documents describing transition scenarios, aimed at isps but not specifici scearios [05:17:47] assuption is you've deviced to deploy ipv6 [05:18:02] kbransom joins the room [05:18:18] Tatsuji Ue joins the room [05:18:40] recomendations - network model, how componetns fit together, specify scope [05:19:11] describe coexistence cover considers for legacy operation [05:19:19] james.huang joins the room [05:19:22] include security consideration [05:19:42] bashi joins the room [05:19:43] every service provider is differenct [05:20:22] jonne s - I went through this same process some years ago as wg and it wasn't pleasant [05:20:33] scenarios become quite high level [05:20:43] we spent years on transition documents. [05:20:56] nmm joins the room [05:21:14] all the work that has come after that has come in spite of rather than because of those documents [05:21:51] this has job secuirty facto but time is not usefully expended [05:22:03] kami joins the room [05:22:39] brian - I take your point but isps that don't come to the ietf but they do read rfcs [05:23:24] jonne - writing a book is perhaps more useful becasue you don't have to agree with anyone else [05:23:39] moison S : I support this document [05:24:52] kurtis - they're talking past each other [05:25:15] if oppertars at the ietf are any idication then there isn't much consensus to go on [05:26:21] basaraj patil - many operators do come to ietf, roadmap isn't going to signficantly help thne because they're all different [05:26:34] marla azinger [05:27:07] - discusted with the personal tone [05:27:27] I support this [05:27:48] in the north american region there is an issue of where to get document [05:28:26] jonne s - how do use them and what they're good for is [05:28:28] fine [05:29:25] randy bush - my name is brian carpenter [05:30:23] if the documents describing a transition mechanism doesn't describe when and how a transition mechanism works fix the documents [05:30:45] victor k - we have a lot of small operators that need guidance [05:31:01] I feel there is value here [05:32:06] from the guidance perspective we have something to offer [05:32:20] citor - ipv4-v6 cable use cases [05:32:27] victor k [05:32:41] kami leaves the room [05:35:13] is this useful [05:36:10] ed jankiwitz sri - even though this won't proviade all the anwsers for all operators it will provide some the analysis. I appreciate what rrandy sent about fixing the documents. [05:36:24] I do support these documents [05:37:05] as the number of operators working on prefix advertisement is signficant that problem wasn't previously addressed [05:37:06] tomtaylor leaves the room [05:37:25] tom taylor - mobile use case [05:37:42] drafts are unchanged since september but we got lots of comments in between [05:38:07] what useful can be said about mobile given what's already been done [05:38:47] wmhaddad joins the room [05:38:49] draft korhenen v6ops 3gpp eps [05:39:04] draft ietf v6ops mobile ... [05:39:15] mobile lte arch [05:39:40] kami joins the room [05:39:49] euijong hwang joins the room [05:42:08] cbyrne leaves the room [05:42:45] changes to assumptions in rfc 4215assumptions [05:45:26] geir joins the room [05:48:13] becarpenter joins the room [05:48:15] Tina TSOU joins the room [05:48:32] jari arko - you can tunnel but you shouldn't add tunnels over tunnels [05:48:55] what is the role of this work vs other work being done in 3gppp some things are dated [05:49:19] 3gpp has already decided stateful nat64 is the way the go [05:49:30] what do we add to this vs 3gppp [05:50:04] ? - to jari's point closer linkage to certain 3gppp documents would certainly help [05:52:43] ? [05:53:19] jonne - if we use the time to do this here when it's being done elsewhere it's a wasted effort [05:54:07] if we don't understand everything then the guidance will be harmful 6rd over 3gpp would be harmful [05:55:05] jari arko - we had some cooperation if we do something we need to be very clear on what are we doing [05:56:12] duan.chen joins the room [05:56:13] fred - converstation wit hte autherois of these three documents on what we're trying to achive and what the expected outcome is [05:56:38] tomtaylor joins the room [05:57:18] present draft huang and draft yang [06:04:36] duan.chen leaves the room [06:09:36] brian carpenter - been looking at this and the previousl documents why seperating the scenario and transition guide. [06:10:50] Bill joins the room [06:10:55] joel j - observation - growth swamps the legacy subscribers [06:11:23] small number of observations [06:12:14] jankewitz - ipv6 bibliography abut as long as we have ipv6 widely deployed before we run out of ipv6 addresses. [06:12:26] it may be time to prepare to panic [06:13:10] growth will be impedded unless we have these coping mechanisms in place. [06:13:48] nobdy was paying attention to coexistance and transition mechanim, but now we're all back here. [06:15:20] three laws of coexistance mechanisms [06:15:24] do no harm [06:15:28] keep it simple [06:15:35] move towards native ipv6 [06:16:22] focus on the point of need [06:16:33] wmhaddad leaves the room [06:16:42] Simon Perreault leaves the room [06:19:15] lee howard - somebody asked what can we do do to help, help yes [06:19:27] er less [06:19:38] jari arko - ? [06:19:48] "Help less" -- referring to the excessive volume of documents [06:20:04] brian for a while you should maintain it as a webpage as an rfc it will be out of date [06:22:21] fred - wshould we put this on the ietf wiki [06:23:11] gang chep - nat64 cpe opertation [06:23:58] Bill leaves the room [06:24:08] lee howard - previous topic , rir's and wkimedia have wiki's lets use therer [06:24:11] 's [06:28:53] - jari arko is the only thing you're doing different that you don't have a dns mapping [06:29:17] I think that's a valid deployment case, I think it's in scope for the behave document [06:29:29] Bill joins the room [06:30:10] qiong sun ivi/divi [06:35:56] bashi leaves the room [06:36:57] Warren Harrop leaves the room [06:38:08] nmm leaves the room [06:39:12] fred what input would you like from the the group [06:39:58] randy bush - one line management of and by ipv6 [06:40:19] all this 10,000 transition pieces what I want is feature parity [06:40:24] the rest is all noise [06:40:53] swb joins the room [06:41:03] le howard -procedural point corretly identify yourself [06:41:43] fred - any concerns you have about china telcom's migration ot v6 you can put to bed [06:42:31] keeping their v4 network operational is their problem [06:43:08] otter_denver leaves the room [06:43:26] fred - a comment on the class of applications - specific applications in china which have v4 literals [06:44:27] tony hain - my question is this really interformational document or there something embedded in this that says working group we need to do something else. [06:48:07] christ lilenstolpe [06:48:20] - presenting address request [06:49:14] the correct word is impugnment [06:52:56] geir leaves the room [06:54:00] chris - telstra tests indicated lack of clean address space. [06:54:44] ? - why must register public ipv4 space from iana rather than cut off address for a block you already own [06:55:48] chris - do know in china you use this using 192.168 [06:57:45] cancan wong was previous speaker [06:58:38] tomtaylor leaves the room [06:58:46] tim shepherd - naive question asking for a /10 rather than a /8 [07:00:11] wes george - things that contradict your justification - use the top 10 cpe as an example [07:00:25] we need some actual data to backup that asertion. [07:00:52] not saying there isn't the possibility fo a technical justification but there's a high threshhold [07:01:27] what you are actually asking for is addresses for the time between runout and the time you have a solution [07:01:49] tomtaylor joins the room [07:02:21] dan romascanu - 3 discusses basically say don't do this [07:02:26] on previous draft [07:02:47] 5 potentia l discusses on this draft [07:03:54] chris - the problem is daising chaining nats is exactly [07:04:22] jari - we had this document from marla which says this is is a bad idea [07:05:23] Tatsuji Ue leaves the room [07:06:07] timing doesn't really matter, technical implications of breakage. is what jari [07:07:06] susanne wolf - I would hope the iesg members are in this room. [07:07:11] this is a bad Idea [07:07:15] I'd like a pony [07:08:30] we'd played around and we're going to have to do something [07:08:44] moisen - this is just unfair can we trust you [07:09:50] chris - there's no project that doesn't get out the gate [07:10:13] without v6 support [07:11:14] lee howard - nat444 conumser electronicsdevice that don't have a v6 stack is a case where this does work [07:11:35] marla - author of one iesg reviewers [07:11:55] we laid out with leo vegoda what the conesquences of one of these documents. [07:12:03] fisher leaves the room [07:12:42] the choice of going to iana for a block the whole internet world change when transfer proposals. [07:12:58] @joel: for the minutes: s/moisen/mohsen [07:13:58] it never will happen if we could gotten /8 from an rir we would have done it. not true [07:15:54] simon - there are other opertors who are not listed here who are thing about this as a fair request [07:16:26] Jacky Yao (Health Yao) joins the room [07:16:27] dave thaler - two point in your netowrk you might have control over your cpes not everyone odoes [07:16:52] if cpe is one that implents 6to4 then the connevity will break using 6to4 [07:17:01] netpnp and up pnp will break [07:21:03] vpn vendors. [07:21:17] chris donnely - spolution shared /10 [07:22:30] wes george - if you could justify this you would ahve already done it - has to do with availability [07:23:17] we we are considering swappng [07:23:30] randy bush point dave was making was very germain [07:24:08] swb leaves the room [07:24:08] Dave Thaler leaves the room [07:24:16] is soon as this space is sent aside other users will use it. [07:24:35] For once, I agree 100% with Randy! [07:24:38] frodek leaves the room [07:24:51] tim shepherd I think oging forward nat444 as much as I dislike it is going to happen [07:26:24] one is to do nat444 iwith the new /10 that other is to do nat444 with 10.192.0.0/10 in middle the middle of a nat444 willl do less harm, but options are better than running out and getting more address space. [07:26:55] I don't thing another 1918 is another option at this point. [07:27:05] Dave Thaler joins the room [07:28:01] I wish somebody had the data. [07:28:46] i think I agree with Tim [07:29:13] redigger volk - speaking very much as a private network citizen - I'd to take another look at the arguemetns as to how the addressspace is administrators. [07:30:27] I'm getting to the question is there any rir where a service provider can justify this [07:30:40] if that's the case than only one needs top do it. [07:31:16] rbonica leaves the room [07:31:30] it might actually lead to a less heated perception of what needs to be done. [07:32:24] jari arko - the mechanics of what the allocation is actually done isn't germain to the larger question of whether it should be done. [07:34:08] Tina TSOU leaves the room [07:35:53] tomtaylor leaves the room [07:37:14] What redigger volk explains why said I was sure that Operators will end in getting that space (/10 or even a /8) in a way or another (with or without IETF support), and that's UNFAIR. And btw, the argument "it's urgent and we don't have CPEs IPv6-ready off the shelf" does not convince me. My counter-argument: the majority of operators should have put pressure earlier on CPE vendors in order to get CPEs upgraded in a timely manner. CPEs vendors had said for years, there was no demand from ISPs (a nice well-known chikken-and-egg problem). Too sad a situation! [07:37:30] fred - rest of the world uses nat444 how do they do that [07:42:08] Joonhyung Lim leaves the room [07:42:41] Jonne Soininen joins the room [07:42:54] Joonhyung Lim joins the room [07:43:06] randy busy - not really an ietf prefix freak [07:43:11] process [07:43:24] quite definenetly no-consesu here [07:43:41] I think it would actually be valauble to go through the entire space [07:44:18] willing to accept smaller blocks then there might be best practices associated with this. [07:44:39] from a technical perspective we can use multiple aggregates [07:45:03] this sucks it's just a question of how much [07:45:54] fred - I'm the process wonk - produce consensus where none exists [07:46:19] I want to run this is a hum don't run to the mikes [07:47:34] question - if we fine no part of rfc 1918 pool will work would the group support having the operators go get a block. [07:48:23] wes - the reason I hummed against it was the other considerations raised plus the research [07:50:18] I think there's data on two fronts. with rfc 1918 prefix. I blieve that you as provider might feel pain becuase you do that and you might cause others pain as a product of this. [07:50:30] frad -we'll consider the topic closed for the moment. [07:50:48] done [07:50:53] joel jaeggli leaves the room [07:51:02] dudisaki leaves the room [07:51:04] dromasca leaves the room [07:51:08] Dave Thaler leaves the room [07:51:08] Joonhyung Lim leaves the room [07:51:13] euijong hwang leaves the room [07:52:08] Bjoern A. Zeeb leaves the room [07:52:08] Colman Ho leaves the room [07:52:32] kami leaves the room [07:52:40] Joonhyung Lim joins the room [07:52:49] Mohsen leaves the room [07:53:08] Jacky Yao (Health Yao) leaves the room [07:53:10] Jacky Yao (Health Yao) joins the room [07:53:19] Bill leaves the room [07:53:38] Joonhyung Lim leaves the room [07:53:46] Bill joins the room [07:53:48] Joonhyung Lim joins the room [07:55:38] james.huang leaves the room [07:59:39] becarpenter leaves the room [08:01:08] Joonhyung Lim leaves the room [08:02:33] Jonne Soininen leaves the room [08:03:07] kbransom leaves the room [08:03:47] fdupont leaves the room: Computer went to sleep [08:08:39] ꈲ leaves the room [08:23:33] joel jaeggli joins the room [08:31:39] Jacky Yao (Health Yao) leaves the room [08:52:17] becarpenter joins the room [08:52:39] becarpenter leaves the room [10:18:13] joel jaeggli leaves the room [10:22:25] joel jaeggli joins the room [10:23:49] mawatari leaves the room [10:24:24] Bill leaves the room [10:26:12] joel jaeggli leaves the room [10:57:44] ꈲ joins the room [11:21:10] ꈲ leaves the room [11:21:16] ꈲ joins the room [11:44:08] james.huang joins the room [12:03:34] joel jaeggli joins the room [12:08:11] kbransom joins the room [12:08:11] kbransom leaves the room [12:47:50] Colman Ho joins the room [12:48:28] Colman Ho leaves the room [13:08:14] frodek joins the room [13:08:58] frodek leaves the room [14:16:41] james.huang leaves the room [14:25:26] james.huang joins the room [14:35:11] james.huang leaves the room [14:48:15] james.huang joins the room [15:13:41] james.huang leaves the room [16:33:54] joel jaeggli leaves the room [23:28:48] ꈲ leaves the room