On 03/27/2015 04:31 AM, Juliusz Chroboczek wrote:
More precisely, here's the approach I've taken in RFC 6126 (credit to Joel Halpern for helping me with that):* if something is required to ensure the integrity of the network, it's a MUST. In particular, bidirectional reachability detection, loop avoidance and blackhole avoidance are MUSTs (although one could conceive a protocol that interoperates with Babel without implementing any of those). * if something is needed for good performance, it's a mere SHOULD, so that it is possible to build an RFC 1217 compliant version of Babel. * if an algorithm is necessary, but could be implemented in different ways, then the properties that the algorithm have are MUST in the body of the document, and a suitable algorithm is described in an informative appendix.
I'm not sure if bringing in rfc 2119 is really helpful because sausage factory dev managers take the requirements language as "must=will, should=maybe, may=definitely not" for their schedules. My bet is what would be even more effective is to have bits of code readily available (either in-spec, or in-github) so that little-to-no thinking is required. It's unfortunate, but whether the code works is not what drives the incentives for lots of crappy low end routers from what I've seen.
Mike _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
