Re: ACL Policy should be a property of the partition of namespace...

["Ed Reed" <ED_REED@novell.com>]

You are, of course, both right.

Many mechanisms do exist, and many of them want to be front-ended by LDAP responders.  Several of them would like to be replicable among other LDAP servers.  It's that last bit that I was addressing.

Scenario 1:  different mechanisms, different namespaces, federation limited to referrals, without replication - no problem, provided the policy mechanism is "known" to clients and servers who know about them, manage them, or know how to use them.

Scenario 2: different mechanisms, same namespace - big problem, since a policy administrator can't know whether the policy will be enforced when data are replicated to a server which doesn't know how to deal with the policy mechanism the administrator set.  This is the case which we've got to figure out how to work around.

Scenario 3: different mechanisms, same namespace, with fractional and/or sparse replication of attributes/objects, such that Server A won't send things to Server B which are subject to some policy mechanism that A knows about, but B doesnt.  This requires a mapping to be performed, perhaps algorithmically, probably manually, and for that to be known in the replica agreement.  This will probably be one of the more frequent causes for the use of fractional and sparse replicas.

Scenario 4: single mechanism, different namespaces - doesn't compute for the reason Paul mentions - multiple non-mappable, non-interoperable mechanisms already exist, and they DO want to be replicated among LDAP servers.  That suggests to me that a canonical mapping of each could be documented by the respective mechanism champions, published, and be used as the mapping mechanism, where possible, described in scenario 3 - either by mapping operations onto the canonical LDAP baseline, or by specifying that attributes/objects requiring protection which is not available in the LDAP baseline should / must not be replicated to a server which only supports the LDAP baseline.

any other possible scenarios anyone can think of?

Ed

-------------------
Ed Reed, Technologist
Group Technology Office
Novell, Inc.
+1 801 861 3320

>>> "Paul Leach" <paulle@microsoft.com> 05/08/1998 11:11:30 >>>
-----BEGIN PGP SIGNED MESSAGE-----

You're forgetting something -- the other policies _already exist_.
Acknowledging that fact, and making the allocation of policy ID
codepoints dependent on a specification of the formats used by the
policy, then you have a lever to encourage specification and hence
interoperability. Ignoring it can only be worse.

The marketplace will take care of insuring that there are only a small
number of relevant policies.
- ---------------------
Paul J. Leach <paulle@microsoft.com>
PGP Key ID: 0x978829DD
Fingerprint: 9EFA A405 39B4 F91F DE6F 8939 6FE9 F5D8
Key Servers: http://pgpkeys.mit.edu:11371 ldap://certserver.pgp.com


-----BEGIN PGP SIGNATURE-----
Version: PGP 5.5.5

iQCVAwUBNVM8lsqlCdSXiCndAQE0MwQAhTkmi6sc1B7KocedL/5MgcP6NsQ0iDvl
K5NkYGWtl+inHQiNFZANemYYuWncv81Exzunsg+2a/gg/1s0O29nfl1exK9EvYCV
VYX24cdrWdpOQU097N06Sw7yDIcUo/xRAtmuP+JSKKpsvUYzQP3pwnEfQ41glPOf
POPrrkzsQ/c=
=yifo
-----END PGP SIGNATURE-----