Assuming 'inherently' means 'well-known', yes it is true that manually
configured filtering does not *require* a well-known prefix. It is also true
that automation is required for consumers. Just because it is possible to do
manual filtering doesn't invalidate the requirement for automated
simplicity.
We need to stop propagating the idea that requirements are invalid when -
'if the user was educated they would just do it my way, and they aren't
educated so they shouldn't be doing it'. By definition consumers will not be
technically educated, so approaches that work in a large managed network
will simply fail. They need something as simple as; light switches by
default are only accessible internal to the home, but if say the front
porch light needs to be exposed they can explicitly configure it to be
global.
Once again, Tony, you are putting forth a security solution that is not secure. You cannot *ARCHITECT* security into a protocol based on an IP address. It is one thing for the customers to do that- they *may* know their environments. As we have seen with all sorts of spyware and viruses, they probably do not. It's thus even worse when you architect a standard based on what are false assumptions today and are likely to be false assumptions in the future.
The solution to the problem you have raised is a standard enrollment protocol that is invoked between an element and a security management tool. That tool itself must be made user friendly. You're trying to solve the problem at the wrong level. Leave the IP address out of the argument.
Eliot
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
