On 03/07/2013 06:16 PM, Ole Troan wrote: > > may I suggest you keep ranting to a minimum.
Have you counted how many emails I have sent you off-list regarding this and other I-Ds? Have you noted how many times I had to ask you simply to poll the wg about adoption of this document? >>> when this document was presented in 6man at IETF84, there were suggestions >>> that a more generic >>> document could be written. e.g. in intarea. >> >> We have beaten this one to death -- but you still bring this one up: >> Most folks agreed that a general document (in *addition* to this one) >> would be useful, but this one would be valuable and *needed*. > > <chair> > that is not evident from this thread, nor the minutes from IETF84. > </chair> Both in this thread on in the minutes, it was basically just the chairs arguing in favor of an errata. Other folks (such as Lorenzo Colitti) argued that both a general document *and* this one looked like a good way forward. And then there were folks such as Joel Jaeggli, who noted that I might want to go Informational -- probably because for some folks standards are written into stone. So yes, I disagree with you. If you want, I may try to do a transcript of the relevant meeting (the audio is available, anyway). And the current thread does not seem to support your "let's do nothing about this" proposal, either. > [...] > >> In a more broader sense, I wonder what's the point of having a >> "maintenance" working group when it looks like you seem to do anything >> to avoid formally updating existing standards (this is not the first >> instance of that). > > yes, and I think it is also our responsibility to limit too much tinkering. > in this case fixing what appears to be a marginal problem, in descriptive > text of RFC2460. Look: Two BGP routers talking to each other. Both using predictable I-Ds. Attacker fires an ICMPv6 PTB to one of them (or both). The starts sending fragments to their other endpoints. GTSM is of no help here. Does that look marginal to you? And the descriptive text has resulted in many vulnerable implementations -- we do care about running code, right? Do I really need to publish an automated tool that implements this, and then include a URL to your note of this "being a marginal problem"? > [...] > >> Besides, you'll realize that the document is a bit larger than >> one-paragraph long. And there's much more valuable information that >> would could put in an errata, or a node requirements update. > > "It is recommended to use unpredictable values in protocol fields"? > > the above is good advice, I do not think it necessary to publish a document > to update non-normative text in 2460. It is necessary when so many implementations got it wrong. And if you have followed IPv4's history in this respect, you'll realize that advice *is* needed -- not only in terms of normative language, but also in terms of proposed algorithms -- unless you want implementations to work twice on this issue, as many implementations did for IPv4, since they got it wrong the first time. Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
