> > 1) As requested, please be specific and speak only for yourself. So > that we can carry on a professional dialog meaningfully. >
I will start by citing one of my own responses to you : https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html I do not leave a loose end to any technical > discussion with substance. > With the utmost amount of respect, you do. Many people on this list have provided specific , technical issues with your proposal. Others have commented on non-technical, but practical considerations. In all cases, you have simply handwaved them away or not commented on them further. On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen <ayc...@avinta.com> wrote: > Dear Tom: > > 1) As requested, please be specific and speak only for yourself. So > that we can carry on a professional dialog meaningfully. > > 2) Hint: I signed up to NANOG.org only early this year. So, whatever you > have in mind might be from somewhere else. In addition, even though I do > not have good memory, I do not leave a loose end to any technical > discussion with substance. The revisions of the EzIP documentation have > always been improving the presentation style for easing the reader's > efforts, not about modifying our basic scheme. So, you need to be clear > about the topics that you are referring to. Thanks. > > Regards, > > > Abe (2022-11-21 17:16 EST) > > > > On 2022-11-21 13:23, Tom Beecher wrote: > > > > 1) "... for various technical reasons , ...": Please give a couple > > examples, and be specific preferably using expressions that > colleagues > > on this forum can understand. > > > > > > Myself and multiple others provided specific technical rebuttals to > > the proposal in the past on this list. > > > > > > > > On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen <ayc...@avinta.com> > > wrote: > > > > Dear Tom: > > > > 1) "... for various technical reasons , ...": Please give a couple > > examples, and be specific preferably using expressions that > > colleagues > > on this forum can understand. > > > > Thanks, > > > > > > Abe (2022-11-21 12:29 EST) > > > > > > > > > > On 2022-11-21 10:44, Tom Beecher wrote: > > > > > > 1) "... Africa ... They don’t really have a lot of > > alternatives. ...": > > > Actually, there is, simple and in plain sight. Please have a > > look > > > at the > > > below IETF Draft: > > > > > > > > > https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space > > > > > > > > > For the benefit of anyone who may not understand, this is not an > > > 'alternative'. This is an idea that was initially proposed by the > > > authors almost exactly 6 years ago. It's received almost no > > interest > > > from anyone involved in internet standards, and for > > various technical > > > reasons , likely never will. > > > > > > On Fri, Nov 18, 2022 at 10:52 PM Abraham Y. Chen > > <ayc...@avinta.com> > > > wrote: > > > > > > Dear Owen: > > > > > > 1) "... Africa ... They don’t really have a lot of > alternatives. > > > ...": > > > Actually, there is, simple and in plain sight. Please have a > > look > > > at the > > > below IETF Draft: > > > > > > > > > https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space > > > > > > 2) If this looks a bit too technical due to the nature of > > such a > > > document, there is a distilled version that provides a > > bird-eye's > > > view > > > of the solution: > > > > > > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf > > > > > > 3) All of the above can start from making use of the 240/4 > > > netblock as > > > a reusable (by region / country) unicast IP address > > resources that > > > could > > > be accomplished by as simple as commenting out one line of the > > > existing > > > network router program code. I will be glad to go into the > > > specifics if > > > you can bring their attention to this almost mystic topic. > > > > > > Regards, > > > > > > > > > Abe (2022-11-19 22:50 EST) > > > > > > > > > On 2022-11-18 18:20, Owen DeLong via NANOG wrote: > > > > > > > >> On Nov 18, 2022, at 03:44, Joe Maimon > > <jmai...@jmaimon.com> wrote: > > > >> > > > >> > > > >> > > > >> Mark Tinka wrote: > > > >>> > > > >>> On 11/17/22 19:55, Joe Maimon wrote: > > > >>> > > > >>>> You could instead use a /31. > > > >>> We could, but many of our DIA customers have all manner of > > > CPE's that may or may not support this. Having unique > > designs per > > > customer does not scale well. > > > >> its almost 2023. /31 support is easily mandatory. You should > > > make it mandatory. > > > > Much of Africa in 2023 runs on what the US put into the > resale > > > market in the late 1990s, tragically. > > > > > > > >> Its 2023, your folk should be able to handle addressing more > > > advanced than from the 90s. And your betting the future on > IPv6? > > > > They don’t really have a lot of alternatives. > > > > > > > >>> To be honest, we'll keep using IPv4 for as long as we > > have it, > > > and for as long as we can get it from AFRINIC. But it's not > > where > > > we are betting the farm - that is for IPv6. > > > > And yet you wonder why I consider AFRINIC’s artificial > > extension > > > of the free pool through draconian austerity measures to be a > > > global problem? > > > > > > > >> Its on Afrinic to try and preserve their pool if they wish > to > > > by doing things such as getting it across that progress in > > > addressing efficiency is an important consideration in > > fulfilling > > > requests for additional resources. > > > > Instead of this, they’re mostly ignoring policy, implementing > > > draconian restrictions on people getting space from the free > > pool, > > > and buying into various forms of reality avoidance. > > > > > > > >> But see the crux above. If your RiR isnt frowning on such > > > behavior then its poor strategy to implement it. > > > > So far, AFRINIC has given a complete pass to Tinka’s > > > organization and their documented excessive unused address > space > > > despite policy that prohibits them from doing so. However, > > AFRINIC > > > management and board seem to have extreme difficulty with > > reading > > > their governing documents in anything resembling a logical > > > interpretation. > > > > > > > > Owen > > > > > > > > > > > > > -- > > > This email has been checked for viruses by Avast antivirus > > software. > > > www.avast.com <http://www.avast.com> <http://www.avast.com> > > > > > > > > -- > This email has been checked for viruses by Avast antivirus software. > www.avast.com >