Closure?

[J. Scott Marcus]

Thanks, Brian!  This is a very helpful response.  I responded to just a
couple of your points, as we seem to be largely in agreement on the others.

>> 2) the IAB and IESG had jolly well better remember that, if we do this,
>> there are few if any additional bits to be given away!
>
>True. 

I would propose that the recommendation be amended to note this explicitly
-- I propose verbiage below.



>> As far as assumptions:  The recommendation states that the allocation
>> efficiency for the 45 usable high order bits needs to remain above 0.22 in
>> order to provide a /48 to everyone expected to be on the planet in 2050,
>> and that the telephone system already exceeds this.
>> 
>> >  - RFC 1715 defines an "H ratio" based on experience in address space
>> >    assignment in various networks.  Applied to a 45 bit address space,
>> >    and projecting a world population of 10.7 billion by 2050 (see
>> >    http://www.popin.org/pop1998/), the required assignment efficiency
>> >    is log_10(1.07*10^10) / 45 = 0.22.  This is less than the
>> >    efficiencies of telephone numbers and DECnetIV or IPv4 addresses
>> >    shown in RFC 1715, i.e., gives no grounds for concern.
>> 
>> In fact, it probably IS plenty.  But it is important to remember the
>> implication:  That addresses within the initial 45 usable bits will be
>> assigned fairly densely.  The H ratio for the RIGHTHAND 80 bits of the IPv6
>> address is approximately zero -- not a sustainable example for the LEFTHAND
>> bits to follow.
>
>Absolutely correct. Sparse assignments would be a mistake. Do you think
>this should be stated somehow? Send words...

What about taking the paragraph that begins with "RFC 1715" and changing it
to end:  "gives no grounds for concern provided that the RIRs allocate
/48's prudently, and that the IAB/IESG refrain from any new recommendations
that might further reduce the remaining 45 variable bits unless a
compelling requirement emerges."  It makes for a long sentence -- perhaps
we could re-wordsmith.  But you get the idea.  We should not underestimate
our ability to squander the remaining bits.



>> The assumption that this migration entails only the implementation of new
>> allocation policies is flawed.  Much of the deployed gear -- perhaps most
>> of it -- will break if this happens.
>
>Well, we could argue that point. If people do clean implementations it
shouldn't
>be the case. But sloppy implementations are another question.

I think that the temptation to take advantage of the fixed bit boundaries
to simplify code and configuration will be irresistable.  But even if all
implementations envisioned in advance that a new and unspecified partition
of the bits might emerge in the future -- somehow? -- the quality of that
code in implementations in the field would be unknown until proven.  Sort
of a Y2K problem all over again.  And that's in the best of circumstances.

What about tacking a sentence onto the next paragraph (the "We are highly
confident" paragraph) to say something like: "Such a migration may not be
devoid of pain, but it should be far less disruptive than deployment of a
new version of IP."?



>> Again, the recommendation is probably workable.  I am worried about the
>> underlying overconfidence.
>
>If there is that tone in the text, it should be trimmed out.

I very much appreciate your invitation.  :-)  The two areas above are the
ones that bothered me, and I have availed myself of the opportunity to
propose new text.  Does anybody else have strong opinions?

Cheers,
- Scott