Re: Introducing draft-denog-v6ops-addresspartnaming

[Richard Hartmann]

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