On Sep 30, 2004, at 2:53 PM, ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
I don't know enough
about CRISP to comment, but if GEOPRIV is an example of a success due
to
having used a requirements document, well, all I can say is it is at
best a
very anomalous case. IMO the whole GEOPRIV effort was mismanaged
dating back to
its origins in the SPATIAL effort. (I also think almost all of the
blame for
this rests with the IESG and not the group itself, and since I was an
IESG
member at the time I include myself as a responsible party. But that's
an
entirely separate discussion not relevant to the matters at hand.)
I'm not sure what the point is here... that the IESG is at fault? That
certainly doesn't speak against the point I made: GEOPRIV spent a long
time in fundamental disagreement and finally quit wondering around
after they put their requirements in writing.
On Oct 1, 2004, at 3:29 PM, ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
IMO what's missing from the charter is something that's really hard to
add: The
major failing we have seen over and over and over again in this space
is that
we've let the practically undeployable "best" be the mortal enemy of
the very
deployable "just barely good enough".
Deployability is what matters. Period. A solution which offers only a
small
increase in security (e.g., it can with some trouble be sppofed, or
replays
are hard but possible, or whatever) but which is deployable is going
to be a
million times more valuable than any of the schems we've devised in
the past,
even though those schems offer much much better security.
I would agree with this. And I think this was the issue we had at the
last BoF. This point was not clearly articulated. Instead we spent
too much time arguing about phishing prevention being a social or
technical issue.
The trick is going to be coming up with something that is both
deployable and
which we can get approved. I'm honestly not optimistic that there's an
intersection between the two, even at this late date and after so many
failures.
Just my opinion, but I think the goal is attainable.
On Sep 30, 2004, at 8:57 PM, John Levine wrote:
It certainly seems logical that one would start by defining
requirements and then refine them into a spec and eventually into
working code. This is basically the waterfall model of software
design that was popular in the 1960s. It's fallen our of favor,
because it's proven many times to be a one-way ticket to disaster.
The short reason is because if we knew what we were going to build, we
would have built it already.
Requirements definition is found in more than just the waterfall
software development methodology. Are you seriously trying to suggest
that requirements for software development is just a 35-year-old, faded
and debunked fad?
On Oct 1, 2004, at 9:56 PM, John Levine wrote:
This is exactly the kind of war by proxy that I was referring to.
You are the one that said this was an obvious but debatable
requirement. I'm not sure how it can be both, but the fact that it is
being debated means that it is not obvious to everyone. I suspect this
isn't the only requirement that isn't obvious.
If you don't want a "war by proxy", then be prepared to repeat these
conversations over and over again as this group goes through each
proposal. Or do you suggest we simply give up/down votes for each
proposal without discussion? Because that is the only way this group
will avoid these conversations.
I look forward to multiple and repeated discussions about the various
merits of key management systems, either putting keys directly into DNS
or just using DNS as a pointer, re-using S/MIME or PGP vs a new mail
encryption scheme, the identity from which the key is to be derived,
preservation of forwarding semantics, etc..
I'd like an automobile that costs nothing, protects the occupants from
injury in any possible type of accident, gets a thousand miles to the
gallon, and has no effect on the environment, but making those my
requirements isn't going to help me buy a car.
So we should trust the car salesman instead of doing our homework? You
have obviously had much different car purchasing experiences than I.
-andy