On Nov 17, 2011, at 12:06 PM, Russ White wrote: > >>> Maybe this discussion could be viewed as a good motivation for >>> revisiting the requirements draft. >> >> don't require what you have no solid idea of how to achieve. > > Maybe if someone actually laid out real requirements, someone, > someplace, could determine how to achieve most (if not all) of them. The > process SIDR has used is backwards --choose a solution, then build the > requirements around that solution. When problems arise, just change the > requirements so it's no longer a problem.
Totally agree w/ u here, Russ... Randy, we are all arguing over what we think a secure routing system should do... It sounds like you (and your team?) have already decided what you think everyone's requirements are, but it's pretty plain to all that a fair number of people here in the wg do not agree. One of the main reasons software systems begin with requirements analysis is precisely so that we can know if our solution meets our needs. As I said before, if we wind up needing to rework our collective requirements, then so be it, but this process needs to be followed, not skipped. Even your above comment has taken this out of order (skipping a requirement because you think you can't do it implies a design attempt); requirements come first... ;) Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
