Re: IPv6 prefix lengths - how long?

[Gyan Mishra <[e-mail]>]

I concur with you on the cost benefit trade off.

However I would like to state that there have been many tweaks to RFCs
written  across the board across all IETF workgroups and cost has nevet
been a factor in the consideration since when you add a new feature or
change its really the developers doing the coding to determine feasablility
and cost as every draft proposed is new or change that is Depricates an old
RFC and there is always cost involved no matter how minor the change is but
just because there is cost involved does not mean you don't move forward
with the change or move forward with the change.

If what you are staying that the cost would out weight the benefit we would
have to truly do a cost benefit analysis on every draft that is approved
and I don't think the IETF had the man power to do so.

Of all the IETF WGs that I have been part of for many years cost had not
been the factor for that reason that determines wheathet the change is
approved or not.

The major factor is if the change  makes sense and if their is a problem or
gap or issue or problem or defect we are trying to solve and if we are able
to get consensus by the WG and chairs and ISG for approval.

Gyan


On Sun, Jun 9, 2019, 11:54 AM James R Cutler <[e-mail]>
wrote:

> On Jun 9, 2019, at 10:07 AM, Gyan Mishra <[e-mail]> wrote:
>
>
> All your concerns are duly noted.
>
> As far as changing the prefix length I understand that with IPV6 it seems
> and maybe true that IPv6 exhaustion is not possible but that is what we
> said about IPv4 but that does not give reason to be wasteful.  I believe 64
> bits iid is wasteful.
>
> From many views, I must agree with you about “wasteful”.
>
> Where we part company is that the costs involved in changing away from 64
> bits is more wasteful than your proposal. The especially applies to time
> (labor) costs, both for new RFPs, design and prototyping, and deployment
> costs. It has take around two decades to get this far with IPv6. Adding yet
> another detour to this journey is not an improvement.
>
> James R. Cutler
> [e-mail]
> GPG keys: hkps://hkps.pool.sks-keyservers.net
>
>
>
>