--On Saturday, January 04, 2014 10:31 +0100 Patrik Fältström <paf@xxxxxxxxxx> wrote: > > On 4 jan 2014, at 09:29, Jari Arkko <jari.arkko@xxxxxxxxx> > 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