On 04/23/2013 07:45 PM, Christian Huitema wrote: >> If I'm the guy producing a spec, my goal is to produce a spec that >> is clear as possible, and only leave open those bits that are >> necessary to leave open. > > Well, that might work for internal specs when you are managing a > project, but that's probably not the right way to approach standards.
That probably depends on *what* you're specifying (please see below). > A standard, being the rules of the network, shall only constrain what > must be constrained for interoperability. This document is not about a rule of the network, but about a local policy. Therefore, by definition, as long as the address you select is unique, nothing in this document will affect interoperability. > All implementations are tradeoffs. Developers will necessarily make > them, based on the different resource, priorities, usage scenarios. > It is much better to explain to give clear guidelines than to merely > mandate an implementation. We probably have different views here. We're not mandating an implementation (e.g., we're not mandating any specific PRF for F(), nor how you store addresses in memory if you do store them). I see the algorithm in this document as giving more room for tradeoffs to developers than RFC4941, and the same room for tradeoffs as e.g. RFC6528. Based on the above, me, I don't find the idea of re-writing the I-D compelling -- particularly at this point in time. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
