Re: [v6ops] Conclusions? - Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 29, 2010 at 21:34, Doug Barton do...@dougbarton.us wrote: 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. :) 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 confusion. Given all of the above, my personal opinion is that hextet will come out as the winner. Richard PS: Thanks to Joel. I was contemplating how to refocus the whole thing and he did our job for us; and nicely.
Conclusions? - Introducing draft-denog-v6ops-addresspartnaming
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 terminology. thanks joel
Re: Conclusions? - Introducing draft-denog-v6ops-addresspartnaming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/29/2010 11:59, Joel Jaeggli wrote: | 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 terminology. 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. :) hth, Doug - -- 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. :) http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM9A5mAAoJEFzGhvEaGryEGxEH/3rs0yOYma3fWHnHc20+fxPu CTcziNHpjjkvI0bAv0V+NFAxXO350iyv18KqufyEvCuGbkT/AETfOLAr+QsDa09X vvE7/sO+XEBNuGI1f2IZiDDZQ9M4u1L5Hx+stJ6chxASXzBUHPJdNamO5DbmKU6H Wxic2+XEtBl/EvX4yB/yBJOwT7R+gjgWcQjCZ06aPmi0N45fGohhsutv7fE93qlm GCxp6zQisr88rgdgs6HyJgwc36ZmVFCqEoT8IYBYDxwWYc28S4Wb0WWd3R3rs13E 3eNysvRPPv0UxALYgecLKc/C0HOTQjfgS4YplbFL/ltHzIRLs6qPXUJyNT3XC+4= =YBMa -END PGP SIGNATURE-
RE: Introducing draft-denog-v6ops-addresspartnaming
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.
Re: Introducing draft-denog-v6ops-addresspartnaming
On Nov 26, 2010, at 2:11 PM, kmedc...@dessus.com wrote: 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) purpose. While windows certainly qualifies as nefarious, I doubt anyone would consider it tight or well written code. Owen
Re: Introducing draft-denog-v6ops-addresspartnaming (fwd)
Documenting my support publically, as requested. --- Jay -- Forwarded message -- Date: Mon, 22 Nov 2010 23:26:31 +0100 From: Richard Hartmann richih.mailingl...@gmail.com To: Jay Nugent j...@nuge.com Subject: Re: Introducing draft-denog-v6ops-addresspartnaming On Mon, Nov 22, 2010 at 19:46, Jay Nugent j...@nuge.com wrote: Â I like hexquad for any value between the colons being greater than zero. Â Example :abcd: OK, noted :) Are you willing to answer on-list to document your support publically? Â I like hexnot when the value between the colons is zero. Â Example :: I honestly think that they look and sound way too similar which may lead to confusion. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
If we can't choose mouthful (which for some reason sounds thematically correct), chunk gets my vote. *(Chunk = Maybe not the most technical, but has been working for me all along ...)* Chunk is at least the proper English term for these bits between the colons. The process of breaking up a long string into shorter substrings is already known as chunking. With IPv4, the chunking was done on octet boundaries so people used the specific term octet instead of the more general chunk. But in the absence of a specific term, chunk is the correct and proper way to refer to these bits. IPv6 addresses are chunked into 16 bit chunks and each chunk is written down in hexadecimal notation with a colon between the chunks. For example, 805B:2D9D:DC28:::FC57:D4C8:1FFF. Of course there are some other rules that allow for shorter strings but they all start with the 8 chunks separated by colons. The last 4 chunks represent the interface identifier and the first 4 chunks are the network prefix. -- Michael Dillon
Re: Introducing draft-denog-v6ops-addresspartnaming
On Nov 22, 2010, at 5:05 PM, TJ trej...@gmail.com wrote: On Fri, Nov 19, 2010 at 08:14, Scott Morris s...@emanon.com wrote: If 8 bits is a byte, then 16 bits should be a mouthful. Scott If we can't choose mouthful (which for some reason sounds thematically correct), chunk gets my vote. *(Chunk = Maybe not the most technical, but has been working for me all along ...)* /TJ I think each section should be a nom, and :: can be a om. My lolcat agrees.
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sat, Nov 20, 2010 at 23:15, Owen DeLong o...@delong.com wrote: You seem to be indirectly answering the parent posting in much of what you say. That is fine, I just wanted to point it out. It's a commonly accepted, well-defined convention to save humans effort while not sacrificing readability. There are weirder things in technology. I don't think it's all that weird and it's a major savings in writing out IPv6 addresses and being able to read them (except in lists of varying sized addresses (please, when dumping routing tables and such, just keep the optional zeroes or give us a flag to choose). In practice, the :: usually ends up being placed between the network number and the host number for things with static addresses and rarely appears in EUI-64 based addresses, so, I don't see this as a problem. FWIW, I do not see it as weird or as a problem, either. There are weirder things does not mean the thing I am referring to is weird itself :) I don't see a problem with people not assigning customers /56s so long as they go in the correct direction and give /48s and not /60s or /64s. Many ISPs will end up handing their customers /64, /62 or other less-than-ideal prefixes. As soon as a customer needs to subnet their /64, the real fun starts. There is nothing we can do about it, other than trying to educated people and hope for the best. I honestly think I never explained (as in, after I understood the matter, myself) netmasks other than as a bit vector. Unless you mean write 255.255.255.0 in there cause that's what right for you. Then you are young and never had to deal with systems that didn't know about bit-vector syntax. I have had to explain the translation between bit-vector syntax (/n) and bit-field syntax (255.255.255.240) to many people. It's easy when n is a multiple of 8. After that, it can be quite hard for some mathematically challenged individuals unfamiliar with binary and BCD to wrap their heads around. I wish ;) Either the person can grasp that a dotted netmask can be transformed into a bit vector or I tell them use 255.255.255.0 everywhere, it will work for everything you will ever need. 80/20 and all that. Removing bitmath from operations where possible is a good thing that reduces outages caused by human factors. It's just good human factors engineering. We can't do so in IPv4, there aren't enough bits to do it. We seek to do so in IPv6 with ARIN draft policy 2010-8 and proposal 121. If by bitmath you mean ending netmasks not on full bytes only, I could not agree more. This will reduce a lot of useless overhead. I really wish the RIRs would get unique a name space for their respective drafts. If even my person object needs a -RIPE suffix, I don't see why drafts etc don't. Should we all sing kumbayah now? Only if you bring a tambourine. Basically, as I recall the earlier discussions of this and the IETF arriving at the decision to use colon (:), it boiled down to the simple fact that colon (:) is the worst choice except for all the others. Agreed. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sun, Nov 21, 2010 at 16:54, William Herrin b...@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
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sun, Nov 21, 2010 at 23:15, Owen DeLong o...@delong.com wrote: In fact, it would look pretty weird to most people if we started writing 951-21-42-33 (or I bet they wouldn't expect that was a zip code in any case). Similarly, if we start placing the separators in arbitrary places in phone numbers, people get confused. The complete uniformity of telephone numbers seems to be a North American phenomena, but as a German who is used to wildly different phone numbers, I would still prefer a common scheme for all of them, yes. I still disagree. While I noted the one pathology with the current system, that same pathology is present with floating colons and there are others which I also pointed out (difficulty in reproducing the correct placement of the floating colons in automated output, for example. Even worse, allowing floating colons will mean different groups will adapt different defaults. Not a desirable goal. The syntax for handling this was already present in IPv4 and is easily adapted to the problem in IPv6. Simply wrap the IPv6 address in square brackets (e.g. [2001:db8:feed::cafe]:80 is the ipv6 address 2001:db8:feed::cafe on port 80). Which is admittedly ugly, but I can't think of anything better, either. We did forego ::192.168.1.1. However, we still have :::192.168.1.1 and for good reason. This is a useful construct for allowing humans to see in log files that an IPv6-aware application on a dual-stack machine accepted an IPv4 connection on an IPv6 socket. Agreed. Ugly, but useful needed. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
Please don't group several emails into one. It breaks threads. And while I could not find anything about this in the NANOG FAQ, it's common netiquette not to do so. On Sun, Nov 21, 2010 at 23:50, William Herrin b...@herrin.us wrote: On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli joe...@bogus.com wrote: Looks like an ass-u-me. If you think the use if IPv4 addresses in URLs is infrequent, it's mostly u. Get out in the field some time. Ad hominem usually does not do much to maintain or improve the quality of a discussion. That server op is the kind of guy we're asking to understand that there's nothing special about the two bytes between the colons in the IPv6 address. He's gonna be trouble. As you described yourself, he is gonna be trouble anyway. People end up working around him anyway, so why bother to cater to his needs? Especially as the fixed colons are here to stay and a good thing, also. On Sun, Nov 21, 2010 at 1:42 PM, valdis.kletni...@vt.edu wrote: Whatever you want to do. That's the point of optional/movable separators. Principle of least surprise. On Sun, Nov 21, 2010 at 5:15 PM, Owen DeLong o...@delong.com wrote: That would be a more compelling argument if it accurately described phone number notation. It doesn't. +44 121 410 5228, for example, is the phone number for parking services at Heathrow airport, exactly as described on http://www.heathrowairport.com/'s contact us page. No dashes at all, and not 10 digits. The UK is not part of the USA nor of Canada. IPv6 is one of very few addressing schemes in which the separators intentionally have no greater meaning within the protocol or its use. As has been pointed out several times before, helping humans reduce errors is a highly desirable goal. _And_ the discussion is moot anyway. I think I am at a point where I will simply ignore any new occurrences of this theme. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
[ Meant to send this to the list and not directly to Richard. ] On Fri, Nov 19, 2010 at 03:07:40AM +0100, Richard Hartmann wrote: If any of you have any additional suggestions, you are more than welcome to share them. I heard hexquad somewhere awhile back and have been using it since... looking over the other options present in your poll, I think I still prefer it, but I could live with either hextet or simply quad as well. --Jeff
Re: Introducing draft-denog-v6ops-addresspartnaming
For the sake of completeness, the relevant part of what I answered privately can be found below. On Mon, Nov 22, 2010 at 13:22, Jeff Aitken jait...@aitken.com wrote: [ Meant to send this to the list and not directly to Richard. ] On Fri, Nov 19, 2010 at 03:07:40AM +0100, Richard Hartmann wrote: If any of you have any additional suggestions, you are more than welcome to share them. I will add quad to -03 anyway. If you get a few +1 on hexquad, I am against adding that, as well. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 22, 2010 at 6:40 AM, Richard Hartmann richih.mailingl...@gmail.com wrote: On Sun, Nov 21, 2010 at 16:54, William Herrin b...@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. Richard, A route prefix is always trimmed on the right. Always. That's why we call it a PREfix. Trimming zeros on both the left and the right, as the correctly written IPv6 notation 1::/16 would have us do, is confusing. It's like writing one million and one tenth as 1,,.1 instead of 1,000,000.1. Please don't group several emails into one. It breaks threads. And while I could not find anything about this in the NANOG FAQ, it's common netiquette not to do so. Six of one, half a dozen of the other. Flooding a list with half a dozen replies on the same thread at the same time is poor netiquette for its impact on unthreaded mail agents and if your mailer started a new thread for this message in spite of the identical subject and in-reply-to header then it's broken. On Sun, Nov 21, 2010 at 23:50, William Herrin b...@herrin.us wrote: Looks like an ass-u-me. If you think the use if IPv4 addresses in URLs is infrequent, it's mostly u. Get out in the field some time. Ad hominem usually does not do much to maintain or improve the quality of a discussion. Insolence alone does not rise to argumentum ad hominem. The predicate assumption is wrong. Here's several paragraphs about what's actually observed in the field, certainly isn't. If you want to call me out on a logical fallacy, at least call me out on one I've actually committed. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Introducing draft-denog-v6ops-addresspartnaming
I don't see a problem with people not assigning customers /56s so long as they go in the correct direction and give /48s and not /60s or /64s. Many ISPs will end up handing their customers /64, /62 or other less-than-ideal prefixes. As soon as a customer needs to subnet their /64, the real fun starts. There is nothing we can do about it, other than trying to educated people and hope for the best. If we educate a sufficient percentage of ISPs and solve the perception problems of the RIR policies that are driving some ISPs to be overly conservative (see proposal 121 in the ARIN region for an example of what I think represents a reasonable solution), then, the other ISPs will eventually find themselves at a competitive disadvantage as their customers start to ask Why can't I have a /48 like my friend Bob got from provider Z? This is a good thing, but, it means we need to do what we can to educate as many ISPs as possible as quickly as possible during this critical phase of deployment. I honestly think I never explained (as in, after I understood the matter, myself) netmasks other than as a bit vector. Unless you mean write 255.255.255.0 in there cause that's what right for you. Then you are young and never had to deal with systems that didn't know about bit-vector syntax. I have had to explain the translation between bit-vector syntax (/n) and bit-field syntax (255.255.255.240) to many people. It's easy when n is a multiple of 8. After that, it can be quite hard for some mathematically challenged individuals unfamiliar with binary and BCD to wrap their heads around. I wish ;) Either the person can grasp that a dotted netmask can be transformed into a bit vector or I tell them use 255.255.255.0 everywhere, it will work for everything you will ever need. 80/20 and all that. Ah... OK... Sorry, I'm the guy that had to deal with all of your users when they found themselves on one of my /27s and tried to use 255.255.255.0 there. :p So... Don't worry, I ended up picking up the educational task where you left off. (OK, maybe not the exact same set of users, but, honest, you're not the only one who took this approach and it did lead to interesting breakages by users so educated in a number of places I have worked.) Removing bitmath from operations where possible is a good thing that reduces outages caused by human factors. It's just good human factors engineering. We can't do so in IPv4, there aren't enough bits to do it. We seek to do so in IPv6 with ARIN draft policy 2010-8 and proposal 121. If by bitmath you mean ending netmasks not on full bytes only, I could not agree more. This will reduce a lot of useless overhead. I really wish the RIRs would get unique a name space for their respective drafts. If even my person object needs a -RIPE suffix, I don't see why drafts etc don't. Well, in IPv6, I think ending them on nibbles is fine. Specifically, see ARIN Policy Proposal 121 (as mentioned above). Should we all sing kumbayah now? Only if you bring a tambourine. LoL Sorry, I don't own a tambourine. Owen
Re: Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 22, 2010 at 15:07, William Herrin b...@herrin.us wrote: Trimming zeros on both the left and the right, as the correctly written IPv6 notation 1::/16 would have us do, is confusing. It's like writing one million and one tenth as 1,,.1 instead of 1,000,000.1. No, there are simply two mechanisms at work: I start with 0001:::::::/16 then, I remove leading zeros as they are not needed 1:::::::/16 which I can further reduce by the same mechanism to 1:0:0:0:0:0:0/16 Finally, the accepted convention for IPv6 addresses is that I can drop a continuous block of zeros which means I end up with 1::/16 Makes perfect sense to me. Six of one, half a dozen of the other. Flooding a list with half a dozen replies on the same thread at the same time is poor netiquette for its impact on unthreaded mail agents and if your mailer started a new thread for this message in spite of the identical subject and in-reply-to header then it's broken. I disagree, but if you want to continue this part of the discussion, we should do so off-list. I do apologize that I wrote this in-line and did not poke you off-list in the first place. Insolence alone does not rise to argumentum ad hominem. The predicate assumption is wrong. Here's several paragraphs about what's actually observed in the field, certainly isn't. If you want to call me out on a logical fallacy, at least call me out on one I've actually committed. I called out a social, not a logical, fallacy. As per the rest, see above. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
Richard Hartmann richih.mailingl...@gmail.com writes:
I will add quad to -03 anyway. If you get a few +1 on hexquad, I am
against adding that, as well.
Quad is a standard term for 64 bit integer in C/C++. For
example:
$ grep -c quad /usr/src/sys/netinet6/*|awk -F: '{tot+=$2} END{print tot}'
171
which is to say, the kame derived ipv6 stack on this machine uses
one of the *quad_t types 171 times.
Ambiguating usages like Take the least signifigant quad of that
ipv6 address to mean either 16 bits or 64 bits, when it currently is
unamibigously 64 bits won't make the lives of C/C++ programmers
writing IPv6 code any easier.
Re: Introducing draft-denog-v6ops-addresspartnaming
Given that a meal is often comprised of several mouthfuls, wouldn't it stand to reason that the entire address would suffice there? ;) Scott On 11/19/10 11:06 AM, Richard Hartmann wrote: On Fri, Nov 19, 2010 at 14:14, Scott Morris s...@emanon.com wrote: If 8 bits is a byte, then 16 bits should be a mouthful. When does it become a meal and, more importantly, do you want to supper (sic) size? RIchard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 22, 2010 at 16:23, Owen DeLong o...@delong.com wrote: then, the other ISPs will eventually find themselves at a competitive disadvantage as their customers start to ask Why can't I have a /48 like my friend Bob got from provider Z? I kinda implied that, but yes, I should have written it out. Thanks :) So... Don't worry, I ended up picking up the educational task where you left off. Even though this is getting kinda off topic: In my private life, I either explain what a bit vector is or I tell them to use a /24. In my professional life, I either deal with people who can grasp the bit vector thing or they bought the complete care package anyway, meaning that we tell them where to click on the CMS to make the colourful overload they call a website go bling. In the latter case, I don't have to explain anything because a) that part is handled by someone else b) they have no interest whatsoever in learning what an IP address is, let alone a netmask. (OK, maybe not the exact same set of users, but, honest, you're not the only one who took this approach and it did lead to interesting breakages by users so educated in a number of places I have worked.) The question is: Would those users have acted any differently if someone went to the trouble of explaining in depth what they would have forgotten within days? Well, in IPv6, I think ending them on nibbles is fine. Hmm, true. That's fine, too. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 22, 2010 at 18:33, Daniel Hagerty h...@linnaean.org wrote: Ambiguating usages like Take the least signifigant quad of that ipv6 address to mean either 16 bits or 64 bits, when it currently is unamibigously 64 bits won't make the lives of C/C++ programmers writing IPv6 code any easier. Agreed. Thanks a lot for pointing this out. Comments like this are incredibly valuable to me. I think I will still add quad to -03 as it has been requested a lot of times, but more to point out and document that there is a significant problem with it than anything else. Thanks again, Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Friday, November 19, 2010 08:14:52 am Scott Morris wrote: If 8 bits is a byte, then 16 bits should be a mouthful. I thought the Jargon File settled that long ago: 4 bits = nybble, 8 bits = byte, 16 bits = playte, 32-bits = dynner. See http://dictionary.die.net/nybble Since the zeros between double colons are indefinite length, call it the voyd and be done.
Re: Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 22, 2010 at 14:05, Richard Hartmann richih.mailingl...@gmail.com wrote: I will add quad to -03 anyway. If you get a few +1 on hexquad, I am against adding that, as well. Erm. Belated, but I am _not_ against adding etc pp. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Fri Nov 19 11:05:33 2010 Subject: Re: Introducing draft-denog-v6ops-addresspartnaming From: Owen DeLong o...@delong.com Date: Fri, 19 Nov 2010 08:58:45 -0800 To: Richard Hartmann richih.mailingl...@gmail.com Cc: bmann...@vacation.karoshi.com, nanog@nanog.org On Nov 19, 2010, at 12:57 AM, Richard Hartmann wrote: On Fri, Nov 19, 2010 at 07:00, bmann...@vacation.karoshi.com wrote: 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. 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. I suppose one could call the explicitly-present fields 'bi-bytes', and the compressed-out sequence the 'bye-bytes'.
Re: Introducing draft-denog-v6ops-addresspartnaming
From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Fri Nov 19 14:18:02 2010 Date: Fri, 19 Nov 2010 12:19:34 -0800 From: Joel Jaeggli joe...@bogus.com To: Owen DeLong o...@delong.com Subject: Re: Introducing draft-denog-v6ops-addresspartnaming Cc: bmann...@vacation.karoshi.com, nanog@nanog.org On 11/19/10 10:56 AM, Owen DeLong wrote: 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... Assuming you have a v6 stack on your cdc6600 a v6 address fits in 22 bytes not 16. pedant 3 words of CPU memory (with 50+ bits available to possibly pack 'something else useful' in.) One could get away with 11 words of PPU memory, but that would require pack/unpack on every move between CPU-PPU address-spaces. /pedant just implementing a KR 'C' compiler was a real challenge on that hardware. :) One can define that byte size for the purposes of the human reading of addresses ipv6 as 8 bits, without getting into machine specific details. what's important to the machine isn't the division of the address into parts (they aren't divided in the machine representation it's just one long row of bits) but rather where the mask falls. Yup. When talking IP, the 'network byte size' is fixed at 8 bits. This is 'cast in stone', as is 'network byte order', and 'bit order'. If the 'scope' of the term is restricted to Internet protocol/connectivity contexts, one can use 'byte' unambiguously as a referant to an 8-bit qty.
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 08:14, Scott Morris s...@emanon.com wrote: If 8 bits is a byte, then 16 bits should be a mouthful. ;) Scott If we can't choose mouthful (which for some reason sounds thematically correct), chunk gets my vote. *(Chunk = Maybe not the most technical, but has been working for me all along ...)* /TJ
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sat, Nov 20, 2010 at 5:15 PM, Owen DeLong o...@delong.com wrote: fd00:68::1 and fd:0068::1 mean different things now. The former means fd00:0068::1 while the latter means 00fd:0068::1. I would instead have them mean the same thing: fd00:6800::1. The single-colon separator gets syntax but no semantics I am not sure if this would actually be an advantage. It would actually be a huge disadvantage. [...] Where this becomes unfortunate is when people make the mistake of writing things like fd/8 or worse, fd::/8. Technically both of these are not correct. fd/8 is simply invalid syntax. The human eye will turn it into fd00::/8 because that's the only possible logical meaning that makes any sense. fd::/8 is worse because the human eye will turn it into fd00::/8 as that is again, the only sensible thing it could represent, while, in fact, as written it means 0::/8. So... You just dissed my screed about IPv6 notation and then offered two fantastic arguments why I'm right... 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. 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? 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. 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. 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. Dash is a poor choice because it becomes potentially problematic to know whether your cisco is telling you that: 2001-0db8-5f03 is a MAC address or a /48 prefix. Cisco's expression of a MAC address is wrong anyway. Correct notation for a MAC address is separating each byte with a colon. This has always been a PIA for me any time I need to copy a MAC address in to or out of a Cisco config. Basically, as I recall the earlier discussions of this and the IETF arriving at the decision to use colon (:), it boiled down to the simple fact that colon (:) is the worst choice except for all the others. Could have stuck with dot and forgone ::192.168.1.1. Or replaced the v4 dot with a dash in that scenario. Could have gone with comma and quoted the address in CSV files like you do for any text value that isn't trivial, instead of bracketing it in much more commonly used URLs. For example: 260:abcde:123456:98::1 260 - IANA to ARIN, a /12 abcde - ARIN to ISP, a /32 123456 - ISP to customer, a /56 98 - customer subnet ::1 - LAN address How do you propose to get the router to regurgitate this? I don't. The colons float. If the address was learned dynamically, the router can regurgitate it any way it wants. 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. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Introducing draft-denog-v6ops-addresspartnaming
On 11/21/10 7:54 AM, William Herrin wrote: 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. 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. The benefits of hindsight are myriad... The uri schema is contemporaneous with rfc 1883 as is a lot of formative work in a lot of areas 1992-1994 range. There is a lot of assumption on the part of ipv6 that the use of ipv6 literals in uri's would be a rather infrequent occurrence, given how infrequent it is in ipv4 it would seem to be a reasonable assumption.
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sat, 20 Nov 2010 12:12:09 EST, William Herrin said: 260:abcde:123456:98::1 260 - IANA to ARIN, a /12 abcde - ARIN to ISP, a /32 123456 - ISP to customer, a /56 98 - customer subnet ::1 - LAN address What do you do when ARIN gives Tier1 a /24, and Tier1 gives Billy Bob's Bait, Tackle, and Internet a /40, and Billy Bob gives one of their customers a /56? pgpgpCRMEjh8M.pgp Description: PGP signature
Re: Introducing draft-denog-v6ops-addresspartnaming
On Nov 21, 2010, at 7:54 AM, William Herrin wrote: On Sat, Nov 20, 2010 at 5:15 PM, Owen DeLong o...@delong.com wrote: fd00:68::1 and fd:0068::1 mean different things now. The former means fd00:0068::1 while the latter means 00fd:0068::1. I would instead have them mean the same thing: fd00:6800::1. The single-colon separator gets syntax but no semantics I am not sure if this would actually be an advantage. It would actually be a huge disadvantage. [...] Where this becomes unfortunate is when people make the mistake of writing things like fd/8 or worse, fd::/8. Technically both of these are not correct. fd/8 is simply invalid syntax. The human eye will turn it into fd00::/8 because that's the only possible logical meaning that makes any sense. fd::/8 is worse because the human eye will turn it into fd00::/8 as that is again, the only sensible thing it could represent, while, in fact, as written it means 0::/8. So... You just dissed my screed about IPv6 notation and then offered two fantastic arguments why I'm right... 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. That's not a reason you're correct, it's a recognition of one of the warts in the current system and a statement that on the rare occasion when people are writing IPv6 addresses, they need to do so with care. So long as one writes the IPv6 address correctly, it is not hard to read. There is no problem with the understanding of fd00::/8 for both humans and machines. In fact, fd::/8 would be interpreted, I estimate, by approximately 80% of people as fd00::/8 and by the other 20% who are used to working with numbers and computers as 00fd::/8 until they realized that the person responsible for that scrawl must have meant fd00::/8. Thus, it is an ambiguous representation open to convenient misinterpretation. The problem with your idea comes when we move on to fd::/16. In the current system, this is a valid syntax for 00fd::/16. In your system, would this mean 00fd::/16 or would it mean fd00::/16? Both are equally valid as I see it. Certainly there is the likelihood for much confusion even if you have rules that cover it. 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? If this were prose, sure. It isn't. It's an addressing scheme. I mean, really, we don't question 9-1520 or 408-555-1212 which are much more like what we're talking about. In fact, it would look pretty weird to most people if we started writing 951-21-42-33 (or I bet they wouldn't expect that was a zip code in any case). Similarly, if we start placing the separators in arbitrary places in phone numbers, people get confused. 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. I still disagree. While I noted the one pathology with the current system, that same pathology is present with floating colons and there are others which I also pointed out (difficulty in reproducing the correct placement of the floating colons in automated output, for example. 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. The syntax for handling this was already present in IPv4 and is easily adapted to the problem in IPv6. Simply wrap the IPv6 address in square brackets (e.g. [2001:db8:feed::cafe]:80 is the ipv6 address 2001:db8:feed::cafe on port 80). 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. Really, there's no advantage whatsoever to this. All it does is make talking about address structure more complicated. Having a universal name will reduce the occurrence of local arbitrary naming which I believe is a useful practice. Dash is a poor choice because it becomes potentially problematic to know whether your cisco is telling you that: 2001-0db8-5f03 is a MAC address or a /48 prefix. Cisco's expression of a MAC address is wrong anyway. Correct notation for a MAC address is separating each byte with a colon. This has always been a PIA for me any time I need to copy a MAC address in to or out of a Cisco config. Doesn't matter... It's widespread and Cisco isn't the only one to use it. As such, doing this to IPv6 addresses is a recipe for pain. Basically, as I recall the earlier discussions of this and the IETF arriving at the decision to
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli joe...@bogus.com wrote: There is a lot of assumption on the part of ipv6 that the use of ipv6 literals in uri's would be a rather infrequent occurrence, given how infrequent it is in ipv4 it would seem to be a reasonable assumption. Joel, Looks like an ass-u-me. If you think the use if IPv4 addresses in URLs is infrequent, it's mostly u. Get out in the field some time. I've yet to work for a non-ISP that (before I arrived) maintained their internal DNS consistently vice using address literals. If the company was small, they didn't really know how to operate a DNS server. If large, the DNS ops were too inaccessible to be consulted on things that weren't also being reviewed by PR for release to the general public. In fact, in one project I occasionally work on, the team is -frequently- told by the DNS op for the NIPR-based DNS server how bothered he is by the lookup count, so won't we please place commonly used Internet names in our /etc/hosts. My jaw dropped the first time I heard that one. That server op is the kind of guy we're asking to understand that there's nothing special about the two bytes between the colons in the IPv6 address. He's gonna be trouble. On Sun, Nov 21, 2010 at 1:42 PM, valdis.kletni...@vt.edu wrote: On Sat, 20 Nov 2010 12:12:09 EST, William Herrin said: 260:abcde:123456:98::1 260 - IANA to ARIN, a /12 abcde - ARIN to ISP, a /32 123456 - ISP to customer, a /56 98 - customer subnet ::1 - LAN address What do you do when ARIN gives Tier1 a /24, and Tier1 gives Billy Bob's Bait, Tackle, and Internet a /40, and Billy Bob gives one of their customers a /56? Whatever you want to do. That's the point of optional/movable separators. An option w/ movable separators: 260:abc:1234:9876:fe::1 Actual IPv6 standard (and also allowed w/ movable separators): 260a:bc12:3498:76fe::1 On Sun, Nov 21, 2010 at 5:15 PM, Owen DeLong o...@delong.com wrote: 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? If this were prose, sure. It isn't. It's an addressing scheme. I mean, really, we don't question 9-1520 or 408-555-1212 which are much more like what we're talking about. In fact, it would look pretty weird to most people if we started writing 951-21-42-33 (or I bet they wouldn't expect that was a zip code in any case). Similarly, if we start placing the separators in arbitrary places in phone numbers, people get confused. That would be a more compelling argument if it accurately described phone number notation. It doesn't. +44 121 410 5228, for example, is the phone number for parking services at Heathrow airport, exactly as described on http://www.heathrowairport.com/'s contact us page. No dashes at all, and not 10 digits. And BTW, 408-555-1212 isn't arbitrarily separated. Each component has a specific meaning. Long distance region 408, telco reserved prefix 555, long distance information 1212. The Zip code's components also have meaning. The left 5 digits indicate the specific post office and the right 4 digits usually specify the internal box number used for sorting the mail. Even IPv4's dot separators were placed in meaningful locations in the original Classful design. The network address was always the whole content to the left of one of the dots while the host address was always the whole content to the right. Unless the network was complex enough to have a subnet address in the middle, still confined by the dots. It's an anachronism now, but the separators were originally important. IPv6 is one of very few addressing schemes in which the separators intentionally have no greater meaning within the protocol or its use. They're just there. If we want folks to understand that difference from their normal experience with addressing notations, we'll have to call attention to it by, for example, leaving the byte groupings formally unnamed. Dash is a poor choice because it becomes potentially problematic to know whether your cisco is telling you that: 2001-0db8-5f03 is a MAC address or a /48 prefix. 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. -Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
RE: Introducing draft-denog-v6ops-addresspartnaming
An option w/ movable separators: 260:abc:1234:9876:fe::1 Actual IPv6 standard (and also allowed w/ movable separators): 260a:bc12:3498:76fe::1 The problem with movable separators is in handling zeros. If the separators are a known distance apart, zeros can be deduced. The example above has only one zero. Imagine it were a different address: 260a:0:8:65::1 Now with movable separators the the zeros would be explicit because you don't know how far apart the colons are n the address. In your example, it would become: 260:a00::0800:65::1 because there is no way to tell from a movable colon address how many places the colon was moved and how many zeros there are between them. You can move colons as long as zeros are explicit but you must have fixed colons if zeros are implicit. Otherwise there is no way to deduce where the zeros go from simply parsing the address.
Re: Introducing draft-denog-v6ops-addresspartnaming
On 21/11/2010 22:50, William Herrin wrote: 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. Brocade, or at least the Foundry part of Brocade. Nick
Re: Introducing draft-denog-v6ops-addresspartnaming
On 11/21/10 2:50 PM, William Herrin wrote: On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli joe...@bogus.com wrote: There is a lot of assumption on the part of ipv6 that the use of ipv6 literals in uri's would be a rather infrequent occurrence, given how infrequent it is in ipv4 it would seem to be a reasonable assumption. Joel, Looks like an ass-u-me. If you think the use if IPv4 addresses in URLs is infrequent, it's mostly u. Get out in the field some time. In the situation where, load balancers, virtual hosting and named ssl certs are the lingua franca, ip4 literals have rather limited usable scope. there have been a couple of studies associated with thinking about protcol translation, which if they're not totally off-base in fact conclude their usage in public services is rather rare. if you really want to type something like: http://[2001:490:f000:16:20c:29ff:fe95:c05d]:8080 to reach a freshly provisioned host, I don't think adding the brackets is the bulk of the effort and I kinda doubt google is going to help you complete it. I've yet to work for a non-ISP that (before I arrived) maintained their internal DNS consistently vice using address literals. If the company was small, they didn't really know how to operate a DNS server. If large, the DNS ops were too inaccessible to be consulted on things that weren't also being reviewed by PR for release to the general public. I am aware of locations where the operation of the DNS is not a source of competitive advantage, I may in fact work in one, that said without it you're going to be in more hurt than in ipv4. In fact, in one project I occasionally work on, the team is -frequently- told by the DNS op for the NIPR-based DNS server how bothered he is by the lookup count, so won't we please place commonly used Internet names in our /etc/hosts. My jaw dropped the first time I heard that one. That server op is the kind of guy we're asking to understand that there's nothing special about the two bytes between the colons in the IPv6 address. He's gonna be trouble. On Sun, Nov 21, 2010 at 1:42 PM, valdis.kletni...@vt.edu wrote: On Sat, 20 Nov 2010 12:12:09 EST, William Herrin said: 260:abcde:123456:98::1 260 - IANA to ARIN, a /12 abcde - ARIN to ISP, a /32 123456 - ISP to customer, a /56 98 - customer subnet ::1 - LAN address What do you do when ARIN gives Tier1 a /24, and Tier1 gives Billy Bob's Bait, Tackle, and Internet a /40, and Billy Bob gives one of their customers a /56? Whatever you want to do. That's the point of optional/movable separators. An option w/ movable separators: 260:abc:1234:9876:fe::1 Actual IPv6 standard (and also allowed w/ movable separators): 260a:bc12:3498:76fe::1 On Sun, Nov 21, 2010 at 5:15 PM, Owen DeLong o...@delong.com wrote: 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? If this were prose, sure. It isn't. It's an addressing scheme. I mean, really, we don't question 9-1520 or 408-555-1212 which are much more like what we're talking about. In fact, it would look pretty weird to most people if we started writing 951-21-42-33 (or I bet they wouldn't expect that was a zip code in any case). Similarly, if we start placing the separators in arbitrary places in phone numbers, people get confused. That would be a more compelling argument if it accurately described phone number notation. It doesn't. +44 121 410 5228, for example, is the phone number for parking services at Heathrow airport, exactly as described on http://www.heathrowairport.com/'s contact us page. No dashes at all, and not 10 digits. And BTW, 408-555-1212 isn't arbitrarily separated. Each component has a specific meaning. Long distance region 408, telco reserved prefix 555, long distance information 1212. The Zip code's components also have meaning. The left 5 digits indicate the specific post office and the right 4 digits usually specify the internal box number used for sorting the mail. Even IPv4's dot separators were placed in meaningful locations in the original Classful design. The network address was always the whole content to the left of one of the dots while the host address was always the whole content to the right. Unless the network was complex enough to have a subnet address in the middle, still confined by the dots. It's an anachronism now, but the separators were originally important. IPv6 is one of very few addressing schemes in which the separators intentionally have no greater meaning within the protocol or its use. They're just there. If we want folks to understand that difference from their normal experience with addressing notations, we'll have to call attention to it by, for example, leaving the byte groupings formally unnamed. Dash is a poor choice because it becomes potentially problematic to know whether your cisco is telling you
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sun, Nov 21, 2010 at 5:15 PM, Owen DeLong o...@delong.com wrote: 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? If this were prose, sure. It isn't. It's an addressing scheme. I mean, really, we don't question 9-1520 or 408-555-1212 which are much more like what we're talking about. In fact, it would look pretty weird to most people if we started writing 951-21-42-33 (or I bet they wouldn't expect that was a zip code in any case). Similarly, if we start placing the separators in arbitrary places in phone numbers, people get confused. That would be a more compelling argument if it accurately described phone number notation. It doesn't. +44 121 410 5228, for example, is the phone number for parking services at Heathrow airport, exactly as described on http://www.heathrowairport.com/'s contact us page. No dashes at all, and not 10 digits. Sure, but, try presenting a NANPA phone number in that format to just about anyone in the US and you'll get a pretty perplexed look. In fact, many people have a great deal of difficulty when confronted with +1 408 555 1212, let alone something like +1 40 85 55 12 12 or any other derivitave you might want to come up with. The Zip code's components also have meaning. The left 5 digits indicate the specific post office and the right 4 digits usually specify the internal box number used for sorting the mail. Which is why I offered 951-21-42-33 as an alternative... Turns out that has significance too... 951 is the bulk mail center. 21 is the post office within the bulk mail center service area. 42 is the carrier route and 33 is of local significance within the route. Most post offices have two zip codes... The second one is usually the standard zip++ and is used for po boxes where the format is BBBpX- whiere BBB is still the builk mail center, but, X- is the P.O. Box. We could also move on to SSNs which would confuse people no end if you wrote them as 57523-1234 rather than as 575-23-1234. In fact, you could have lots of fun writing zip codes as 951-21-4223 and SSNs as 57523-1234. IPv6 is one of very few addressing schemes in which the separators intentionally have no greater meaning within the protocol or its use. They're just there. If we want folks to understand that difference from their normal experience with addressing notations, we'll have to call attention to it by, for example, leaving the byte groupings formally unnamed. I don't think leaving the hextets unnamed helps with that in any meaningful way. As I said, the only thing you accomplish by leaving it formally unnamed is to cause everyone to make up their own local name and expand the confusion. Dash is a poor choice because it becomes potentially problematic to know whether your cisco is telling you that: 2001-0db8-5f03 is a MAC address or a /48 prefix. 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. Cisco alone is a sufficient sample of the market to constitute widespread usage. However, several router vendors that have cloned Cisco behaviors and command-line syntax have also cloned this mess. I don't recall their names for certain off the top of my head, but, I know I've encountered it on non-Cisco routers. Owen -Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 23:52, William Herrin b...@herrin.us wrote: I thought about that. Have a one colon rule that IPv6 addresses in hexidecimal format have to include at least one colon somewhere. The regex which picks that token out versus the other possibilities is easy enough to write and so is the human rule: Oh, it's got hexidecimal digits and a colon in it. IPv6 address. Even if this were feasible at this point, and it's not, this would still make it hard for humans to detect an IPv6 address at a glance, makes it impossible to quickly pick out any sections that are more relevant at the moment and would hog the colon for all eternity, blocking it for other uses. Also, this would make adding a port even more cumbersome. fd00:68::1 and fd:0068::1 mean different things now. The former means fd00:0068::1 while the latter means 00fd:0068::1. I would instead have them mean the same thing: fd00:6800::1. The single-colon separator gets syntax but no semantics I am not sure if this would actually be an advantage. and the :: separator means all middle nibbles are zero instead of all middle two-byte components are zero. Putting the burden of parsing that on humans (and computers). Same as modern compression algorithms are optimized to doing more work while encoding and less work during decoding, it does not really make sense to make it harder to understand an address while reading it for the dubious gain of saving up to six colons. I mean, when you think about it, the consequence that :: means all middle two-byte components are zero is kinda weird. It's a commonly accepted, well-defined convention to save humans effort while not sacrificing readability. There are weirder things in technology. Anything you call out will be interpreted as special. The more you call it out, the greater the expectation that the distinction is important. That's human nature. Pattern recognition is a central part of our intelligence, so yes, it's human nature. This is not necessarily a bad thing. While I agree that some of the delimitations are social, rather than technical, it's still useful to have them. If this results in some people not assigning their customers a /56 cause it looks funny, so be it. You've explained netmasks before to folks whose brains couldn't get past the dots in the address. We all have. I honestly think I never explained (as in, after I understood the matter, myself) netmasks other than as a bit vector. Unless you mean write 255.255.255.0 in there cause that's what right for you. And referring to IP address notation as dotted quads just reinforces classful addressing concepts so that folks assigning themselves 10/8 subnets damn near always split on /16 and /24 boundaries. And why shouldn't they? Unless they are a large ISP or similar, they will have enough space for pretty much everything they ever need to do. It's as good as anything and it allows people to be somewhat familiar with this stuff. Not everyone is an expert and that is fine. Personally, I have no motivation whatsoever to _truly_ understand _everything_ that's involved in today's wireless systems. Still, it's nice that I can use them reliably without needing this level of involvement. And even more efficiently when we don't have to repeatedly explain that the mental model implied by the notation style is, in fact, not how the technology actually works. If the person can grasp what a bit vector is, they will understand. If they don't, they will not understand it anyway and I won't waste time trying to explain it in depth. At least as of right now, you are giving those people some middle ground which allows them to have a good working knowledge to use IPv6 reliably without needing this level of involvement. No sweat. When I shoot my mouth off, I expect to be challenged on the remarks. Part of the fun lies in discovering whether the thesis is defensible. For at least a few rounds, I am usually good for that, too. Personally, I think I answered the implicit question above, but it made me re-asses and re-think my personal professional opinion on quite a few things and that's a Good Thing, from time to time. By the by, as long as I'm criticizing IPv6 notation, let me express just how poor a choice of separator character the colon is. The colon separates the IPv4 address from a directory or port description only slightly less often than the slash. Writing the parsers to handle an IPv6 address as a drop in is a pain in the tail. Should have used a dash, underscore or plus. Those are far more rarely used in tokenization. A dash is the character people use when there is not a standard. Look at what they had to do for UUIDs to make them recognizable (which worked out really well, especially the version encoding. I really like their solution). Though they had the advantage that substring length _really_ doesn't matter other than as a way to correctly distinguish UUIDs from anything else.
Re: Introducing draft-denog-v6ops-addresspartnaming
On 19 November 2010 13:14, Scott Morris s...@emanon.com wrote: If 8 bits is a byte, then 16 bits should be a mouthful. I like that, but maybe a chomp (although that might annoy some perl ruby people)... then maybe when all 2bytes are zeros and we expel them from the address with a double colon, we should call that a fart. -- Daniel Holme
Re: Introducing draft-denog-v6ops-addresspartnaming
On 20 Nov 2010, at 13:42, Daniel Holme dan.ho...@gmail.com wrote: On 19 November 2010 13:14, Scott Morris s...@emanon.com wrote: If 8 bits is a byte, then 16 bits should be a mouthful. I like that, but maybe a chomp (although that might annoy some perl ruby people)... then maybe when all 2bytes are zeros and we expel them from the address with a double colon, we should call that a fart. On a more serious note, apologies for throwing in more suggestions this late in the game. Especially now some documentation has been drafted, but has anybody thought of using 'munch' for 2bytes. It just seems to ring right for me. -- Daniel Holme
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sat, Nov 20, 2010 at 5:05 AM, Richard Hartmann richih.mailingl...@gmail.com wrote: On Fri, Nov 19, 2010 at 23:52, William Herrin b...@herrin.us wrote: I thought about that. Have a one colon rule that IPv6 addresses in hexidecimal format have to include at least one colon somewhere. The regex which picks that token out versus the other possibilities is easy enough to write and so is the human rule: Oh, it's got hexidecimal digits and a colon in it. IPv6 address. this would still make it hard for humans to detect an IPv6 address at a glance, makes it impossible to quickly pick out any sections that are more relevant at the moment Which is why you wouldn't conventionally remove the colons even though the format would allow it. You might, however, move the colons to highlight the delineations relevant to a particular address rather than the meaningless two-byte separation. For example: 260:abcde:123456:98::1 260 - IANA to ARIN, a /12 abcde - ARIN to ISP, a /32 123456 - ISP to customer, a /56 98 - customer subnet ::1 - LAN address fd:1234567890:abcd::1 fd - ULA space 1234567890 - ULA global ID abcd - user subnet ::1 - LAN address Instead of this meaning-filled separation, we have: 260a:bcde:1234:5698::1 which doesn't tell us a single helpful thing about how that address is organized. The only thing the colons do there is make it easier to blindly transcribe, like the dashes in a CD license key. and would hog the colon for all eternity, blocking it for other uses. Also, this would make adding a port even more cumbersome. I've written more than a few parsers. I think your concern here is overstated. Anything you call out will be interpreted as special. The more you call it out, the greater the expectation that the distinction is important. That's human nature. Pattern recognition is a central part of our intelligence, so yes, it's human nature. This is not necessarily a bad thing. The way you talk about something trains people how that thing works. Train them poorly and it's your fault when their mistaken mental model results in errors. I mean, when you think about it, the consequence that :: means all middle two-byte components are zero is kinda weird. It's a commonly accepted, well-defined convention to save humans effort while not sacrificing readability. There are weirder things in technology. I have no beef with the the notion of abbreviations. I'm just saying this particular formulation is weird, a consequence of a poorly thought-out notation format. And even more efficiently when we don't have to repeatedly explain that the mental model implied by the notation style is, in fact, not how the technology actually works. If the person can grasp what a bit vector is, they will understand. If they don't, they will not understand it anyway and I won't waste time trying to explain it in depth. At least as of right now, you are giving those people some middle ground which allows them to have a good working knowledge to use IPv6 reliably without needing this level of involvement. It helps if the notation style reminds them that they're dealing with a bit vector. IPv6 is better about this than IPv4; at least the colons aren't separating portions of the bit pattern expressed in base-10. But it could be better. Fixed separations get folks thinking there's a higher significance. Movable separations offers a constant reminder that it is just a bit vector. No sweat. When I shoot my mouth off, I expect to be challenged on the remarks. Part of the fun lies in discovering whether the thesis is defensible. For at least a few rounds, I am usually good for that, too. Personally, I think I answered the implicit question above, but it made me re-asses and re-think my personal professional opinion on quite a few things and that's a Good Thing, from time to time. A value I also find when I'm on the receiving end. :) PS: Yes, I am fully aware that my complete email is moot anyway as the IPv6 syntax will not change, ever. I wrote it for fun :) Yep. However, there is one thing that could be done at this juncture: intentionally don't name the two-byte groupings. And then make that a part of the lesson plan: by the way folks, these groupings of four characters in the IPv6 address intentionally have no name. That's because the IPv6 address is a bit vector. The colons are only there to make it easier to read and type; the groupings have no significance. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Introducing draft-denog-v6ops-addresspartnaming
I saw 'field' somewhere http://tools.ietf.org/html/rfc5952#section-2.1 seems to agree. Frank On 11/19/2010 10:42 AM, Owen DeLong wrote: 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 On Nov 18, 2010, at 6:07 PM, Richard Hartmann wrote: 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
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 07:00, bmann...@vacation.karoshi.com wrote: 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. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 08:42, Owen DeLong o...@delong.com wrote: 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] http://en.wikipedia.org/wiki/Condorcet_method
RE: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 07:00, bmann...@vacation.karoshi.com wrote: 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. 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?
Re: Introducing draft-denog-v6ops-addresspartnaming
If 8 bits is a byte, then 16 bits should be a mouthful. ;) Scott On 11/18/10 10:45 PM, George Bonser wrote: 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
Re: Introducing draft-denog-v6ops-addresspartnaming
On 11/19/2010 4:57 AM, George Bonser wrote: It's always two bytes, but people may choose to omit them. That is a social, not a (purely) technical, syntax, though. 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? 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.)
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 10:57, George Bonser gbon...@seven.com wrote: 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? I don't call it anything. The fourth $decided_upon is zero/empty suffices :) 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
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 14:14, Scott Morris s...@emanon.com wrote: If 8 bits is a byte, then 16 bits should be a mouthful. When does it become a meal and, more importantly, do you want to supper (sic) size? RIchard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, 2010-11-19 at 17:06 +0100, Richard Hartmann wrote: On Fri, Nov 19, 2010 at 14:14, Scott Morris s...@emanon.com wrote: If 8 bits is a byte, then 16 bits should be a mouthful. When does it become a meal and, more importantly, do you want to supper (sic) size? 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
Re: Introducing draft-denog-v6ops-addresspartnaming
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
Re: Introducing draft-denog-v6ops-addresspartnaming
On Nov 19, 2010, at 12:57 AM, Richard Hartmann wrote: On Fri, Nov 19, 2010 at 07:00, bmann...@vacation.karoshi.com wrote: 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. 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
Re: Introducing draft-denog-v6ops-addresspartnaming
Greetings, On Fri, 19 Nov 2010, Owen DeLong wrote: 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. I like to call it a HexNot - a hexidecimal representation of zeros. :: --- Jay Nugent () ascii ribbon campaign in /\ support of plain text e-mail Train how you will Operate, and you will Operate how you were Trained. ++ | Jay Nugent j...@nuge.com(734)484-5105(734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com]| | Internet Consulting/Linux SysAdmin/Engineering Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP Modem Performance Monitoring | | Web-Pegasus[www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| ++ 12:01pm up 72 days, 21:25, 3 users, load average: 0.15, 0.07, 0.05
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 17:58, Owen DeLong o...@delong.com wrote: 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 :) Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
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: On Nov 19, 2010, at 11:06 AM, Richard Hartmann wrote: On Fri, Nov 19, 2010 at 14:14, Scott Morris s...@emanon.com wrote: If 8 bits is a byte, then 16 bits should be a mouthful. When does it become a meal and, more importantly, do you want to supper (sic) size? RIchard James R. Cutler james.cut...@consultant.com
Re: Introducing draft-denog-v6ops-addresspartnaming
On Nov 19, 2010, at 8:58 AM, Owen DeLong wrote: On Nov 19, 2010, at 12:57 AM, Richard Hartmann wrote: On Fri, Nov 19, 2010 at 07:00, bmann...@vacation.karoshi.com wrote: 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... 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
Re: Introducing draft-denog-v6ops-addresspartnaming
On 11/19/10 10:56 AM, Owen DeLong wrote: 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... Assuming you have a v6 stack on your cdc6600 a v6 address fits in 22 bytes not 16. 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. One can define that byte size for the purposes of the human reading of addresses ipv6 as 8 bits, without getting into machine specific details. what's important to the machine isn't the division of the address into parts (they aren't divided in the machine representation it's just one long row of bits) but rather where the mask falls. Owen
Re: Introducing draft-denog-v6ops-addresspartnaming
On Thu, Nov 18, 2010 at 9:07 PM, Richard Hartmann richih.mailingl...@gmail.com wrote: 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. Hi Richard, I have an anti-naming proposal: Allow users to place the colons -anywhere- or even leave them out altogether without changing the semantics of the IPv6 address. The colons are there for readability purposes only. They have no special significance and should not be elevated to significance by naming the parts of the address they delineate. Treat them specially and some fools will attach importance to arranging tasks on two-byte boundaries. The meaningful boundaries in the protocol itself are nibble and /64. If you want socially significant boundaries, add /12, /32 and /48. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Introducing draft-denog-v6ops-addresspartnaming
On 11/19/10 12:45 PM, William Herrin wrote: On Thu, Nov 18, 2010 at 9:07 PM, Richard Hartmann richih.mailingl...@gmail.com wrote: 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. Hi Richard, I have an anti-naming proposal: Allow users to place the colons -anywhere- or even leave them out altogether without changing the semantics of the IPv6 address. The colons are there for readability purposes only. They have no special significance and should not be elevated to significance by naming the parts of the address they delineate. Treat them specially and some fools will attach importance to arranging tasks on two-byte boundaries. The meaningful boundaries in the protocol itself are nibble and /64. If you want socially significant boundaries, add /12, /32 and /48. It is possible and desirable to be able to describe any mask length between /0 and /128. the /64 is an important demarcation point for subnets but everything shorter than that will appear in your routing table. Regards, Bill Herrin
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 4:09 PM, Joel Jaeggli joe...@bogus.com wrote: On 11/19/10 12:45 PM, William Herrin wrote: The meaningful boundaries in the protocol itself are nibble and /64. If you want socially significant boundaries, add /12, /32 and /48. It is possible and desirable to be able to describe any mask length between /0 and /128. the /64 is an important demarcation point for subnets but everything shorter than that will appear in your routing table. Hi Joel, Bit, nibble and /64 then. /64 is treated specially by functions in the protocol (like SLAAC) thus it's a protocol boundary rather than a social one (/12 IANA allocations, /32 ISP allocations, /48 end-user assignments). Unless you particularly feel the need to assign /64's to router loopbacks, you'll see plenty of routes longer than /64 in your table too. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 21:45, William Herrin b...@herrin.us wrote: I have an anti-naming proposal: Allow users to place the colons -anywhere- or even leave them out altogether without changing the semantics of the IPv6 address. A decade or two of established syntax disagree. IPv6 addresses, UUIDs and similar have a unique syntax for a reason. Otherwise, we, nor computers, wouldn't be able to quickly distinguish an IP from a hash. The colons are there for readability purposes only. They have no special significance and should not be elevated to significance by naming the parts of the address they delineate. Treat them specially and some fools will attach importance to arranging tasks on two-byte boundaries. Even if they were for readability only, they would still be for humans. Same as the specific, canonical name we are trying to agree on. If people want to interpret more into the colons than there is to see, they will do so regardless of a name. The rest of us will work faster, more efficiently and not explain the same old thing a gazillion times. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 22:17, William Herrin b...@herrin.us wrote: Bit, nibble and /64 then. /64 is treated specially by functions in the protocol (like SLAAC) thus it's a protocol boundary rather than a social one (/12 IANA allocations, /32 ISP allocations, /48 end-user assignments). I would argue that /0 and /128 are somewhat special, too. Unless you particularly feel the need to assign /64's to router loopbacks, you'll see plenty of routes longer than /64 in your table too. That's a personal preference, really. Unless you mess up, or are an end user permanently stuck with a /64 (in which case your ISP messed up), there isn't really much need to assign anything longer, though. That being said, for whatever reason, several of my upstreams use /126 for their sessions. In any case, other than some people might see the colons as magic markers I don't really see an argument in favour of avoiding a common name. And that does not seem to hold much water. This is not meant to be an attack, I simply wonder if I am missing something. Richard
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
Re: Introducing draft-denog-v6ops-addresspartnaming
On Thu, Nov 18, 2010 at 07:45:19PM -0800, George Bonser wrote: 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
Re: Introducing draft-denog-v6ops-addresspartnaming
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 On Nov 18, 2010, at 6:07 PM, Richard Hartmann wrote: 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
