On Tue, 9 Nov 2004 15:34:01 +0200 (EET), Pekka Savola
<pekkas@netcore.fi>
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
implementations.
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
tradeoffs.
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 ?