I understand the need for moving many tasks to policy and settings documents, but putting quotas there, for example, would ensure that the admin would need to create an explicit policy to set a user's mail quota or adjust it now--as it typically done in R5, ND6, and ND7 environments (and can be done this way in ND8).

Overall, this would create a lot of overhead for the admin, particularly with users that have existing explicit policies. So, you end up with scores of settings documents to adjust differently, the policy documents for people. So, business execs that need larger mail amounts, or are over quota and need quick relief because they have a major project to complete, but will delete documents shortly, would need a new setting document, have it applied, then have the user logout of Notes to get the Dyncfg to run and pull down the policy. So, it makes a decent situation now, worse is some regards.

Although I appreciate the concept of putting where feasible more settings and options into policies, sometimes the solution can be worse than the issue addressed. Also, at what point to do we stop putting things into policies? We can not have every setting in Domino there. Some things like attachment limits are handled by the router for efficiency. But in theory, I see the value of having OU based attachment limits...but have not been to a client site that required this...usually, their IT policy is company binding. Additionally, if too much is put into policies, you end-up with a performance detriment too, but that is another topic.

Hmmm. I posted a clarification once, but I don't see it. Let's try this a second time...

@Bill:

I should have been more verbose in my original posting; let me clarify: I wasn't thinking of specifying quota *values* in policy, just the enforcement settings associated with quotas, which are currently stored in the Configuration document, with a granularity of one or more home servers. I am quite happy myself with the current arrangement where quota values are properties of a database.

Generally, though, my proposal to make such settings part of policy is a bit bigger than the words themselves; since policy is currently implemented by clients, and I am suggesting that policy control settings which are implemented by servers, I'm really suggesting that a new type of policy be implemented, where we can specify user-, group-, OU-, or Organization-specific restrictions that are implemented by servers.

My specific suggestion was regarding mail restrictions. Implementing these using granular policy might well require rewriting the router, which certainly would have, as you mentioned, an impact on performance, so that would definitely be a consideration for the admin to make. But I'll bet that, if implemented, IBM could come up with all kinds of other ways to implement server-side policy which didn't impact server performance.

Ok, clarification over.

Are you suggesting that a server-side policy replace server configuration documents? I believe something has to be done with configuration documents as they can potentially override each other & the "Most specific to a server wins" can be very vague in a domino environment where there are lots of config docs. I like the idea of a visible hierarchy for server-side policies so that if I want to work out my mail settings for a domain I look into one place. Not sure though that I hijacked your idea for my frustration with configuration documents.