On Sun, Nov 21, 2010 at 16:54, William Herrin <bill@herrin.us> wrote:
Because in my version fd::/8 actually is the same as fd00::/8, which, as you rightly point out, is exactly what a normal human being would naturally expect.
Which is against every expectation of anyone who ever learned Arabic numbers in a left-to-right system. As Owen pointed out, filling with zeros on the right-hand side would be, to put it lightly, a disaster. Maybe I should have worded that more strongly in my last reply.
Imea nrea lly, what ifwe wrot eEng lish thew aywe writ eIPv 6add ress es? Looks pretty stupid without a floating separator, doesn't it?
Reductio ad absurdum.
We've gone too far down the wrong path to change it now; colons are going to separate every second byte in the v6 address. But from a human factors perspective, floating colons would have been better.
No. See my, and Owen's, emails.
From a computer parser perspective, a character other than a colon would have been better because colons are already claimed for many for other syntax elements that include an IP address, like the address/port separator in a URL.
It's the least bad amongst a highly limited choice of even worse chars. There is a reason why the colon is used so often.
Making the jump in logic, it would help mitigate the errant design if the two-byte groupings separated by the colons were intentionally and formally not named. That fits a training scenario which reinforces the idea that the colons are there for convenience but that there is nothing special about those two byte groupings.
Personally, I have no interest whatsoever in limiting my efficiency and increasing the chance that I or others make mistakes because people who don't understand the matter at hand might misinterpret something.
The question leads me to recall a fancy version of traceroute I once used. In addition to looking up the PTR record for each hop, it also looked up the org and AS number currently associated. If users found it valuable to have the router present variable colon placement, it's a doable albeit complex computing task.
If you ever looked at the state of a lot of data in the RIR's whois databases, you know that's literally impossible. And a _lot_ of effort for little to no gain. And what if a LIR changes their numbering scheme, at some point? Attach parsing instructions to inetnum? Richard