[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-jones-opsec-framework-01 comments
On Tue, 9 Nov 2004 15:34:01 +0200 (EET), Pekka Savola <firstname.lastname@example.org>
> Capabilities are currently defined to NOT refer to specific
> technologies. However, this brings up a problem mentioned when we
> tried to figure out what to do with the original opsec document: this
> does not guarantee or give any guidance to providing interoperable
Right. RADIUS vs. TACACS comes to mind.
> For example, as an operator, I'm not satisfied with requiring
> capability to do ingress filtering; I want to know which methods for
> ingress filtering are supported by the vendor in question, and I want
> a very specific one if that's reasonable considering the other
> There should be a means to communicate what features are supported,
> and what specific features the operator is preferably looking for (to
> maintain interoperability/consistency with other equipment).
I'm not sure I have a good answer. The minute we say "you must support
SSH for remote access", something better will come along or 3 out of 4
operators will choose to use rsh over IPSEC or some such.
In the end, I think the best we can do is sort of what's there:
have the capability (nee requirement) be generic, list examples
of how to do it with current technology (if any), and leave it up
to individual operators to decide what capabilities are
actually requirements for them.
Do you have a better idea ?
> Would there be profiles for different kinds of equipment.
Yes. That's the idea of profiles.
> (there were also quite a bit of typos, minor issues, etc., but I might
> send those separately.)
Send them to me (or the list).