Based in Rotterdam, The Netherlands
Articles
Likes on articles
Andrew worked as a network and software engineer in the telecom industry for 15 years. Then in 2013 he decided to migrate away from being an engineer, so he got a Masters degree in Technology and Public Policy. Since then he has been working for ICANN supporting the technical community as a researcher and writer. He supported the Security and Stability Advisory Committee for eight years. Now he supports the Root Server System Advisory Committee, the Root Zone Evolution Review Committee, and the Address Supporting Organization. Originally from the USA, Andrew currently lives in Rotterdam, The Netherlands with his husband and cat. In his spare time he enjoys cycling, table top role playing games, and reading.
Email: andrew@depht.com
• 11 min read
The RIPE community has spoken and the results are in. The RIPE Code of Conduct Team presents an analysis of the feedback received, discusses next actions, and shares a detailed breakdown of the results.
• 5 min read
Help shape a safer, more open RIPE community. We’re launching our first Code of Conduct survey to understand how safe people feel at RIPE meetings and how likely they are to report concerns. If you have a moment to answer five quick, anonymous questions - your input will shape what we improve next.
Showing 2 article(s)
“Hi Andrew, I couldn't agree more. Most of what will be out there for the foreseeable future is machines, in my opinion. What makes the discussion necessary at the moment is that there IS ongoing work within the IETF in this area, and if that leads to an instruction to IANA for an allocation with a delegation to the RIR system, ignoring it is not an option. The main reason I wrote this article is that IF this is a thing that's going to go ahead, we need to make sure it gets done correctly, and actually gives the RIRs something workable. The current state of the draft in the IETF is, in my opinion, not. Remco”
Thanks Remco. I think I understand a bit more now your article and proposal. My main issue is that people are looking into different crystal balls and imagining different futures. And nothing in your proposal or anything I've seen in tiptop really addresses this. Predicting the future will inevitably fail, but we should still spend time describing the future that we're designing for. Otherwise all of these design questions degrade into arguments about which future we're designing for. I remember many of the discussions around IoT from 5-10 years ago or so, and many of them started with things like, "We expect dozens of devices in the average home." Or something like that. I don't understand how this space Internet thing can even start without people making declarative statements like that. A lot of what was predicted for IoT didn't actually happen, but that's not the point. The point is that there was a foundational baseline from which network nerds could begin developing user expectations and requirements. Typical of consensus based efforts there will be disagreements over how abstract or specific the declarative predictions of space colonization can be. Maybe only very abstract statements can be agreed upon about the future, but that's still better than nothing.
I find this article and much of the discussion on the tiptop mailing list suffers greatly from a kind of techno-utopianism that assumes humans will colonize space. I don't buy it. I'm willing to bet that by the time of my death (let's say 30 years) there will not have been a single BGP peering session in space. Perhaps I'm wrong and space will be colonized, but in your attempt to reestablish a baseline for this work by questioning assumptions you've left out the most important one: Why design a network when we don't yet have users? I don't want to dig into the reasoning and speculation surrounding the inevitability of space colonization, and I don't think this work in the IETF should either. But I do find it rather weird that this work just assumes users are going to show up in space at some point and need an Internet. More importantly, the assumptions about how many users there will be, what those users will need, where they will be, and whether they will be humans or machines underpin much of this work. Yet the vast majority of discourse I've read on this topic simply ignores these fundamental questions. Instead, everyone approaching this work has a different idea about how space exploration is going to play out. These assumptions then shape their design choices, and since everyone is looking into a different crystal ball, arguments over design become a proxy for arguments over futurism. Consider this question: If I were going to develop software for a bunch of users that didn't exist, but with an expectation that they would exist in the future, what should be my first step? Answer: Describe these future users and their environment. State your assumptions about these users. Only then can you begin to understand their needs and draft requirements for the software that will address those needs. Designing a network is no different. No one is proposing extending the Internet to the Mariana Trench. Maybe giant squids need Internet even more than asteroids? And we can laugh at this suggestion, but there's really no reason why colonizing one is more inevitable than colonizing the other.
Showing 2 comment(s)