Give Feedback (closed)
IT-ARCH Discussion List (closed)
Changes to the Directory Service Architecture document
Leading to version 2.4.6, March 6, 2002
- Changed status to "Adopted by CIRT February 20, 2002"
Leading to version 2.4.5, September 19, 2001
- Changed status to "Ready for Adoption"
Leading to version 2.4.4, June 22, 2001
- Section 7.1:
- Say PeopleSoft use of LDAP is with its web interface.
- Added bullet on use of eDirectory and NDS at Emory.
- Section 8: Added "Used" status.
- Section 8.1:
- Added entries for eDirectory under Directory Server and Replication.
- Updated status for Anonymous client.
Leading to version 2.4.3, May 24, 2001
- Copy edited the entire document to correct language, sharpen or clarify meaning, and improve readability.
- Increased consistency of terminology throughout the entire document:
- Replaced "Educause" with "EDUCAUSE" (all caps).
- Replaced "e-mail" with "email" (no hyphen).
- Used lowercase "rfc" before an rfc number and upper case "RFC" to refer to the type of document.
- Used "DN" instead of "dn" for Distinguished Name.
- Section 2: Made changes to add "Configuration and Next Steps" to the document outline.
- Section 5.2, Table heading B.7: Fixed formatting problem.
- Section 5.3.2, #8: noted the qualification in #14 on allowing authenticated clients to do updates.
- Section 7.3: In slurpd changed "?" to "NK". Added that LDIF is an IETF standard.
- Section 11:
- Added web link references to LIPS and NAC.
- Added entry for W3C.
- Rewrote definition of "metadata" to make room for W3C without starting a new page.
- Section 12:
- Made copy edits in: #2, 3, 4, 6, 8, 11, 12, 14, 15 (Implications #2 & 5), 16, 17, 18, 19 (Impl. #1), 21, 24, 25, 27 (Impl. #3), 28 (Impl #1 & 2), 28 (all Impl.).
- #1: Moved an example here from #18 and rewrote it to be more on topic for this principle.
- #2: Replaced "authoritative source" with "source of authority" to reflect a change in approach (see #12, Impl. 1).
- #3: Deleted "authoritative" since that is not the point. Also deleted the sentence about initializing data (it is implicitly covered by the preceding sentence).
- #11: Changed present tense to past tense in the examples.
- #15: Changed "network identifiers" to "userids" in the example.
- #16: Deleted the material about sources from Example 11 to better focus it to the topic of the principle.
- #17: Inserted as a new implication 2 an explicit list of what might be added to the directory, and removed mention of what is being added from the other implications to avoid unnecessary repetition.
- #18:
- Added a summary of mentioned reasons from Doc 2 B.6.
- Updated the example to be more about a directory.
- Removed the examples from the implication about restricting searching, and put them in rewritten form in #1 and #21. This renumbered the examples in section 12.
- #19: Moved a justification bullet to Implications and rewrote it as two implications.
- #21: Replaced the old example with one from #18.
- #22: Rewrote the justification to be more on target.
- #23: Revised the justification to indicate that the vision that the directory service is part of the security infrastructure comes from the directory service architecture.
- #24: Deleted redundant Implication #10.
- #28: Combined, rewrote, and reordered the implications.
Leading to version 2.4.2, May 14, 2001
- Distinguished between data and "types" of data in Trend #2, bullet 1, old principle #2 (now #3), and elsewhere.
- Added recommendations to base directory access control on group membership in Section 5.3 #20; Section 12: Modular (new #7), Fine-grained access (new #21), and Secure the directory data (new #24).
- Updated terminology in all sections as needed to reflect changes in glossary.
- Sections 1 & 3: Removed emphasis on userids and passwords in favor of "authentication information."
- Removed examples of NOS directories from Sect 3.1, Types of Directories & Glossary NOS entry, because the examples given are now being used as general purpose enterprise directories.
- Section 3.3: Intranet domain: In relationship column indicated use of Intranet in Directory rather than use of Directory in Intranet to align it with other usage in the table.
- Section 5: Updated table to reflect change in principle 1, add new principle 2, and adjust descriptive phrases where necessary to incorporate terminology changes.
- Section 10:
- Changed heading to replace "Issues" with "Considerations," distinguish considerations for this domain from those for other domains, and group them by other domain.
- Rewrote Securing the Directory service (was #2) to be more clear and concise.
- Rewrote LDAP Authentication (was #3) to better take into account the approach envisioned by the security architecture.
- Added dc naming items, one for this domain relative to the name, and another for Network relative to use of DNS.
- Added considerations related to Active Directory and Windows 2000, one for Platform and one for Network.
- Section 11, Glossary:
- Updated to better align with LDAP/X.500 meanings.
- Shortened entry for OID to make room to add RFC.
- Added definition for RFC giving URL to locate them.
- Removed "container" and "bind" to avoid page overflow. They were not used elsewhere in the document.
- Section 12, Principles:
- Changed all status "ITA Track" to "Standards track".
- Inserted new principle "Flexible Searching" as principle #1.
- Changed old principle #1 (Dynamic Association) to "2. Support groups with dynamic membership" and rewrote the principle and justification to better reflect what was intended.
- #3. "Easy change to contents" (was #)2:
- Bullet 1: Distinguished between data and types of data.
- Added bullet to include changing schema. Although adding a type of data is a schema change, it is helpful for the less technical reader to list adding new types of data separately.
- #13. "Event Driven" (was #12): Added Implication that the Integration architecture domain addresses infrastructure to support exchange of events between services in a standard way.
- #18. "Support information sharing" (was #17): added need to support anonymous access.
- #20. "Encourage appropriate use" (was #19):
- Rewrote the justification to make it sound more like a justification.
- In Implication #4, changed "LDAP" to "the standard interface(s) for general access (see section 9)" to avoid placing specific choice of technology and standard in a principle.
- Moved the last Justification bullet into the Implications where it more properly belonged..
- #21. "Provide fine-grained access control" (was #20), Implication #3: Changed "object" to "entry," because an access control would likely be specific to an object such as "person" in as much as it would specify patterns involving attributes to an object. What is wanted in this case is to avoid having an access control that is specific to a particular person. Added additional types of access control.
- #22. "Support the needs of security" (was #21):
- Changed the terminology to "policy data store" for alignment with a recent change in the security architecture document.
- In Justification bullet 2, changed the specific reference to the directory service to be a reference to the policy data store, since the latest version of the security architecture leaves the choice of the policy data store as a product decision.
- #23. "Highly secure and interoperable with security layer" (was #22). Added additional security needs, such as to easily support new security methods and technologies, be able to communicate securely, and be able to audit permissions by allowed user by access control list.
- #24. "Secure the directory data entries" (was #23):
- Changed "entries" to "everything" in the statement, and made similar changes throughout the principle to avoid having to repeat the list over and over.
- Pulled all the justifications about source together and related it to security, since the requirement is really part of another principle.
- #26. "Develop competency" (was #25): Changed to include keeping up with technologies and product updates.
- Version 2.4.1, April 9, 2001
- Initial release for review by the Emory community.