[{"author": "\u00c9ric Vyncke", "text": "I will relay the questions to the mike if you are unable to ask questions over Meetecho<br/>", "time": "2022-03-22T13:31:36Z"}, {"author": "\u00c9ric Vyncke", "text": "Simply prefix your question with \"Mic:\"<br/>", "time": "2022-03-22T13:31:44Z"}, {"author": "Donald Eastlake", "text": "sound level seems a bit low<br/>", "time": "2022-03-22T13:34:40Z"}, {"author": "Tony Li", "text": "Getting a lot of crackling<br/>", "time": "2022-03-22T13:38:10Z"}, {"author": "Paolo Navarretta", "text": "Dear Seth, can you please try to move the mic a bit further? It is a bit distorted due to the proximity effect right now<br/>", "time": "2022-03-22T13:41:10Z"}, {"author": "Dino Farinacci", "text": "still crackling<br/>", "time": "2022-03-22T13:42:37Z"}, {"author": "Tony Li", "text": "Yes, but majority is irrelevant. You need ubiquity.<br/>", "time": "2022-03-22T13:44:59Z"}, {"author": "Jody Beck", "text": "It depends what is being proposed by making 240/4 usable. If it is meant to be public address space it needs to work everywhere before it can be used anywhere and there is significant effort involved that could be spent working on IPv6. If it is meant to be something like private address space the effort is different to support it because it''s generally within controlled environments.<br/>", "time": "2022-03-22T13:49:59Z"}, {"author": "Dave Thaler", "text": "@Jody even \"private\" space (like net 10) in practice can be fairly public when used by a large ISP behind a CGN<br/>", "time": "2022-03-22T13:51:30Z"}, {"author": "Tony Li", "text": "We used to burn a /8 every month.<br/>", "time": "2022-03-22T13:52:06Z"}, {"author": "\u00c9ric Vyncke", "text": "@Seth, sorry I left the queue as I was not expecting a reply...<br/>", "time": "2022-03-22T13:52:25Z"}, {"author": "Lars Eggert", "text": "i find it a bit confusing to see this expressed as a protocol \"fix\" to ipv4 - as if we had for example discovered a deadlock possibility in the protocol state machine - when in reality this seems to be all about de-icing some address space.<br/>", "time": "2022-03-22T13:53:19Z"}, {"author": "Philipp Tiesel", "text": "I would me very sympathetic to designate 240/4 for private reverse NAT64 use-cases to make v6-only services available within RFC1918 environments. Still, this is no \"fix\" but a designation.<br/>", "time": "2022-03-22T13:53:43Z"}, {"author": "Dave Thaler", "text": "+1 to Lars<br/>", "time": "2022-03-22T13:54:11Z"}, {"author": "\u00c9ric Vyncke", "text": "+1 indeed, my original Q about IP addressing or IP fixing, which was not really answered<br/>", "time": "2022-03-22T13:55:04Z"}, {"author": "Dave Thaler", "text": "\"fix\" implies something is \"broken\", so maybe the discussion should be about \"what exactly is broken\" (maybe that's the definition of \"serious\"?)<br/>", "time": "2022-03-22T13:55:31Z"}, {"author": "Jari Arkko", "text": "+1 Jen<br/>", "time": "2022-03-22T13:56:45Z"}, {"author": "Bob Hinden", "text": "+1 Jen<br/>", "time": "2022-03-22T13:57:02Z"}, {"author": "Philipp Tiesel", "text": "+1 Jen, still, de-icing large blocks of private address space is in fact something that would help many large companies who completely depleted all private address space in IPv4 and have a hard time to move to IPv6.<br/>", "time": "2022-03-22T13:57:51Z"}, {"author": "Tony Li", "text": "Remote audio is good<br/>", "time": "2022-03-22T13:58:19Z"}, {"author": "Ole Tr\u00f8an", "text": "I don't think IETF should choose a path of hindering evolution of IPv4 in the name of IPv6 deployment.<br/>", "time": "2022-03-22T13:59:40Z"}, {"author": "Lars Eggert", "text": "an mtu is not necessarily the unit of retransmission though.<br/>", "time": "2022-03-22T13:59:48Z"}, {"author": "Lars Eggert", "text": "transport protocols are free to rtx whatever lost bytes ranges in whatever packets they deem useful<br/>", "time": "2022-03-22T14:00:24Z"}, {"author": "Lars Eggert", "text": "when there is loss because of pmtud probing, you explicitly do not want to rtx that same too large mtu<br/>", "time": "2022-03-22T14:00:54Z"}, {"author": "Jim Reid", "text": "@Ole, ipv4 is largely a dead end. IMO there's nothing&nbsp;&nbsp;there to evolve.<br/>", "time": "2022-03-22T14:01:03Z"}, {"author": "Tony Li", "text": "@Jim Baloney.<br/>", "time": "2022-03-22T14:01:16Z"}, {"author": "Tony Li", "text": "We've been evolving IPv4 routing the whole time.<br/>", "time": "2022-03-22T14:01:30Z"}, {"author": "Jody Beck", "text": "@Jim In many cases the need for IPv4 isn't based on unwillingness to do IPv6 but rather that they both need to co-exist for a significant period of time. Dual stack and such.<br/>", "time": "2022-03-22T14:01:47Z"}, {"author": "Tony Li", "text": "Look at the streams of changes in LSR and IDR.<br/>", "time": "2022-03-22T14:01:49Z"}, {"author": "Jim Reid", "text": "Fair enough Tony. But are these changing the core IPv4 spec?<br/>", "time": "2022-03-22T14:02:30Z"}, {"author": "Tony Li", "text": "Nothing that's been proposed is changing the core IPv4 spec.<br/>", "time": "2022-03-22T14:02:50Z"}, {"author": "Ole Tr\u00f8an", "text": "GSO/GRO is such a horrid hack though... on the other hand this may be too. ;-)<br/>", "time": "2022-03-22T14:09:36Z"}, {"author": "Mike Bishop", "text": "It's basically extending those optimizations into the network.<br/>", "time": "2022-03-22T14:10:02Z"}, {"author": "Mike Bishop", "text": "(Hack or not.)<br/>", "time": "2022-03-22T14:10:12Z"}, {"author": "Fred Templin", "text": "Yes, the point of IP parcels is to extend the optimizations into the network.<br/>", "time": "2022-03-22T14:13:34Z"}, {"author": "Fred Templin", "text": "Also, to Lars' question, GSO/GRO currrently stop at 64K maximum-size. IP Parcels goes all the way up to 4MB.<br/>", "time": "2022-03-22T14:14:16Z"}, {"author": "Tony Li", "text": "@Fred: Given that IEEE won't even standardize Jumbo Frames, how would we ever get to an even higher MTU?<br/>", "time": "2022-03-22T14:14:21Z"}, {"author": "Fred Templin", "text": "Using the adaptation layer with AERO/OMNI - this takes it up a layer in the stack, and the IEEE links never see jumbos.<br/>", "time": "2022-03-22T14:15:02Z"}, {"author": "\u00c9ric Vyncke", "text": "? so we glue packets together and then fragment the result ? What did I fail to understand ?<br/>", "time": "2022-03-22T14:15:41Z"}, {"author": "Tony Li", "text": "Why this is a smashing good idea.<br/>", "time": "2022-03-22T14:16:25Z"}, {"author": "Fred Templin", "text": "Think of it as more efficient packaging at each layer. And, if IP fragmentation is needed at the lowest layer then that is no problem because IP fragmentation and reassembly is *fast*.<br/>", "time": "2022-03-22T14:16:49Z"}, {"author": "BEHCET SARIKAYA", "text": "I am disconnected, now back<br/>", "time": "2022-03-22T14:17:03Z"}, {"author": "Dirk Trossen", "text": "I would want to come back on the adoption question and wonder if the chairs could let the authors know what kind of indication/exchange is needed beyond the amount of emails we have seen in the run-up to the IETF113?<br/>", "time": "2022-03-22T14:24:50Z"}, {"author": "Lars Eggert", "text": "are there any \"open solutions\" here? isn't it all proprietary?<br/>", "time": "2022-03-22T14:25:04Z"}, {"author": "Dirk Trossen", "text": "-&gt; this relates to the PS/GA draft, in case that wasn't clear<br/>", "time": "2022-03-22T14:25:19Z"}, {"author": "Tony Li", "text": "I know of two projects in this area: Starlink and Kuiper. Both proprietary.<br/>", "time": "2022-03-22T14:26:00Z"}, {"author": "\u00c9ric Vyncke", "text": "+ OneWeb<br/>", "time": "2022-03-22T14:26:15Z"}, {"author": "Tony Li", "text": "So is anyone here from one of those projects? If not, how would we ever deploy work? And if we can't deploy it, why would we do the work?<br/>", "time": "2022-03-22T14:28:04Z"}, {"author": "Lars Eggert", "text": "so this is then basically a thought experiment? \"what would i do if i had a few K satellites in leo space\"?<br/>", "time": "2022-03-22T14:28:19Z"}, {"author": "Tony Li", "text": "I would call it 'academic'.<br/>", "time": "2022-03-22T14:29:08Z"}, {"author": "\u00c9ric Vyncke", "text": "Indeed, but still interesting<br/>", "time": "2022-03-22T14:29:22Z"}, {"author": "Lars Eggert", "text": "i wouldn't but i would have called myself an academic at some point in my life, so maybe that's why :-)<br/>", "time": "2022-03-22T14:29:32Z"}, {"author": "Tony Li", "text": "Why not use an MPLS node label?<br/>", "time": "2022-03-22T14:30:47Z"}, {"author": "Lars Eggert", "text": "all these movements are 100% predicatble and so routing can be precomputed?<br/>", "time": "2022-03-22T14:32:46Z"}, {"author": "Tony Li", "text": "If things work as expected.<br/>", "time": "2022-03-22T14:33:02Z"}, {"author": "Benjamin Schwartz", "text": "98% predictable<br/>", "time": "2022-03-22T14:33:11Z"}, {"author": "\u00c9ric Vyncke", "text": "indeed, no need for IGP hellos just good time<br/>", "time": "2022-03-22T14:33:12Z"}, {"author": "Tony Li", "text": "It's NOT the SPF computation that's the problem, it's the adjacency flap.<br/>", "time": "2022-03-22T14:33:53Z"}, {"author": "\u00c9ric Vyncke", "text": "now quality of link can vary whether Sun is in the back of the transmitter (my guess) but again predictable<br/>", "time": "2022-03-22T14:33:56Z"}, {"author": "Tony Li", "text": "Looks like an LSP to me...<br/>", "time": "2022-03-22T14:36:05Z"}, {"author": "BEHCET SARIKAYA", "text": "I think Gorry is asking if it is Starlink?<br/>", "time": "2022-03-22T14:38:45Z"}, {"author": "Jens Finkh\u00e4user", "text": "Lin Han: I actually had a question, but was too slow: how does your work relate to e.g. the CCSDS standards and stack already in use in the space industry?<br/>", "time": "2022-03-22T14:41:17Z"}, {"author": "\u00c9ric Vyncke", "text": "\"disconnecting cable\" or \"cutting undersea fibre\" ?<br/>", "time": "2022-03-22T14:47:32Z"}, {"author": "\u00c9ric Vyncke", "text": ";-)<br/>", "time": "2022-03-22T14:47:38Z"}, {"author": "Mike Bishop", "text": "A.k.a. \"disconnecting a really big cable\"<br/>", "time": "2022-03-22T14:48:15Z"}, {"author": "\u00c9ric Vyncke", "text": "Really <a href=\"https://datatracker.ietf.org/doc/html/rfc3514\" rel=\"nofollow\">https://datatracker.ietf.org/doc/html/rfc3514</a> does not work for bad/good ? ;-)<br/>", "time": "2022-03-22T14:49:31Z"}, {"author": "Tony Li", "text": "Ok, that's an exception.<br/>", "time": "2022-03-22T14:49:54Z"}, {"author": "Donald Eastlake", "text": "I was just going to point out how the presentation ignores the evil bit.<br/>", "time": "2022-03-22T14:50:01Z"}, {"author": "\u00c9ric Vyncke", "text": "(I read the slides before so I had a head start)<br/>", "time": "2022-03-22T14:50:20Z"}, {"author": "Tony Li", "text": "No one has implemented an Evil bit ACL yet.<br/>", "time": "2022-03-22T14:50:22Z"}, {"author": "Lars Eggert", "text": "@tony: <a href=\"https://lists.freebsd.org/pipermail/cvs-all/2003-April/001098.html\" rel=\"nofollow\">https://lists.freebsd.org/pipermail/cvs-all/2003-April/001098.html</a><br/>", "time": "2022-03-22T14:56:16Z"}, {"author": "Mallory Knodel", "text": "Great points, Ted.<br/>", "time": "2022-03-22T14:57:18Z"}, {"author": "Tony Li", "text": "@Lars: I sit educated. Thanks! lol<br/>", "time": "2022-03-22T14:58:21Z"}, {"author": "Olaf Kolkman", "text": "Ted referred to Internet Society work. See e.g. here for one of these assessments: <a href=\"https://www.internetsociety.org/resources/doc/2022/quick-analysis-the-impact-of-efforts-to-disconnect-russia-from-the-internet/\" rel=\"nofollow\">https://www.internetsociety.org/resources/doc/2022/quick-analysis-the-impact-of-efforts-to-disconnect-russia-from-the-internet/</a><br/>", "time": "2022-03-22T15:00:16Z"}, {"author": "Olaf Kolkman", "text": "Also, the Internet Society bridged their work with the work in RFC7754 (I was not ISOC staff when coauthoring it, and worked with ISOC staff at the time)<br/>", "time": "2022-03-22T15:01:30Z"}, {"author": "Melchior Aelmans", "text": "Thanks for sharing the link Olaf!<br/>", "time": "2022-03-22T15:01:49Z"}, {"author": "Donald Eastlake", "text": "Suggest that RFC 3675 might be relevant. It's easy to find as it is the only RFC with \"sex\" in its title :grinning:<br/>", "time": "2022-03-22T15:01:59Z"}, {"author": "Olaf Kolkman", "text": "I have to say I am in agreement with Ted and Alissa.<br/>", "time": "2022-03-22T15:03:36Z"}, {"author": "BEHCET SARIKAYA", "text": "Rudiger, this is not a \"paper\"<br/>", "time": "2022-03-22T15:04:33Z"}, {"author": "Jim Reid", "text": "An IETF document on this topic will have unintended consequences. This needs a lot of policy context IMO and that's best done elsewhere. Public policy and IETF don't mix well.<br/>", "time": "2022-03-22T15:11:19Z"}, {"author": "Luigi Iannone", "text": "I agree with Jim.<br/>", "time": "2022-03-22T15:13:55Z"}, {"author": "Jody Beck", "text": "+1 Jim<br/>", "time": "2022-03-22T15:14:20Z"}, {"author": "Mallory Knodel", "text": "Clarity: Not in favour of the draft moving forward here or in HRPC.<br/>", "time": "2022-03-22T15:16:29Z"}, {"author": "Rich Salz", "text": "A purely tech paper on \"weaknesses in Internet architecture\" could be worthwhile.<br/>", "time": "2022-03-22T15:16:38Z"}, {"author": "\u00c9ric Vyncke", "text": "Thankz to the authors and the intarea participants for the interesting and respectful discussion.<br/>", "time": "2022-03-22T15:17:01Z"}, {"author": "Rich Salz", "text": "What's the worry, that some bad people or state actor will use this stuff? And if we don't publish an RFC they'll not figure it out?<br/>", "time": "2022-03-22T15:17:16Z"}, {"author": "Dirk Trossen", "text": "+1 with Jim<br/>", "time": "2022-03-22T15:17:21Z"}, {"author": "Mallory Knodel", "text": "draft-irtf-pearg-censorship would include scope for ip geoblocking, so asking for a review there before it goes into LC. depends on the contrib<br/>", "time": "2022-03-22T15:17:21Z"}, {"author": "Olaf Kolkman", "text": "These type of of documents are inherently not disinterested.<br/>", "time": "2022-03-22T15:18:11Z"}, {"author": "Alissa Cooper", "text": "@Rich I don't think anyone suggested they won't figure it out.<br/>", "time": "2022-03-22T15:18:20Z"}, {"author": "Rich Salz", "text": "Ok. Came late to this session, but coming from the security world any time I hear \"don't disclose\" I get worried.<br/>", "time": "2022-03-22T15:19:22Z"}, {"author": "Olaf Kolkman", "text": "In the policy space people are very attuned to also noticing what is not said. And in this document a lot of things are not being said - for good reasons I think - I do not doubt the good intentions of the authors.<br/>", "time": "2022-03-22T15:19:43Z"}, {"author": "Jody Beck", "text": "I think the analogy of a doctor taking a hippocratic oath and writing a howto about shooting your neighbor was on point. It's not that it can't still happen or won't but is it the role of the IETF to provide the guidance?<br/>", "time": "2022-03-22T15:21:08Z"}, {"author": "Dirk Trossen", "text": "@Jody agree; do we need to advocate WCPs (worst current practices)?<br/>", "time": "2022-03-22T15:23:46Z"}, {"author": "Ted Hardie", "text": "Bonus points:&nbsp;&nbsp;show all the bits that are non-continental France on this map, and then realize that they are all in RIPE because France is.<br/>", "time": "2022-03-22T15:24:45Z"}, {"author": "Jim Reid", "text": "@Rich, the bad actors will already have figures this out. A doc that can be misrepresented as \"IETF supports censorship\" will undermine the efforts by ISOC, Article 19, EFF, etc to reduce these forms of Internet breakage.<br/>", "time": "2022-03-22T15:26:43Z"}, {"author": "\u00c9ric Vyncke", "text": "@Jim this is the reason why I repeated the clear statemement of the authors 'individual contribution'.<br/>", "time": "2022-03-22T15:28:03Z"}, {"author": "\u00c9ric Vyncke", "text": "Corollary, really unsure whether this I-D should be adopted...<br/>", "time": "2022-03-22T15:28:28Z"}, {"author": "Jim Reid", "text": "We are in violent agreement&nbsp;&nbsp;Eric.<br/>", "time": "2022-03-22T15:28:50Z"}, {"author": "Rich Salz", "text": "I wasn't here so you don't have to convince me (and you won't, but that's okay).&nbsp;&nbsp;\"Someone might mis-interpret\" could be corrected with a title change like I suggested.&nbsp;&nbsp;But enough, WG made it's decision and I can't complain because I was elsewhere :)<br/>", "time": "2022-03-22T15:29:01Z"}, {"author": "Lars Eggert", "text": "what ben is saying<br/>", "time": "2022-03-22T15:30:41Z"}, {"author": "Jim Reid", "text": "Rich, I sometimes swim in the toxic swamps where this misrepresentation can and does happen. [I do this so you don't have to.:grinning:] Changing the title won't make a difference.<br/>", "time": "2022-03-22T15:31:53Z"}, {"author": "\u00c9ric Vyncke", "text": "Thank you all<br/>", "time": "2022-03-22T15:32:25Z"}]