Subject: Re: [v6ops] On IPv6 address part naming

From: Owen DeLong <[email-masked]>
Date: Mon, 1 Dec 2014 17:00:23 -0800

+1 for hextet.

Owen

> On Nov 20, 2014, at 2:48 PM, Doug Barton <[email-masked]> wrote:
> 
> Responding to a post at random ....
> 
> I've always been partial to the term 'hextet' for this.
> 
> Doug
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Owen DeLong <[email-masked]>
Date: Mon, 1 Dec 2014 17:20:24 -0800

> On Nov 20, 2014, at 3:23 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 
> On 11/20/2014 2:51 PM, Richard Hartmann wrote:
>> On Thu, Nov 20, 2014 at 11:37 PM, Joe Touch <[email-masked]> wrote:
>>> That said, it depends on whether you're going for Latin accuracy or
>>> convenience.
>> 
>> That was a major point of discussion back then and the consensus
>> leaned towards convenience.
>> 
>> The technical world is full of plays on words, inside jokes, and other
>> not-quite-serious names.
>> 
>> Given that, I would argue that a (non-funny) name of convenience would
>> be better than a factually correct yet unwieldy name.
> 
> Agreed. To that end, we already have a bunch of name sequences:
> 
> 	Groups of bits:
> 		bit
> 		nibble
> 		octet/byte

octet and byte are not (necessarily) synonymous. A byte may be 8 bits. An octet is ALWAYS 8 bits.

> 	Groups of bytes:
> 		octet/byte
> 		halfword
> 		word
> 		double-word
> 		quadword

Of which the only deterministic name in the entire group is “octet”.

> IMO, if we're headed towards naming 16-bit things, in the old days
> (e.g., when octal was common instead of byte), we'd use hexadecet (not
> hexadectet, matching the base name sequence, even though it switches
> from Latin to Greek).

Octet and byte are often used interchangeably, these days, but you will find that network engineers usually try to stick with octet in contexts where exactly 8 bits are intended and reserve byte where “a single addressable memory location” or “a single character” is intended.

> However, we already have a common term for that - halfword, but that can
> be ambiguous. The only unambiguous terms would be double-byte or
> double-octet.

double-byte is actually ambiguous because bytes can be many different lengths. I have seen bytes as short as 5 bits and as long as 12. I believe there are even longer bytes in historical systems, but my historical knowledge of computing is limited.

> Hextet is a poor choice, IMO. It transliterates to '6', not '16', and
> that's misleading at best. At worst, it already has a clear meaning that
> might be accurate for IPv6 specs but not desired:
> http://en.wiktionary.org/wiki/hextet <http://en.wiktionary.org/wiki/hextet>

Since that meaning is limited to German (which makes one wonder what it is doing in the en.wiktionary.com <http://en.wiktionary.com/> pages). It’s not listed in Webster’s.
I can’t check OED easily at the moment, but if anyone has a subscription or access to the dead tree edition, feel free. As such, I don’t think coining it for this purpose is any worse than the current vernacular (which you have fallen victim to) where bytes are presumed to be 8 bits in length.

> However, I doubt we need a single document to decide such things. Nobody
> declared that "thou shalt refer to 8 bits as an octet" (parodies of
> Genesis aside).

http://en.wikipedia.org/wiki/Octet_(computing) <http://en.wikipedia.org/wiki/Octet_(computing)>

Covers this rather well. There may not be an RFC that says “thou shalt call the pieces of an IPv4 address an octet”, but very early RFCs do specify that an IPv4 address is comprised of 4 octets.

The first RFC I could find that used the term octet was RFC635 (by Vint Cerf). The definition of IPv4 addresses as 4 octets comes later in RFC791.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 1 Dec 2014 17:36:45 -0800

I will also point out that 3 syllables is not likely to persist as a commonly used term. Further,
three syllables that are not necessarily intuitive to spell (is it saidiset, sedicet, sediset,
sedacet, sedacit, …?) are simply not likely to survive vernacularization. Most of the terms
we tend to use every day tend to get reduced to one or 2 syllable versions and the majority
of the ones in common use tend to have less than ambiguous spelling (where byte is a
notable exception for it’s distinct spelling oddity).

nibble
byte
octet
kilo
mega
giga
peta
exa
milli
micro
nano
pico
femto

Not one of those is more than 2 syllables and they are all spelled phonetically and unambiguously.

Longer scientific terms tend to get acronymized, such as Gastrointerologist -> GI, Fiberoptic -> Fiber,
etc.

I’m not sure what would happen to sedicet if we tried to mandate it, but I don’t think it would survive
to widespread adoption in tact.

OTOH, sextet seems to already have substantial following and I think this is an area where IETF serves
the community better by documenting existing terms currently in use. If possible, we should come to
some consensus on a preferred one and document that, but it should, ideally be chosen from those
already in use rather than inventing a new term.

Owen

> On Nov 20, 2014, at 11:06 PM, Richard Hartmann <[email-masked]> wrote:
> 
> On Fri, Nov 21, 2014 at 1:42 AM, Lorenzo Colitti <[email-masked]> wrote:
>> Hextet seems to be the term most in use among my colleagues, too.
> 
> One more note about this point: back in 2010/2011, there was a
> surprising amount of people well into the two figures who contacted
> me, asking what the default will be so they could start adoption. The
> only sane answer back then was that it would likely be "hextet". It's
> quite likely that this usage spread from there and has created a
> baseline of a somewhat commonly accepted name. Myself, I have heard
> this name used several times in normal conversation without pushing
> either way. This was not the case back then so maybe facts have been
> created, already.
> 
> Reactions in this thread seem to mirror my observations though we
> should let some more time pass before taking a count^Whum.
> 
> 
> 
> Richard
>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 01 Dec 2014 21:53:18 -0500

On 01/12/2014 8:20 PM, Owen DeLong wrote:
>
>> On Nov 20, 2014, at 3:23 PM, Joe Touch <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>> On Thu, Nov 20, 2014 at 11:37 PM, Joe Touch <[email-masked]
>>> <mailto:[email-masked]>> wrote:
> Octet and byte are often used interchangeably, these days, but you will
> find that network engineers usually try to stick with octet in contexts
> where exactly 8 bits are intended and reserve byte where “a single
> addressable memory location” or “a single character” is intended.
>
> double-byte is actually ambiguous because bytes can be many different
> lengths. I have seen bytes as short as 5 bits and as long as 12. I
> believe there are even longer bytes in historical systems, but my
> historical knowledge of computing is limited.
>
>> http://en.wiktionary.org/wiki/hextet
>
> Since that meaning is limited to German (which makes one wonder what it
> is doing in the en.wiktionary.com <http://en.wiktionary.com> pages).
> It’s not listed in Webster’s.
> I can’t check OED easily at the moment, but if anyone has a subscription
> or access to the dead tree edition, feel free. As such, I don’t think
> coining it for this purpose is any worse than the current vernacular
> (which you have fallen victim to) where bytes are presumed to be 8 bits
> in length.
>
> http://en.wikipedia.org/wiki/Octet_(computing)
>
> Covers this rather well. There may not be an RFC that says “thou shalt
> call the pieces of an IPv4 address an octet”, but very early RFCs do
> specify that an IPv4 address is comprised of 4 octets.
>
> The first RFC I could find that used the term octet was RFC635 (by Vint
> Cerf). The definition of IPv4 addresses as 4 octets comes later in RFC791.
>
> Owen
>
>
>
I can't resist adding a touch of history. The term "byte" was introduced 
with the IBM /360, and definitely meant eight bits at that time. I 
worked on the first one in Canada. The /360 came after the IBM 1401, 
which emulated punched cards plus a couple of additional bits for parity 
and word marks.

Rummaging through my hardcopy Random House dictionary I find "decade" = 
"group of ten". I'm not sure if "hexadecade" translates to 16 or 60, but 
it sounds good.

Tom Taylor

---

From: Owen DeLong <[email-masked]>
Date: Mon, 1 Dec 2014 19:01:13 -0800

hexadectet may be more natural or easier for someone of hispanic background, but as a native English speaker, I have to tell you that I find it much easier to say hextet than any of the others.

Owen

> On Nov 22, 2014, at 9:24 AM, Octavio Alvarez <[email-masked]> wrote:
> 
> On 11/21/2014 07:41 PM, Doug Barton wrote:
>> On 11/21/14 5:02 PM, Octavio Alvarez wrote:
>>> "Hexadecatet". It's correct and even easier than "hextet"
>> 
>> 5 syllables is easier than 2? Seriously? :)
> 
> Yeah, I should clarify. I'm not even sure if I meant "hexdectet" instead of "hextet" above.
> 
> Anyway: easy != short != natural
> 
> "Natural" implies the muscle use of the mouth and the already-trained brain used to pronounce a word, mostly as a result of the accent and culture. The brain and muscles already have many constructs on their "cache" to (both) say and understand a word.
> 
> 2 is shorter than 5, but not necessarily easier. For example, in Spain's Spanish "hexteto" is more unnatural pronounce than "hexateto", even though it is a shorter word. Even further, "hexadecatet" is way more natural than "hexdectet" although 5 > 3.
> 
> So:
> 
> * hexadecatet, easier than hexadectet
> * hexadecatet, definitely easier than hexdectet
> * hexatet, easier than hextet
> * hex- -dec- -tet, more correct than hex- -tet
> 
> That is why I gave my thumbs up to "hexadecatet":
> 
> * "Hexadecatet" better (not shorter) than "hextet", considering correctness.
> 
> * "Hexadecatet" better (and easier) than "hexdectet"
> 
> My $2E-2.
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 1 Dec 2014 21:10:49 -0600

> hexadectet may be more natural or easier for someone of hispanic background, but as a native English speaker, I have to tell you that I find it much easier to say hextet than any of the others.

It's also shorter to write.   And for better or for worse, IETF documents are written in english.   I suspect this general practice is more of a problem for someone who is not a native english speaker than the specific english or jargon words that are used in documents... :)

---

From: Joe Touch <[email-masked]>
Date: Mon, 1 Dec 2014 19:31:36 -0800

> On Dec 1, 2014, at 6:53 PM, Tom Taylor <[email-masked]> wrote:
> 
> I can't resist adding a touch of history. The term "byte" was introduced with the IBM /360,

It was coined during the design of the IBM Stretch, by Buchholtz, prior to the /360.

Byte meant 8 bits until that got mixed up with parity memory sizes. Is has meant 8 bits got more then long enough at this point to be unambiguous. 

Joe

---

From: "Rampley Jr, Jim F" <[email-masked]>
Date: Mon, 1 Dec 2014 22:59:48 -0600

I agree that hextet sounds right.

Jim

---

From: t.petch <[email-masked]>
Date: Wed, 3 Dec 2014 10:48:08 +0000

----- Original Message -----
From: "Joe Touch" <[email-masked]>
To: "Tom Taylor" <[email-masked]>
Cc: "Phillip Remaker (remaker)" <[email-masked]>; "IPv6 Operations"
<[email-masked]>
Sent: Tuesday, December 02, 2014 3:31 AM
> Byte meant 8 bits until that got mixed up with parity memory sizes. Is
has meant 8 bits got more then long enough at this point to be
unambiguous.

I was a resident technical expert working for a rival organisation in
the 1970s which was about to switch from 6 bit storage to 8 bit storage
and their market research heard that IBM was about to introduce the
concept of the 9 bit byte so I was asked to evaluate what the
implications might be.  The best I could come up with was a parity bit,
but since Hamming codes were all the rage, that seemed a bit limp; it
stays in my mind as an unresolved question.

Tom Petch

---

From: Tim Kleefass <[email-masked]>
Date: Thu, 04 Dec 2014 13:26:35 +0100

On 22.11.2014 9:33 AM, Gert Doering wrote:
> On Thu, Nov 20, 2014 at 07:03:13PM +0100, Richard Hartmann wrote:
>> as you may remember, I tried to push a draft on IPv6 address naming[1]
>> back in 2010 on both v6ops [2] and 6man [3].
>>
>> As I finally have enough spare cycles again I want to try and push
>> this as a WG item within v6ops one last time.
> 
> "Hextet" sounds good to me, even if not fully pedantically correct - but 
> it's short, easy to pronounce (at least for german speakers) and to remember.
> 
> As for "shall the WG adopt the draft" - well, this is operational, and
> it helps if people talking about "things" use the same terminology, so
> I'd support that.

Good summary, I'd like to second that.

Cheers,
	Tim

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Dec 2014 14:14:14 +0100

> Good summary, I'd like to second that.

I third adoption, but wonder about coherence of this particular naming 
at other SDOs.

Alex

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 4 Dec 2014 16:59:38 +0000

> it helps if people talking about "things" use the same terminology, so

I'm intrigued by the discussion of the word "octet". As of this morning, 2667 RFCs and 581 posted Internet Drafts use the term, from RFC 635 (as Owen notes) to RFC 7411 and draft-hu-softwire-multicast-radius-ext-07.txt, which was probably posted on today’s date China Standard Time. RFC 635, which uses the word six times and talks about "a line control envelope consisting of 48 bits of control octets and a 24 bit cyclic checksum" among other things, uses it pretty much the same way we use the term "byte"; it's a basic unit of information used to describe all sorts of things, but is specifically about things found in or relevant to messages. 

RFC 7411's example of the usage is

   Mobility Header messages exchanged in HI/HAck and FBU/FBack dialogs
   impose length restrictions on multicast context records due to the
   8-bit Length field.  The maximal payload length available in FBU/
   FBack messages is 4 octets (Mobility Option header line) + 1024
   octets (MLD Report Payload). 

draft-hu-softwire-multicast-radius-ext-07.txt octet mentions IPv6 multicast addresses, but uses the term “octet” to discuss "the total length in octets of [an] attribute” - it’s a measure of the size of a container, not the data in the container.

That usage (a basic unit of measure comprised of identifiable eight bit chunks) is consistent from April 1974 through today.

Various folks kicked around various words. An experiment that you may find amusing: google the word “hexadectet”. http://tinyurl.com/k3aqckb uses the term, there is a Java class by the name with the intended meaning of a sixteen bit unsigned number, and there are other hits. The word is in fact out there. Then google the word “hextet”; It is in the Wikipedia and the Urban Dictionary as a 16 bit quantum of information specifically relevant to an IPv6 address. It is also (youtube) used to refer to an ensemble of six instruments...

If I may ask a silly question: are we inventing or appropriating a word for a sixteen bit chunk of an IPv6 address, which might have applicability in RFC 4291bis if and when it gets written and a couple of other RFCs, or are we inventing a word that is likely to find its way into 2667 of the next 7400 RFCs over the next 40 years as a basic unit of measurement? If we're not doing the latter, how valuable is the definition?

Also: are we creating a term, or taking note of one in common usage? When RFC 635 referred to "48 bits of control octets", it didn't pause to say "which is to say units of 8 bits in a message as transmitted or as stored in memory"; the term had to have already been in common use and presumed to be understood by the readers. I think I can make an argument that hexadectet and hextet (which my spell checker insists on rewriting as "sextet") are common enough to be found in a search; I'm not sure a "gulp" is.

Coming back to your initial comment:

On Nov 20, 2014, at 10:03 AM, Richard Hartmann <[email-masked]> wrote:
> If this proves to be too controversial I will go the route of
> Informational Independent Submission, but I would really prefer to do
> this within this WG.

I'm not sure I would describe the effort or conclusion as "controversial", but I *would* assert that it hasn't yet led to a consensus or (better) documented an existing consensus. I'm looking for a sense of "OK, let's all call it a gulp" or whatever, followed by everyone calling it that. Absent the consensus, wherever and however it is achieved, were I in Nevil's shoes, I'm not sure I would do much with it, and I certainly can't.

In this WG, I have a charter question. If I heard a thundering sense of "The sky is falling! We have an operational problem! We need a word for a 16 bit unit of information!" I might be OK with sending the draft to may favorite AD. What I hear is a lot more like "this is a fun weekend diversion" and "if we were to establish such word, the reasonable derivation of such a word, and therefore the word, might be..." from one of several european languages and other forms of (often technically incorrect, as in "hextet") common usage.

It seems to me that whatever working group works on this needs to be in the General Area if it isn’t specifically operational and specifically about IPv6 Operations.

I’m not trying to put a damper on the discussion - it has been diverting - but trying to let you know what I’m looking for as a chair. I’m looking for usefulness in operational and standards documentation, and consensus, and ideally documentation of an already-existing consensus.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 4 Dec 2014 11:03:23 -0800

> If I may ask a silly question: are we inventing or appropriating a word for a sixteen bit chunk of an IPv6 address, which might have applicability in RFC 4291bis if and when it gets written and a c…

It’s not a silly question, but the answer depends on a subtle distinction you failed to provide.

If you are asking what is our intent, then I would say that at least in my case, the intent is to have a term which can be viable for 2667 (or however many it turns out to be) of the next 7400 (or however many it turns out to be) RFCs over the next however many years.

If you’re asking what is the {probable, intended, predicted, expected} outcome, then I would say it is difficult to predict any but the intended outcome which I think I clarified in the previous paragraph. If history has shown us anything over the past 40+ years of standards and protocol development, it’s that the expected or predicted outcomes often bear little or no resemblance to the actual outcomes and that precisely correct terms which are awkward, lengthy, or difficult to spell will almost always lose out to simplified terms that are easier to pronounce. Look at the strong pull which remains to attempt to use the word byte to define an 8-bit chunk instead of octet. Admittedly, IETF terminology has remained relatively resolute, but in my every-day life, I am routinely criticized for sticking to the term octet instead of just saying byte even though the latter is technically not necessarily accurate.

How many people on this list now the difference between a gibibit and a gigabit? I’ll note that Yosemite considers gibibit to be a spelling error while gigabit is readily accepted. How many people use the term gibibit? How many use the term gigabit interchangeably for both meanings?

[For those that are now wondering WTF? What s a gibibit and how is it different, a gigabit is 1,000,000,000 bits (1000*1000*1000) while a gibibit is 1024*1024*1024 bits (1,073,741,824 bits)].

> Also: are we creating a term, or taking note of one in common usage? When RFC 635 referred to "48 bits of control octets", it didn't pause to say "which is to say units of 8 bits in a message as tr…

I think if we are writing an RFC, then we should be attempting to take one of the terms in reasonably common usage and express it as the officially preferred terminology for that particular thing. Such an RFC should probably include a list of the other terms in previous common usage and perhaps even a summary of the reasons those terms were not selected.

Owen

---

From: James Woodyatt <[email-masked]>
Date: Thu, 4 Dec 2014 11:29:32 -0800

On Thu, Dec 4, 2014 at 11:03 AM, Owen DeLong <[email-masked]> wrote:

> > If I may ask a silly question: are we inventing or appropriating a word
> for a sixteen bit chunk of an IPv6 address, which might have applicability
> in RFC 4291bis if and when it gets written and a couple of other RFCs, or
> are we inventing a word that is likely to find its way into 2667 of the
> next 7400 RFCs over the next 40 years as a basic unit of measurement? If
> we're not doing the latter, how valuable is the definition?
>
> [...] If you are asking what is our intent, then I would say that at least
> in my case, the intent is to have a term which can be viable for 2667 (or
> however many it turns out to be) of the next 7400 (or however many it turns
> out to be) RFCs over the next however many years. [...]
>

I don't think that would be in the scope of the V6OPS charter. Maybe IETF
would like to attempt coining a good term for data structures comprising
precisely two sequential octets, but as the chair notes, V6OPS is
absolutely the wrong working group to take up that effort. Maybe we could
coin a term for the limited purpose of naming the eight 16-bit fields
comprising an IPv6 address, but I'd object to the working group spending
any temporal resources attempting to standardize it. Especially if the
awful "hextet" is the best we can do.

Let's revisit this closer to April 1.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering