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