Hi all,

I've been working on implementing this cascading control in the context of the schema subsystem which
is highly specialized with cross references and dependencies to model inheritance of attributeTypes and
objectClasses.  This is why a cascade option is needed while performing modify operations.  I am realizing
that there are some limitations to doing this properly and at the same time there are serious pitfalls in this
feature without it being curbed.

I don't think we should add this feature without having the ability to mark schemas, and individual schema
elements as read-only (exposed in subschemaSubentry as X-READ-ONLY schema extension).  Only the
administrator and owner of the schema should have the ability to revert the read only flag.  Even the admin
should not be able to delete schema elements with or without the cascade control present if any element
in the dependency chain is marked read only.

Now here is my dilema. I would never allow a production grade release without having these checks in
place.  Just imagine what would happen if the admin deleted the 'top' objectClass or the 'name'
attributeType: a large amount of the schema would be blown away and the server would be rendered
useless although blowing away the schema partition folder will recreate it with the defaults.  Regardless
should we allow this feature in this (non-production) feature release with a warning.

Another option is to disable cascade deletes for now and just support cascading modifications?

Thoughts?

Alex