Alternative Re: ipv4/25s and above Re: 202211201009.AYC

Mon Nov 21 17:54:31 UTC 2022

Dear Tom:

0) Thanks for your advice.

1) What I wrote was just informal online chatting. I was not attempting 
to make a water-tight legal statement. The fact is, we have identified 
at least one concise case of how this task could be done easily, as 
reported in Appendix D of the EzIP IETF Draft. Although no references 
have been published, I believe that colleagues on the IPv4 Unicast 
Extensions Project have seen similar situations.  Even without the 
latter, a "there exists one reference" should be sufficient to encourage 
other software engineers to review their own work. They should question 
the quality of their own programs if they are more complex, instead of 
ridiculing the concise example on the table.

Regards,

Abe (2022-11-21 12:54 EST)

On 2022-11-21 12:00, Tom Beecher wrote:
>
>     As stated in Subsection 4.A. of the "Revamp The
>     Internet" whitepaper, all need be done is "Simply disable the existing
>     software codes that have been disabling the use of the 240/4
>     netblock."
>
>
> Some friendly feedback. The phrase "all that needs to be done" , is 
> exceptionally reductive, and in the case of internet standards, also 
> always going to end up being wrong.
>
> On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen <aychen at avinta.com> 
> wrote:
>
>     Dear Mark:
>
>     0) Thanks for the clarification. I understand. A short message
>     through
>     the cyberspace, especially between parties who have never met can be
>     easily skewed. I am glad that I asked you, instead of taking it
>     negatively without raising my hand.
>
>     1) "...I'd, rather, expend those resources on IPv6, 464XLAT,
>     e.t.c. ...
>     ": Since EzIP is still being further refined, it may not be clear
>     in our
>     documentation about how much work is required to get the IPv4 out
>     of the
>     current depletion mode. As stated in Subsection 4.A. of the
>     "Revamp The
>     Internet" whitepaper, all need be done is "Simply disable the
>     existing
>     software codes that have been disabling the use of the 240/4
>     netblock."
>     In fact, we have found examples that this means commenting out one
>     line
>     code that searches for then discards packets with 240/4
>     addressing. It
>     seems to me that there is no easier task than this.
>
>     https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
>     Regards,
>
>     Abe (2022-11-21 11:18 EST)
>
>
>
>     On 2022-11-20 23:56, Mark Tinka wrote:
>     >
>     >
>     > On 11/20/22 19:02, Abraham Y. Chen wrote:
>     >
>     >> Dear Mark:
>     >>
>     >> 0)  I am surprised at your apparently sarcastic opinion.
>     >>
>     >> 1)  The EzIP proposal as referenced by my last MSG is the
>     result of
>     >> an in-depth system engineering effort. Since the resultant
>     schemes do
>     >> not rely on any protocol development, IETF does not need be
>     involved.
>     >> Especially, its first step of disabling one line of existing
>     >> networking program code empowers any party to begin deploying EzIP
>     >> stealthily for mitigating the IPv4 address pool depletion issues.
>     >> Note that EzIP is a generic solution applicable to everyone, not
>     >> limited to Africa.
>     >>
>     >> 2)  Of course, constructive criticism is always appreciated.
>     However,
>     >> unspecific comments that confuse and distract the readers only
>     >> provide dis-service to those disadvantaged population who are
>     >> enduring the handicaps of being the late-comers to the Internet.
>     >
>     > My comment was not directed at you. Sorry.
>     >
>     > I have nothing against the EzIP proposal. It just does not add any
>     > real value in solving the IPv4 depletion problem for the amount of
>     > effort required to implement it, in my view. I'd, rather, expend
>     those
>     > resources on IPv6, 464XLAT, e.t.c.
>     >
>     > Mark.
>     >
>
>
>     -- 
>     This email has been checked for viruses by Avast antivirus software.
>     www.avast.com <http://www.avast.com>
>