> > to avoid making existing code insecure when introducing new scopes.
> 
> Let's say we introduced a new scope. Can you think of any situation
> where we would dispatch authorization requests on this scope without
> also adding some listeners?

3rd party listeners.

> >> Loading a listener changes the security model. Having no listeners means
> >> that you can't really do anything the scope manages. Having an "always
> >> block" policy is unacceptable.
> > 
> > why unacceptable?
> 
> Because I previously pointed out cases where this behavior will screw
> one of the purposes of kauth(9) - pluggable security models - which
> may not be shipped by us and compiled in.

i don't think it is a good reason to make it per-scope.

> >> I think making the behavior optional is
> >> best. I don't care what would be the default behavior. :)
> > 
> > let's try to avoid introducing too many options.
> 
> This is not the place to save on options; see "IPFILTER_DEFAULT_BLOCK"..

- i don't think it's so relevant.
- i don't think IPFILTER_DEFAULT_BLOCK option is a great idea.
- iirc, ipfilter has a global knob to enable it.
  it's basically what i suggested here.

YAMAMOTO Takashi