OPEN ISSUE: Standards Track
john.loughney at nokia.com
john.loughney at nokia.com
Fri May 23 10:40:31 CEST 2003
Charlie,
First off, a disclaimer. I am not talking about Mobile IP.
> I'm afraid this may be getting away from the original point,
> which is that there needs to be a way to boil a truckload
> of water before we boil the ocean.
No, I agree with your point about tackling the problem in
measured steps.
> The idea of requiring a threat analysis and deployment
> scenarios analysis is a pretty good way to raise the bar
> way up into the stratosphere so that no work gets done.
> Presumably you meant that this would come _after_
> the problem statement and definition, followed by the
> requirements analysis, all of which should (???) occur
> before anyone is allowed to mention a solution.
Not at all. Deployment analysis was not even something
I suggested. What I actually meant is that when working
on a clean sheet of paper, it doesn't hurt to think about
what are the possible threat models which can aid in
working on a solution - rather than trying to retrofit
solutions during IESG review.
If you are not working with a clean-sheet of paper, then
taking some time to look at what exists, in terms of
security, is not a bad thing.
I think most of this can be done in parallel, or nearly
parallel. I hope that problem statements, problem definition,
requirements, ad-nauseum don't become the standard
WG deliverables for all WGs. Actually, I think the
the problem statement & definition should be a feature
of the charter, not a seperate document.
> I think iterative and parallel development is best,
> and testing interoperability all along the way.
I agree - and I was just suggesting that putting some
thoughts about security upfront could actually make
things work smoother & perhaps even speed things up
(to save from last minute security gotchas).
John
More information about the Problem-statement
mailing list