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 question about endianness before, or if they did, they figured out the answer plenty quick without coming to the IETF for clarification. Conclusion: this is not a real problem in practice. > What if a vendor writes the application and tests it with one other > vendor's software. The application does not work. And the decision now > has to be made as to which vendor needs to fix the problem? Any competent implementor would then ask "what is the history of this other software I'm testing against? Is it well-known? Are people using it? Have they tested it?" Etc. The idea that two implementations (implemented from scratch) and not tested with an existing well-known one first, would test against each other and then point fingers at each other when the spec clearly does not say which interpretation is right seems just silly! > 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 available implementation. E.g., linux, *BSD, or any of the available products. (Well, if they thought about what they were doing for any length of time, anyway) > In IPv6, how does one convince the decision maker to do the right > thing? Does common sense play any role here? (I know, a lot to ask...) > This happens in real life. It's not just an improbable scenario. And > keep in mind that the first vendor is being very defensive by now. OK, if there is a real vendor that did the endinness wrong, go ask them to test against the Microsoft stack (or Sun, or IBM, ...) And if they then think those vendors all got it wrong, have them come back to the IETF and show where in the relevant RFCs there is wording to support their interpretation. There is a big difference between "not clearly specified, and hence my interpretation could be wrong" and "the spec says Y, therefore the other vendors interpretation to do Z instead is wrong" And note, I'm not saying this oversight is a good thing or "right". Its clearly an oversight. Next time we revise the relevant spec, clarifying wording should go in. But is this such a problem that a separate RFC should be written just to clarify this point? Please! I thought the IETF had real work to do with its limited cycles. Next challenge (for those with time on their hands). How many other IETF specs neglected to explicitely state the endianness of protocols? (My prediction, a rather lot of them.) Followup: has it caused great problems in practice? I'd bet not. It may have caused problems in some cases, but I suspect not in a lot relatively speaking. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
