please read the document and make your own conclusions about it. it would be best if you commented on that instead of meta issues like whether my criticism was justified or not or if it hurt someone's feelings. i have apologized for any offense and hope we can move passed that. let's focus on that itu document and it's technical content. On Friday, 25 May 2018, 06:37:42 GMT+1, Sascha Luck [ml] <ripe-ipv6@c4inet.net> wrote: Leslie, On Thu, May 24, 2018 at 07:17:01AM -0700, Leslie wrote:
Can we elevate the level of discussion on this mailing list? It's one thing to disagree over the facts and content, it's another to attack the person (who has feelings!) behind the document.
All I've read was a harsh critique of the document in question. I haven't read the original document so I can't speak to whether said critique is justified or not but if this is supposed to be a *technical* WG, a proposal or paper must be judged on its technical merit and not on the purported feelings of its author. And yes, that can include a judgement on their competence. If the discussion here is *not* supposed to technical but just political, feel-good wishy-washy tripe, I beg to be informed of this, so as to be able to unsubscribe this ML as a waste of my time. rgds, Sascha Luck
On Thu, May 24, 2018 at 7:10 AM James Morrow via ipv6-wg <ipv6-wg@ripe.net> wrote:
i read this document with a mixture of astonishment, confusion and horror. it's awful.
the document is utterly, utterly broken. it has no redeeming or worthwhile qualities at all.
the only thing it's good for is an example of how #not# to do an ip addressing plan based on errors and poorly articulated, mistaken assumptions. it also shows beyond any doubt that itu should not meddle in ip addressing because it has no competence or mandate to get involved in this field. i've already seen far too many deeply flawed itu documents on ipv6, such as the 2009? nav6 study. this one's much, much worse.
it's painfully obvious whoever wrote this junk has no understanding and operational experience of how to design or deploy an ipv6 addressing plan for any non-trivial ipv6 network. the document is not a sound piece of work that makes any sort of technical or engineering sense.
the document is riddled with errors - far too many to list. it makes ridiculous assertions that have no basis in fact and does not provide any references to justify these claims or let someone check them. i started to write down these flaws and then gave up in disgust. why should i do somebody else's homework for them? conflating ipv6 uptake rates with developed/developing countries is yet another serious failing. these things are completely orthogonal to each other.
the unstated assumptions are wrong too.
first of all, the notion of "special" ipv6 addressing plans for iot devices is foolish. these don't need to be treated differently and shouldn't be treated differently from anything else that's connected to the internet - at least from an addressing perspective.
next, it's beyond absurd to suggest or imply there could be one over-arching addressing plan that can be used and will work perfectly for iot devices in any network or every use case. that's just basic common sense. how you'd do that depends on the actual network and its requirements. for example take smart lightbulbs: an addressing plan for home use wouldn't be suitable for a large building (school, hospital, office block, etc) or for a town's street lights. they'd all have different (subnet) addressing plans that were suited to their specific needs - number of lights, topology, security, planned expansion, architecture(s), link-layer connectivity, redundancy / spofs, budget, latency, bandwidth, interoperability and compatibility with existing systems / networks (if any), access controls and so on. the document doesn't even hint at any of those considerations.
the only thing to be done with this document is kill it. kill it with fire. it's too far gone to be fixed or salvaged..
imo, the wg needs to tell itu to stay well away from ip addressing and leave this to the experts who actually build and run ip networks.