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