idnits 2.17.1 draft-ietf-asid-ldap-cache-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 63 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 68: '...e ttl attribute SHOULD be allowed in ...' RFC 2119 keyword, line 114: '... MAY ttl )...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...-Drafts are ...' == Line 14 has weird spacing: '...ments of the ...' == Line 19 has weird spacing: '...and may be ...' == Line 20 has weird spacing: '...ference mater...' == Line 23 has weird spacing: '...atus of any ...' == (58 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1997) is 9690 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Application Working Group Tim Howes 3 INTERNET-DRAFT Netscape Communications Corp. 4 Expires in six months Luke Howard 5 Intended Category: Standard Independent Consultant 6 October 1997 8 A Simple Caching Scheme for LDAP and X.500 Directories 9 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its areas, and its 15 working groups. Note that other groups may also distribute working docu- 16 ments as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 2. Abstract 31 This memo defines an object class and attribute type in support of a 32 simple caching mechanism for use in LDAP and X.500 directories. The 33 object class allows a simple 'time-to-live' attribute to be included in 34 entries, enabling clients retrieving the attribute to tell when the 35 other information they have retrieved from the entry should be thrown 36 away. The use of this scheme does not preclude the subsequent or addi- 37 tional use of other more complicated schemes, for example, allowing dif- 38 ferent TTLs on individual attributes. 40 3. Need for Caching and Overview 42 LDAP [ldapv3-1, ldapv3-2] and X.500 [x500] define a distributed data- 43 base. To achieve greater performance and availability, it is desirable 44 to replicate information close to the entities accessing it. Formal 45 replication schemes have been devised for this purpose. Caching is an 46 informal method of replication designed to make repeated use of 48 Expires March 1998 INTERNET DRAFT 50 information by the same or co-located clients more efficient. Systems 51 relying on fast performance that can tolerate temporarily out-of-date 52 data, such as the Domain Name System [rfc1034], often make heavy use of 53 caching to achieve the desired level of performance. LDAP and X.500 54 comprise another system that could similarly benefit from caching. 56 Until now, there has been no agreed scheme for providing a consistent 57 caching mechanism for LDAP and X.500. Caching occurs, but it is up to 58 the caching agent to determine the appropriate length of time a piece of 59 information can safely be cached. There is support in X.500 for ignoring 60 all cached or replicated information copies in favor of the master copy, 61 at the client's discretion (the dontUseCopy service control). There is 62 no guidance on the length of time that information (master or not) can 63 safely be cached. 65 This draft defines a simple caching model similar to that used by the 66 DNS. A new operational attribute, ttl, is defined to specify the maximum 67 time for which a cached copy of any attributes in the entry should be 68 considered valid. The ttl attribute SHOULD be allowed in every entry 69 that may be cached. 71 A new object class, cacheObject is defined, which allows an entry to 72 have the new ttl attribute, even if the server implementation does not 73 support operational attributes (e.g., an LDAPv2 server). 75 Note that use of this scheme means that all attributes in an entry are 76 subject to the same TTL. This is satisfactory in many cases, but more 77 complicated situations where different attributes (or even values of the 78 same attribute) may have different TTL requirements can easily arise. 79 The scheme described here is not intended to address these situations, 80 nor is it intended to hinder the development of other schemes that do. 82 4. The ttl Attribute 84 The definition of the ttl attribute is as follows: 86 ( 1.3.6.1.4.1.250.1.60 NAME 'ttl' EQUALITY integerMatch 87 SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' SINGLE-VALUE ) 89 The ttl attribute contains the time, in seconds, that any information 90 from the entry should be kept by a client before it is considered 91 "stale" and a new copy fetched. A value of 0 implies that the object 92 must not be cached. 94 The behaviour of caching clients with respect to entries lacking the ttl 95 is not prescribed. Caching agents may use any appropriate method for 96 determining whether an entry without a ttl attribute should be 97 refetched. For example, clients may compare the modifyTimestamp 99 Expires March 1998 INTERNET DRAFT 101 attribute of the entry with the current one and refetch the entry only 102 if the entry has been updated since it was cached. A number of factors, 103 such as network latency, may render this policy inefficient. As such, 104 clients may assume entries lacking the ttl attribute never expire, or 105 that they expire in some client-defined time period, or that they should 106 never be cached. 108 5. The cacheObject Object Class 110 The cacheObject object class is defined as follows: 112 ( 1.3.6.1.4.1.250.3.18 NAME 'cacheObject' AUXILIARY SUP top 113 DESC 'Auxiliary object class to hold TTL caching information' 114 MAY ttl ) 116 6. Coexistence with entryTtl and DNS-related attributes 118 The entryTtl attribute, defined in [v3ext], is an operational attribute 119 maintained by the directory server which appears to bear superficial 120 resemblance to the ttl attribute. The entryTtl attribute is only present 121 in entries of the dynamicObject object class, and may not be modified by 122 the user. A value of 0 indicates that the entry may disappear from the 123 directory without warning. 125 By contrast, the ttl attribute as defined here refers not to dynamic 126 entries, but to those defined by the user which are accorded a specific 127 time to live. 129 Clients caching entries of class dynamicObject should use the entryTtl 130 attribute instead of the ttl to determine an object's TTL. The same 131 behaviour applies: if the value is 0, the entry should not be cached. 133 The dNSDomain object class [rfc1279] contains attributes, such as 134 dNSRecord, which may include embedded TTLs. If the caching agent has 135 specific cognizance of these attributes, it may wish to honour them in 136 preference to the entryTtl or ttl attributes. This is not required. 138 7. Security Considerations 140 A caching scheme has implications on the accuracy and security of data. 141 Both applications and data providers should be aware of how important 142 information consistency is for the data they are using or providing. 144 When accessing anything but publicly available information, care must be 145 taken by the caching entity to ensure that the intended access control 146 policy of the directory is not violated. This may be accomplished by not 147 caching non-public information at all, or by having an understanding of 148 the source site's access control policies. Note that understanding a 150 Expires March 1998 INTERNET DRAFT 152 site's access control policy may be difficult, given the existence of 153 proprietary schemes, and the fact that there may be mechanisms in place 154 not visible or detectable by the caching entity. These mechanisms may 155 even make the determination of what information is publicly accessible 156 difficult or impossible. 158 8. Bibliography 160 [ldapv3-1]Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access 161 Protocol (v3)", INTERNET-DRAFT , August 1997. 164 [rfc1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 165 Request for Comments (RFC) 1034, November 1987. 167 [ldapv3-2]Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight 168 Directory Access Protocol (v3): Attribute Syntax Definitions", 169 INTERNET-DRAFT , 170 August 1997. 172 [x500] "Information Processing Systems - Open Systems Interconnection 173 - The Directory: Overview of Concepts, Models and Services", 174 ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. 176 [v3ext] Yaacovi, Y., Wahl, M., Genovese, T., "Lightweight Directory 177 Access Protocol (v3): Extensions for Dynamic Directory Ser- 178 vices", INTERNET-DRAFT , September 1997. 181 [rfc1279] Kille, S., "X.500 and Domains", Request for Comments (RFC) 182 1279, November 1991. 184 9. Authors' Addresses 186 Tim Howes 187 Netscape Communications Corp. 188 501 E. Middlefield Rd. 189 Mountain View, CA 94043 190 USA 191 +1 415 937-3419 192 howes@netscape.com 194 Luke Howard 195 PO Box 59 196 Central Park Vic 3145 197 Australia 198 lukeh@xedoc.com 200 Expires March 1998 INTERNET DRAFT