Introducing draft-denog-v6ops-addresspartnaming

Hi all,

as most of you are aware, there is no definite, canonical name for the
two bytes of IPv6 addresses between colons. This forces people to use
a description like I just did instead of a single, specific term.

Being highly pedantic Germans, this annoyed quite a few people within
the DENOG community. This, in turn, lead to an I-D[1]. If any of you
have any additional suggestions, you are more than welcome to share
them. Additionally, I want to invite everyone to participate in an
informal poll which we created[2]. We're fully aware that it's trivial
to cheat on this poll; that's life.

As of right now, Quibble leads with Hextet being a close second. All
other options got significantly less votes.

Thanks,
Richard

[1] http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming
[2] http://doodle.com/5q9gfvk4qe6zmzc6

Hi all,

as most of you are aware, there is no definite, canonical name for the
two bytes of IPv6 addresses between colons. This forces people to use
a description like I just did instead of a single, specific term.

I am ok with "quibble" but I don't think it will gain wide usage in the US. We use "quad" at work.

G

problem is, its not alwas ggoig to be two bytes...

--bill

Since the poll is a straight yes/no option with no preference, I will
express my preference here. While I find the term quibble fun and
amusing, I think hextet is a far more useful term because it does not
have the overloaded human semantics that come with quibble.

I'm sorry to quibble with the majority here, but, in this case, I think
we have enough problems with ambiguous terminology in
networking and this opportunity to avoid creating one more should
not be missed.

Owen

I saw 'field' somewhere....

http://tools.ietf.org/html/rfc5952#section-2.1
seems to agree.

Frank

It's always two bytes, but people may choose to omit them. That is a
social, not a (purely) technical, syntax, though.

Richard

Since the poll is a straight yes/no option with no preference, I will
express my preference here.

I considered using the Condorcet method [1] (modified for NotA), but
as past experience has shown that people get easily confused by it, I
decided to create a "plain" poll, instead.

While I find the term quibble fun and
amusing, I think hextet is a far more useful term because it does not
have the overloaded human semantics that come with quibble.

To be completely honest, while I did know the term, I had forgotten
about it. This is part of the reason why I am seeking a wider
audience. I'll add this consideration to the draft. I agree that this
might be (not has to be) a deal breaker.

I'm sorry to quibble with the majority here, but, in this case, I think
we have enough problems with ambiguous terminology in
networking and this opportunity to avoid creating one more should
not be missed.

Agreed. OTOH, Hextet is not technically correct while appearing to be so.

Thanks a lot,
Richard

[1] Condorcet method - Wikipedia

I seem to remember "field" being used with the understanding that it's
a placeholder and not a definite term. As I can't find an actual
source for that, I will have to get back to you once I found it.

Richard

That's exactly what I was going to say but didn't want to quibble. We tend to call them "quads" at work. What do you call that indeterminate space between two colons :: where it might be four or more zeros in there? That's a bunch of nibbles, maybe a "gulp"?

If 8 bits is a byte, then 16 bits should be a mouthful.

:wink:

Scott

Yeah, I think I'd quibble with quibble; it's antagonistic. "Gulp" has serious potential in casual conversation (especially because you can refer to the excluded "::" portion as "the Big Gulp") but somehow I don't see it used in technical documentation. I like "morsel," personally. (Well, I also like "collop," because it's arcane and sounds vaguely dirty to me, but I don't think that would catch on.)

I don't call it anything. "The fourth $decided_upon is zero/empty" suffices :slight_smile:

Though if that gap does not have a name yet, I suppose it can't hurt
to try and think of a canonical name, either.

Richard

When does it become a meal and, more importantly, do you want to
supper (sic) size?

RIchard

The supersize option offered by e.g. McDonalds is not much larger than
the normal meal size in my experience.

So I guess, 8 bits = small, 16 bits = meal, 24 bits = supersize or
something, but that doesn't fit well with IPv6 since each segment
between colons is only 16 bits.

We could call the :: part the 'liposection' though.

William

It is always two bytes. A byte is not always an octet. Some machines do
have byte sizes other than 8 bits, although few of them are likely to have
IPv6 stacks, so, this may be an academic distinction at this point.

Owen

I'm sorry to quibble with the majority here, but, in this case, I think
we have enough problems with ambiguous terminology in
networking and this opportunity to avoid creating one more should
not be missed.

(The above paragraph was mainly so that I had an opportunity to toss
quibble into the text with it's other meaning).

Agreed. OTOH, Hextet is not technically correct while appearing to be so.

True... The correct term would be decohextet, but, decohextet is rather
long both to say and to write and really doesn't roll off the tongue the
way hextet does.

Owen

Greetings,

It is always two bytes. A byte is not always an octet. Some machines do
have byte sizes other than 8 bits

Vice versa. It's always two octects, but on some systems it may not be
two bytes.

, although few of them are likely to have
IPv6 stacks, so, this may be an academic distinction at this point.

Agreed.

We can revisit this once we all own a few portable quantum computers, though :slight_smile:

Richard

I have a quibble with this discussion. When I defined a "byte" as "a mouthful of bits" to my boss back in 1977, he nearly fired me on the spot. He did not care about PDP-10 , much less PDP-11, data constructs.

By now, octet has become essentially synonymous with byte and nibble with 4-bits. Could we just refer to "n octets"?

  Cutler

For Reference Only:

      problem is, its not alwas ggoig to be two bytes...

It's always two bytes, but people may choose to omit them. That is a
social, not a (purely) technical, syntax, though.

Oops... Hit send too fast...

It is always two bytes. A byte is not always an octet. Some machines do

It is always two OCTETS. A byte is not always an octet...