--On Saturday, January 04, 2014 10:31 +0100 Patrik Fältström
<paf(_at_)frobbit(_dot_)se> wrote:
On 4 jan 2014, at 09:29, Jari Arkko <jari(_dot_)arkko(_at_)piuha(_dot_)net>
wrote:
One important change is that every future application
protocol proposal should be required to have an effectively
unlimited code space for assignment.
Agree.
I do not agree regarding the term "unlimited".
What is needed is that the specification do have a consequence
analysis regarding expansion of use.
At least if it isn't unlimited, but I agree with Patrik.
Remember that the most important single protocol value space we
have is one that we've gotten wrong (at least) three times,
twice requiring complete replacement of the relevant protocols
themselves to expand the space (even though, especially the
first time, there were other reasons to do so).
Remember:
-- We will never need more than 254 hosts.
-- We can expand that a bit by using an IMP number/ host
number pair.
-- A 32-bit range will always be enough, even if we
break it into octet-boundary Classes and thereby limit
how much of it can actually be used.
-- A prefix model and bit boundaries will save us for a
while.
and, more recently,
-- A 128-bit range will be enough forever, even if we
allocate it in ways that make the actual number of
usable addresses much smaller.
Maybe we are right about the last one, maybe not. But any
requirement of "unlimited" would essentially require
variable-length addresses (or variable-length parameter fields
more generally, and that has always been considered a major
architectural decision.
So, yes, analysis of how big the space really is and needs to be
and what the consequences are if it turns out to be not
"unlimited" enough.
john