Introducing draft-denog-v6ops-addresspartnaming

I think each section should be a nom, and :: can be a om. My lolcat agrees.

Cisco's expression of a MAC address is wrong anyway. Correct notation
for a MAC address is separating each byte with a colon.

Doesn't matter... It's widespread and Cisco isn't the only one to use it.

Just for my own edification, who else besides Cisco do you know who
uses that notation for MAC addresses? I want some convincing before
I'll accept the claim that it's widespread.

Windows displays macs as dash separated hexified bytes (ie, 12-34-56-78-90-AB) which is incorrect.

Given how widespread and pervasive the Microsoft Windows Virus is, I'd call this widespread and pervasive.

Windows is not a virus. Viruses are tight, well written pieces of code with a specific (usually nefarious)

While windows certainly qualifies as nefarious, I doubt anyone would consider it tight or well written


Since 11/18/10 this discussion has generated something like 66 messages
across five threads on this list, on nanog and elsewhere.

While some suggestions are entertaining, I would think of this criticism
and commentary on the document as useful if it winnowed the number of
options down to fewer rather than more. e.g. the positive result and the
path to advancement of this draft would be when the document produces a
solid recommendation on address part naming rather than several of them.

Several recomendations do not get us further down the road to a common
set of


If you're looking for serious feedback:
1. Any term using > 1 word is out
2. Any word using > 2 syllables is out
3. I've never had a problem calling it "field," I think that 5952 is a
perfectly good normative ref for that, and I don't understand what the
fuss is about. :slight_smile:



- --

  Nothin' ever doesn't change, but nothin' changes much.
      -- OK Go

  Breadth of IT experience, and depth of knowledge in the DNS.
  Yours for the right price. :slight_smile:

If you're looking for serious feedback:

We are.

3. I've never had a problem calling it "field," I think that 5952 is a
perfectly good normative ref for that, and I don't understand what the
fuss is about. :slight_smile:

I seem to remember one of the authors of the initial RFCs telling us
that they went with field with the understanding that it's so generic
that someone could/would think of something else down the road. I
didn't have time to really search for that mail, though. The fact that
GMail is refusing to display quite a few mails atm (or serve them via
SMTP) does not help, either. Most of my draft-related emails are
amongst that...

To give a short summary of the current status:
Hextet received the most votes by far, followed by quibble. Everything
else didn't get nearly as much support. Quad has been suggested a lot
of times, but its meaning within the C/C++ world and very frequent use
within the Kame stack sadly makes this a no-go. Quibble already has a
meaning in English and a negative one, at that.
Hextet is incorrect if you are being pedantic, but it's reasonably
unique so that you don't have to call it "IPv6 hextet" to avoid

Given all of the above, my personal opinion is that hextet will come
out as the winner.


PS: Thanks to Joel. I was contemplating how to refocus the whole thing
and he did our job for us; and nicely.