[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: netsec-reqs document: what is, where it is, what to call it.



 "g" == gmj  <gmj@pobox.com> writes:

g> Why it's being published?
g>  - To enable the larger community of consumers/operators of
g>    IP enabled equipment to communicate security needs
g>    clearly and effectively (read: via references in RFPs)
g>    to the vendor community....i.e. the end game is better,
g>    more secure products.

One reason is (possibly justifiable) UUNET hubris.  We would present
our requirements to a vendor, and they'd say "None of our other
customers are asking for these things."

By publishing it beyond UUNET, we hoped to spark ideas in other
customers, to get them to say "Wow, that's a great idea, we want you
to implement that too."  Basically, "You want it, you just don't know
you want it yet."  There was also the hope that once the document got
out, other customers would chime in with their own ideas, which we at
UUNET had not thought of.

This document comes from very base origins.

g> Why this matters?

g>      We have comments to integrate now.  We need to know
g>      what sort of document is being produced to 
g>      integrate them properly.

Personally, I think that the original mission of the document is as
yet uncompleted.  It might be appropriate to split the document, it
might not.  Whichever way you go, at least one document should come
out of this where end users swap ideas for security enhancements, and
then present them to the vendors with the power of collective
bargaining.

This is a moving target.  Bad things on the Internet evolve rapidly,
old requests get implemented or supplanted.  You will never get
multiple customers with different focuses (or even customers with
similar focuses) to agree on a set of features, and certainly not a
priority list for implementation of those features.  It may be that
this should not really be a document, but that the existing document
should be a foundation for a forum.  There, enhancements can be
suggested, discussed, refined, and prioritized.  Different customers
can sign up for different enhancements, and then vendors can check in
and make informed decisions on what to implement next.

SourceForge, anyone?  Push for Cisco to open source IOS?  It worked
for Mozilla, right?

ericb