On Mon, Nov 29, 2010 at 21:34, Doug Barton 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 t
-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 critici
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 rat
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 ed
>>> 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 notati
On Nov 22, 2010, at 5:05 PM, TJ wrote:
> On Fri, Nov 19, 2010 at 08:14, Scott Morris 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
> 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
Documenting my support publically, as requested.
--- Jay
-- Forwarded message --
Date: Mon, 22 Nov 2010 23:26:31 +0100
From: Richard Hartmann
To: Jay Nugent
Subject: Re: Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 22, 2010 at 19:46, Jay Nugent wrote
On Fri, Nov 19, 2010 at 08:14, Scott Morris 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
> 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
> To: Owen DeLong
> Subject: Re: Introducing draft-denog-v6ops-addresspartnaming
> Cc: bmann...@vacation.karoshi.com, nanog@nano
> 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
> Date: Fri, 19 Nov 2010 08:58:45 -0800
> To: Richard Hartmann
> Cc: bmann...@vacation.karoshi.com, nan
On Mon, Nov 22, 2010 at 14:05, Richard Hartmann
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
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 betwee
On Mon, Nov 22, 2010 at 18:33, Daniel Hagerty 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.
Agr
On Mon, Nov 22, 2010 at 16:23, Owen DeLong 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 ou
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 wrote:
>
>> If 8 bits is a byte, then 16 bits should be a mou
Richard Hartmann 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
On Mon, Nov 22, 2010 at 15:07, William Herrin 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 me
>
>> 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,
On Mon, Nov 22, 2010 at 6:40 AM, Richard Hartmann
wrote:
> On Sun, Nov 21, 2010 at 16:54, William Herrin 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 agains
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 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 y
[ 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...
lo
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 wrote:
> On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli wrote:
> Looks like an ass-u
On Sun, Nov 21, 2010 at 23:15, Owen DeLong 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, peop
On Sun, Nov 21, 2010 at 16:54, William Herrin 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
On Sat, Nov 20, 2010 at 23:15, Owen DeLong 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
>
> On Sun, Nov 21, 2010 at 5:15 PM, Owen DeLong 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'
On 11/21/10 2:50 PM, William Herrin wrote:
> On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli 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 reas
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
>
> 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
On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli 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-m
On Nov 21, 2010, at 7:54 AM, William Herrin wrote:
> On Sat, Nov 20, 2010 at 5:15 PM, Owen DeLong 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
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, Ta
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
On Sat, Nov 20, 2010 at 5:15 PM, Owen DeLong 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 sem
On 11/20/10 2:20 PM, Owen DeLong wrote:
>
> On Nov 20, 2010, at 9:12 AM, William Herrin wrote:
>
>> On Sat, Nov 20, 2010 at 5:05 AM, Richard Hartmann
>> wrote:
>>> On Fri, Nov 19, 2010 at 23:52, William Herrin wrote:
>>>
I thought about that. Have a "one colon rule" that IPv6 addresses in
On Nov 20, 2010, at 9:12 AM, William Herrin wrote:
> On Sat, Nov 20, 2010 at 5:05 AM, Richard Hartmann
> wrote:
>> On Fri, Nov 19, 2010 at 23:52, William Herrin wrote:
>>
>>> I thought about that. Have a "one colon rule" that IPv6 addresses in
>>> hexidecimal format have to include at least on
>
>> 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
On Sat, Nov 20, 2010 at 5:05 AM, Richard Hartmann
wrote:
> On Fri, Nov 19, 2010 at 23:52, William Herrin 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 ver
On 20 Nov 2010, at 13:42, Daniel Holme wrote:
> On 19 November 2010 13:14, Scott Morris 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
On 19 November 2010 13:14, Scott Morris 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 cal
On Fri, Nov 19, 2010 at 23:52, William Herrin 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
On Fri, Nov 19, 2010 at 4:20 PM, Richard Hartmann
wrote:
> On Fri, Nov 19, 2010 at 21:45, William Herrin 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
On Fri, Nov 19, 2010 at 22:17, William Herrin 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 th
On Fri, Nov 19, 2010 at 21:45, William Herrin 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 si
On Fri, Nov 19, 2010 at 4:09 PM, Joel Jaeggli 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 a
On 11/19/10 12:45 PM, William Herrin wrote:
> On Thu, Nov 18, 2010 at 9:07 PM, Richard Hartmann
> 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
On Thu, Nov 18, 2010 at 9:07 PM, Richard Hartmann
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
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 bit
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, 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
>>
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. C
On Fri, Nov 19, 2010 at 17:58, Owen DeLong 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 st
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 p
On Nov 19, 2010, at 12:57 AM, Richard Hartmann wrote:
> On Fri, Nov 19, 2010 at 07:00, 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 alwa
>> 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
On Fri, 2010-11-19 at 17:06 +0100, Richard Hartmann wrote:
> On Fri, Nov 19, 2010 at 14:14, Scott Morris 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
On Fri, Nov 19, 2010 at 14:14, Scott Morris 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
On Fri, Nov 19, 2010 at 10:57, George Bonser 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 o
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 ca
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
> On Fri, Nov 19, 2010 at 07:00, 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
On Fri, Nov 19, 2010 at 09:09, Frank Habicht wrote:
> I saw 'field' somewhere
>
> http://tools.ietf.org/html/rfc5952#section-2.1
> seems to agree.
I seem to remember "field" being used with the understanding that it's
a placeholder and not a definite term. As I can't find an actual
source fo
On Fri, Nov 19, 2010 at 08:42, Owen DeLong 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
decid
On Fri, Nov 19, 2010 at 07:00, 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
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 thi
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 ma
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, spec
> 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
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 c
69 matches
Mail list logo
