Re: Introducing draft-6man-addresspartnaming

Richard Hartmann <> Fri, 08 April 2011 09:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 470F83A69BC for <>; Fri, 8 Apr 2011 02:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.653
X-Spam-Status: No, score=-3.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r-eQbsOuTWWn for <>; Fri, 8 Apr 2011 02:59:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0FBC83A69B8 for <>; Fri, 8 Apr 2011 02:59:38 -0700 (PDT)
Received: by iye19 with SMTP id 19so4099454iye.31 for <>; Fri, 08 Apr 2011 03:01:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Oa8SGcaHefVOl20SxexeWCvqs3EWE2jRYdcUOfLVhmc=; b=ZmQ8Et3sc75NpOfA6gszEfyjKhGkF9ZNofpIwB0PfyQrFJgxtLLovopSQNbxk52Wec u+Fm0enOy7RK5xXP1Tc2zFXpH+42X/TsaPOYG4hh0T6e7cdzptOtm1145KA1/8spJrxg kL1C49+id8Pu/daLlPfVZSpzu1VbLWeJMpq4U=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=uh6gZoZ9s4WtvtBnUiA62NsurzOoHTRg0x7UlqO1Ula55vkYroS385iMp6tfIt0gNk L9b9mwgmLW7qaUpsv5Uuq+O8eJVqgtfaz7ZAOFGtPwVORcwxLGD1Gzk5qj8m/+Ae4Gbi HaXmM5Y6AC3p0Vqc/joou6sm+YZDR0U8EYYfM=
Received: by with SMTP id t25mr1963895ibs.135.1302256883087; Fri, 08 Apr 2011 03:01:23 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 8 Apr 2011 03:01:03 -0700 (PDT)
In-Reply-To: <1302249915.31306.332.camel@karl>
References: <> <1302227649.31306.221.camel@karl> <> <1302249915.31306.332.camel@karl>
From: Richard Hartmann <>
Date: Fri, 8 Apr 2011 12:01:03 +0200
Message-ID: <>
Subject: Re: Introducing draft-6man-addresspartnaming
To: Karl Auer <>
Content-Type: text/plain; charset=UTF-8
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Apr 2011 09:59:39 -0000

On Fri, Apr 8, 2011 at 10:05, Karl Auer <>; wrote:

> OK. I've read it and find many of the arguments to be generally
> unconvincing. Right with you on "chazwazza" though :-)

That's fine. This is why we are here :)

> If the draft is to document what amounts to a popularity contest for a
> word, then that's fine, but it would be more honest if it said so,
> rather than presenting such thin arguments.

I am not sure why or how you see this as a popularity contest. We
solicited feedback from everywhere and went with the results that
showed the most promise of broad and general consensus across both the
IETF lists and actual operators around the world.

> My argument against "hextet" is simple. It is not a legitimate
> abbreviation of "hexadectet" for two reasons.

That as may be, it's a nice, short, precise, unique term. It's not
unheard of that terms are not 100% correct but widely accepted and in
general use. This may not be perfect, but it shows signs of consensus.
As you will certainly agree, a commonly term that is in wide an
accepted use is better than the current confusion.

As you said it's very late in the game, but you are more than welcome
to make an alternate suggestion.

> there may be zero to four hex digits
> between two colons, and there are three to eight colon-delimited parts
> in an IPv6 address.

This point is half moot as I am agreeing that hextet is not a perfect,
"merely" the best, option. Still, no matter how you represent those 16
bits, they are 16 bits. Either way, if anything, this representation
issue makes the argument for a not-quite-technically-perfect stronger,

> Not at all. There are literally tens of thousands of words in English
> alone that are not unique in meaning and require context to be properly
> understood. "Field" is one of them - so are "address", "bit" and
> "colon", for that matter. In the context of IPv6 addresses, there would
> be no more ambiguity with "field" than there would be for, say, "bit",
> which could mean "a binary digit" or "a small piece" unless qualified by
> context:

In technical context, "bit" is reasonably unique to determine that you
are referring to a single boolean value.
As soon as you are talking about an IPv6 bit, an IPv4 bit or a
Mibibytes' bit, you need to add context, though.

This is something we would like to avoid for IPv6 "fields".

"Field" is perfect inasmuch as it describes pretty much anything.
Point in case, the IPv6 RFCs refer to fields (while _not_ specifying
this as a definite term, merely as a placeholder as they had to use
some name).
"Field" is horrible inasmuch as it describes pretty much anything.

Bit vector is another technically correct choice which is horribly
overloaded with context-sensitive meanings.

The goal is to say "look at the fourth hextet" and not "look at the
fourth thing, that IPv6 field. Yes, you know what I mean. Yes, it's
nice that you call it chazwazza. Would you stop this and look at it,

> And if you say my
> name quickly, you get "kalauer", which is the German word for a stale
> joke :-)

Which is why the Comedian chose it. He says it quickly and slurs it.
Enough off topic chatter though, the threw me off, last I
checked it did not mean .austria ;)