On Sun, Nov 21, 2010 at 16:54, William Herrin <b...@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