Thomas Narten [mailto:[EMAIL PROTECTED] wrote:
> Does common sense play any role here? (I know, a lot to ask...)
No, not in your sense. The "common sense" that plays a role is one which
asks, "What is the cheapest fix, short term?"
How hard would it be, for example, to include words similar or i
Thomas Narten wrote:
This is in a lab, before deployment, before many other vendors start
writing their own code to make use of this message.
Let's be real. Anyone doing an implementation from scratch from the
specs would (with high probality) do its first test against a
well-known, readily av
Jeeze, I find it hard to believe some people seem to think this is a
serious issue!!!
> Bazillion IPv6 implementations?
Certainly in the 20-100 range, depending on how you count the
genetics. Point is, many implementors have implemented IPv6, and as
far as anyone here can tell, nobody had a quest
[EMAIL PROTECTED] wrote:
> [write a draft]
How about revving 2460?
Eliot
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Good morning all,
John makes an excellent point. I'd be happy to assist anyone writing the draft.
Best Regards,
Tim
Rom 8:28
>From: [EMAIL PROTECTED]
>Date: 2006/09/16 Sat PM 11:31:41 CDT
>To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Cc: ipv6@ietf.org
>Subject: RE: Endianness
Gentlemen,
>> It would seem a fairly simple yet worthwhile thing to standardize the
>> endianness of IPv6 (both headers and payload for that matter).
>> Is it the majority view that we should do this?
>
>I'm in favor. It's certainly a better use of the IETF's
>collective time than all the proces
On 16-sep-2006, at 21:53, Tim Enos wrote:
No, the real question is, "how do we want the spend the time and
energy in the IETF?", in other words, is this obvious enough that
making explicit guidance isn't worth our time (as there is probably a
lot of other things that the IETF and its participant
c: Thomas Narten <[EMAIL PROTECTED]>, Iljitsch van Beijnum <[EMAIL
>PROTECTED]>,
IETF IPv6 Mailing List
>Subject: Re: Endianness of IPv6 and payloads
>On Sat, 16 Sep 2006, Eric Klein wrote:
>> On September 16, 2006 00:26 Iljitsch van Beijnum wrote:
>>> On the
On Sat, 16 Sep 2006, Eric Klein wrote:
On September 16, 2006 00:26 Iljitsch van Beijnum wrote:
On the other hand, is it good for a standards organization to leave
important technical details unspecified and assume tradition and
interoperability testing will take care of the difference?
I thin
On September 16, 2006 00:26 Iljitsch van Beijnum wrote:
On the other hand, is it good for a standards organization to leave
important technical details unspecified and assume tradition and
interoperability testing will take care of the difference?
I think not, real question is do we want impli
Thomas Narten [mailto:[EMAIL PROTECTED] wrote:
> Let's see. If an implementor got this wrong, and actually tested their
> implementations with one of the bazillion IPv6 implemenations or test
> suites (some productized and some nearly 10 years old -- and all of
> them seeming to do the same thing
On 15-sep-2006, at 23:11, Thomas Narten wrote:
Let's see. If an implementor got this wrong, and actually tested their
implementations with one of the bazillion IPv6 implemenations or test
suites (some productized and some nearly 10 years old -- and all of
them seeming to do the same thing w.r.t.
Bob Hinden <[EMAIL PROTECTED]> writes:
> I have hard time understanding why documenting this further this
> would be a good use of anyone's time (i.e., individuals, IPv6 w.g.,
> ADs, IETF, RFC-Editor, ).
Let's see. If an implementor got this wrong, and actually tested their
implementation
Markku Savela [mailto:[EMAIL PROTECTED] wrote:
> Is thread trying to say the IPv6 *headers* specified in the IPv6 RFC's
> leave the byte order of the header fields unspecified? I never noticed
> this omission as an implementor.
>
> For payloads, the issue is moot, because IPv6 and IPv4 payloads a
ny of
them.Payload is not a specific conception.
But it is better to specify every thing in the RFC.
From: Markku Savela <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: ipv6@ietf.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Endianness of IPv6 and payloads
Date: Fri, 15 Sep 2006 00:31:33 +0300
Is thread trying to say the IPv6 *headers* specified in the IPv6 RFC's
leave the byte order of the header fields unspecified? I never noticed
this omission as an implementor.
For payloads, the issue is moot, because IPv6 and IPv4 payloads and
upper layer headers are same (or should always be, eve
>From: Iljitsch van Beijnum <[EMAIL PROTECTED]>
>Date: 2006/09/14 Thu PM 02:26:39 CDT
>To: [EMAIL PROTECTED]
>Cc: IETF IPv6 Mailing List
>Subject: Re: Endianness of IPv6 and payloads
>On 13-sep-2006, at 20:15, Bob Hinden wrote:
>
>> In my personal view, while t
On 13-sep-2006, at 20:15, Bob Hinden wrote:
In my personal view, while this is a nice theoretical problem, no
evidence has been presented that anyone building an implementation
is confused about it. For example, were there ever any
interoperability problems because someone did this wrong?
Bob Hinden wrote:
>
> Folks,
>
> In my personal view, while this is a nice theoretical problem, no
> evidence has been presented that anyone building an
> implementation is
> confused about it. For example, were there ever any
> interoperability
> problems because someone did this wrong?
Folks,
In my personal view, while this is a nice theoretical problem, no
evidence has been presented that anyone building an implementation is
confused about it. For example, were there ever any interoperability
problems because someone did this wrong? Common sense would indicate
that I
Elwyn,
> I would be willing to take on updating this doc if Chris doesn't want
to
> follow through.
FWIW, I would support your taking the lead on this effort.
Fred
[EMAIL PROTECTED]
IETF IPv6 working group mailing list
ipv6@i
Templin, Fred L wrote:
Elwyn,
Maybe somebody ought to write a very short I-D just to set the record
straight.
It looks like there was at least one attempt to do that; see:
http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-newman-netw
ork-byte-order-01.txt
I think Chr
Templin, Fred L wrote:
[..]
Do we need a more detailed and unified "IETF Reference
Architecture" document, or are existing documents like
RFC1958 enough?
This more looks like a call for an "IETF Encyclopedia" or a FAQ... which
thus nowadays would mean a Wiki ;) Especially with many terms consi
Elwyn,
> Maybe somebody ought to write a very short I-D just to set the record
> straight.
It looks like there was at least one attempt to do that; see:
http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-newman-netw
ork-byte-order-01.txt
I don't know the status of this effort, and I
Brian E Carpenter wrote:
> There are multiple references to network byte order in RFC 3542,
> and it's very specific for raw sockets. That seems clear enough.
>
> RFC 1958 says:
>
> 3.13 All specifications should use the same terminology
> and notation,
> and the same bit- and byte-orde
There are multiple references to network byte order in RFC 3542,
and it's very specific for raw sockets. That seems clear enough.
RFC 1958 says:
3.13 All specifications should use the same terminology and notation,
and the same bit- and byte-order convention.
(sadly, without saying what i
After a little detective work:
The concept of a 'standard' (Internet) network byte order appears to
have crept into the RFC series without actually officially linking
Appendix B of RFC 791 (dated Sptember 1981) to the term.
AFAICS the earliest use of the term 'standard network byte order' is
Manfredi, Albert E wrote:
[..]
I guess we'll just have to go with "Internet convention" arguments.
Well we can also go the Wikipedia route:
8<---
Networks generally use big-endian numbers as addresses; this is
historically because this allowed the routing to be decided as a
teleph
Jeroen Massar wrote:
> Nope. As far as I know of, in the case of all IETF protocols,
> "Network
> Byte Order" is always used, and this means Big Endian. Thus
> when Little
> Endian is supposed to be used, it will always have to be specified,
> otherwise it is per default Big Endian.
Thanks
Manfredi, Albert E wrote:
[..]
Have I missed something, or was this info deleted because it's too
inflammatory?
Nope. As far as I know of, in the case of all IETF protocols, "Network
Byte Order" is always used, and this means Big Endian. Thus when Little
Endian is supposed to be used, it will
30 matches
Mail list logo
