On 03/07/2013 08:02 AM, Ole Troan wrote: >>> That aside, this document aims to update RFC 2460. Where else should >>> that be done, if not in 6man?? >> >> That's a technicality. What's more important is that the relevant expertise >> is in 6man. > > 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*. You cannot have a general document update RFC 2460. And different fields have different constraints. I wouldn't objet to such a general document *in addition* to this one: for the most part, they are orthogonal. > I don't want us to end up with an RFC per field per protocol. You seem to have done everything at hand for this document not to progress. But I would appreciate if it was the working group deciding on such progress. Besides, there's no "one RFC per field". Because IIRC, this is the only such I-D we have in IPv6. As a data point, the transport area produced RFC 6056 -- and they/we didn't refrain from publishing an RFC by means of an errata (and please take a look at such I-D, and see how the contrainst are different). 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). Man, protocols has flaws, in the same way that code has bugs. When you find them, you fix them (rather than pretending there's nothing to fix, opposing to fix them, or fixing them while pretending you aren't). > there isn't an equivalent document for IPv4, right? There is not -- In the same way that IPv6 deprecated RHT0, but IPv4 didn't deprecate source routing. What's the point that you're trying to make? That we should repeat IPv4 history? Do you really want implementations to keep the flawed scheme, implementations to come up with their own flawed algorithms, etc.? Haven't we learned anything from IPv4's history? > there are other alternatives too, e.g. an errata to 2460, or an update to the > nodes requirement document. That would be incorrect. You cannot have a "node requirements" for something that is against an existing std. And if this is an errata, what's a protocol update? 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. 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 --------------------------------------------------------------------
