idnits 2.17.1 draft-ietf-asid-ldap-dynatt-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 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 1 longer page, the longest (page 1) being 448 lines 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 39 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (20 November 1997) is 9654 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 427 looks like a reference -- Missing reference section? '2' on line 431 looks like a reference -- Missing reference section? '3' on line 435 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ASID Working Group Y. Yaacovi 2 INTERNET-DRAFT Microsoft 3 M. Wahl 4 Critical Angle Inc. 5 T. Genovese 6 Microsoft 8 Expires in six months from 20 November 1997 9 Intended Category: Standards Track 11 Lightweight Directory Access Protocol: 12 Dynamic Attributes 13 15 1. Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 2. Abstract 34 This document defines dynamic attributes and the fashion in which they 35 are being set and used on entries in the directory. This document 36 builds heavily on the dynamic extensions to LDAP infrastructure as 37 defined in [1]. 39 The Lightweight Directory Access Protocol (LDAP) [2] supports 40 lightweight access to static directory services, allowing relatively 41 fast search and update access. Static directory services store 42 information about people that persists in its accuracy and value over 43 a long period of time. 45 The dynamic extension to LDAP as defined in [1] added the concept of 46 dynamic entries that only persist in the directory, when they are 47 periodically refreshed. This document takes this approach one step 48 farther and defines how dynamic attributes can be used, on either 49 static or dynamic entries, to handle up-to-date and dynamic 50 information about an entry in the directory. An example use will be a 51 client or a person that has a static entry in the directory and 52 sometimes goes online, which is reflected in the 'online' attribute 53 for the entry. To specify whether this person is online or offline - 54 an attribute that changes frequently, a client application will have 55 to modify this attribute relatively frequently. The current location 56 of a person is another attribute that may change frequently. 58 Dynamic attributes must be periodically refreshed. Otherwise, they 59 will disappear from the directory over time. 61 3. Requirements 63 Dynamic attributes must be set and used in a standard LDAP manner, to 64 allow clients to access static and dynamic attributes in the same way. 66 By definition, dynamic attributes are not persistent and may go away 67 gracefully or not. The proposed draft must offer a way for a server 68 to tell if attributes are still valid, and to do this in a way that is 69 scalable. There also must be a mechanism for clients to reestablish 70 their attributes with the server. 72 Dynamic attributes must build on the same infrastructure that was 73 design into LDAP in the dynamic extensions draft ([1]). It should 74 take advantage of the extensions and operational attributes defined 75 [1]. 77 Finally, to allow clients to broadly use dynamic attributes, they must 78 be able to find out if a server supports such attributes. 80 4. Description of Approach 82 The Lightweight Directory Access Protocol (LDAP) [2] supports the use 83 of attributes on entries in the directory. The dynamic extensions 84 draft ([1]) added support for dynamic entries. This proposal takes 85 the attributes model and the dynamic model and merges the two to 86 provide support for dynamic attributes in a manner which is fully 87 compatible with LDAP and with dynamic entries. 89 The approach taken here is to mark dynamic attributes as dynamic 90 (described below), and require clients to refresh these attributes 91 periodically in order to guarantee that they will continue to be 92 present on the entry. Dynamic attributes can be set on either a 93 static or dynamic entry, and the time-to-live associated with them 94 applies to ALL the dynamic attributes on an entry, i.e. there is no 95 time-to-live per dynamic attribute. This provides for a more scalable 96 design, and a less complex server implementation. 98 4.1. Dynamic Attributes 100 Dynamic attributes behave the same as ordinary user attributes to 101 Search, Compare and Modify requests, except that if they time out they 102 disappear from the entry in which they are located. Unlike the 103 dynamicObject class - which is used to mark entries as dynamic, the 104 entry itself does not disappear, and non-dynamic attributes are 105 unaffected. Like dynamic entries, a static entry with dynamic 106 attributes must have the entryTtl attribute which is described in [1]. 108 Dynamic attributes do not necessarily introduce a new set of 109 attributes in the schema. Any static attribute in the schema can be 110 made dynamic by including the ;dynamic option with the AttributeType 111 (see AttributeDescription in [1]). This does not require the 112 newly-created subtype to be assigned a different OID. It is allowed 113 to introduce new dynamic attributes which are not useful in the static 114 domain. Such attributes will still require including the ;dynamic 115 option with the AttributeType to define them as dynamic. 117 A dynamic attribute may be a subtype of a non-dynamic attribute, but a 118 non-dynamic attribute must not be a subtype of a dynamic attribute. 119 Operational attributes and collective attributes must not be dynamic. 120 All dynamic attributes are considered to be user attributes, however 121 they are not guaranteed to be present in shadow copies of entries. 123 A client may introduce dynamic attributes into an entry by using a 124 Modify request to add them, or by including them in the attribute list 125 of an Add Request. If the attribute type is permitted in the entry 126 then the dynamic attribute is also permitted. The client would 127 specify that the attribute is dynamic by including the option 128 ";dynamic" with the AttributeType. Dynamic values may be changed, and 129 the attributes removed, by using the Modify request as normal. If the 130 entry is deleted, dynamic attributes disappear immediately along with 131 all the non-dynamic. A ;dynamic option on an attribute can be used in 132 a compare request, or in a search request (either in the filter or 133 attributes requested for return). When used in this fashion, only the 134 dynamic values of the attribute will be returned. 136 The granularity of a dynamic attribute is the entire dynamic subtype 137 including all values. The supertype attribute may contain static 138 values, but the dynamic subtype must only contain dynamic values. 139 This requires some explanation: per [2], an attribute of 140 "AttributeType;option" is different from the attribute 141 "AttributeType", e.g. "ipAddress;dynamic" is a different attribute 142 from "ipAddress". It is a subtype of "ipAddress". Values that are 143 added into the dynamic variant (subtype) of an attribute are always 144 regarded as dynamic values. When returned by the server in a search 145 request, they will be returned as values of the dynamic subtype of the 146 attribute. See example in section 4.2. 148 The addition and modification of dynamic attributes are subject to 149 schema and access control restrictions, as with non-dynamic 150 attributes. Thus unless the extensibleObject object class is present, 151 generally an object class or content rule must be defined to permit 152 those attributes to be present in an entry. If their presence is 153 controlled by an object class, then just as with non-dynamic 154 attributes, the object class value must have already been added before 155 the attributes are added. The dynamicObject object class described in 156 [1] does not itself permit any particular dynamic attributes. 158 Dynamic attributes in a particular entry are refreshed using the 159 Refresh extended operation. All of the entry's dynamic attributes are 160 refreshed by a single refresh request. The TTL given in the refresh 161 response applies to all of the entry's dynamic attributes. There is 162 no way to refresh particular dynamic attributes within an entry at 163 different times, or to have different TTLs apply to different dynamic 164 attributes or different values of the same multi-value dynamic 165 attribute. 167 If not refreshed, all dynamic attributes in an entry time out 168 simultaneously. All the attributes which are dynamic with all their 169 values disappear atomically, as if the server had done a ModifyEntry 170 specifying that all the dynamic types were to be deleted from that 171 entry. The client must not expect any dynamic attributes to be 172 present in an entry after the time-to-live for that entry has reached 173 zero. However the attributes may not disappear immediately as servers 174 may only process timing out attributes at intervals (e.g. every few 175 minutes). 177 Note that if an object class definition references a dynamic attribute 178 as a mandatory attribute, the attributes of the entry will still time 179 out, but a schema inconsistency will be present in that entry. (The 180 objectClass attribute and its values always remain since objectClass 181 is not a dynamic attribute.) Thus it is strongly recommended that 182 designers not specify dynamic attributes as anything other than 183 optional attributes of auxiliary classes. 185 Dynamic attributes may be used within dynamic entries (i.e., entries 186 containing object class "dynamicObject", defined in [1]), but since 187 all of such an entry's attributes are implicitly dynamic, such use is 188 superfluous. 190 4.2 Dynamic Atributes Example 192 Suppose the following attributes are added to a static entry: 194 Add "1.2.3.4" to ipAddress 195 Add "3.4.5.6" to ipAddress;dynamic 197 A request for "ipAddress", will return: 199 ipAddress: 1.2.3.4 200 ipAddress;dynamic: 3.4.5.6 202 A request for "ipAddress;dynamic" will return: 204 ipAddress;dynamic: 3.4.5.6 206 5. Protocol Additions 208 Support of dynamic attributes in LDAP does not require any protocol 209 additions beyond the Refresh request and response which were 210 introduced in [1]. 212 6. Schema Additions 214 An entry in the directory which has dynamic attributes must have the 215 entryTtl operational attribute. In addition, the dynamicSubtrees 216 attribute, if present in the root DSE, indicates which subtrees of the 217 directory support the dynamic extensions. The entryTtl attribute and 218 the dynamicSubtrees attribute are defined in [1]. 220 The following attributes are introduced as a result of allowing 221 dynamic attributes on static entries. It is described using the 222 AttributeTypeDescription notation of [3]: 224 ( 1.3.6.1.4.1.1466.101.119.5 NAME 'dynamicAttributesSubtrees' 225 DESC 'This operational attribute is maintained by the server and 226 is present in the Root DSE, if the server supports dynamic 227 attributes as described in this draft. The attribute contains 228 a list of all the subtrees in this directory for which the 229 server supports dynamic attributes.' 230 SYNTAX 'DN' NO-USER-MODIFICATION USAGE dSAOperation ) 232 ( 1.2.840.113556.1.4.612 NAME 'online' 233 DESC 'This attribute is used to indicate whether a entry is the 234 directory is currently online or offline. This attribute 235 should only be used with objects in the directory for which 236 being online or offline makes sense. For example, a 237 person object or a meeting object. Dynamic entries are 238 always expected to be online. This attribute is optional. 239 SYNTAX 'BOOLEAN' SINGLE-VALUE ) 241 ( 1.2.840.113556.1.4.613 NAME 'onlineServer' 242 DESC 'This attribute is used to indicate the DNS names of server 243 where this entry is online. This attribute should only 244 be used with objects in the directory for which being 245 online or offline makes sense. If an entry is not online, 246 the server names in this attribute are meaningless. This 247 attribute is maintained by the client and is optional. 248 SYNTAX 'LDAPString' ) 250 Note that the 'online' and 'onlineServer' attributes are only examples 251 for one particular application of dynamic attributes, and that not all 252 entries with dynamic attributes are required to have these attributes. 254 7. Client and Server Requirements 256 7.1 Client Requirements 258 Clients can find out if a server supports the dynamic extensions by 259 checking the supportedExtension field in the root DSE, to see if the 260 OBJECT IDENTIFIER described in [1] for Refresh request and response, 261 is present. Farther, and as described in [1], clients are expected to 262 check the dynamicSubtrees operational attribute in the root DSE to 263 find out in which subtrees of the directory, the server selected to 264 support the dynamic extensions. 266 To find out if a server specifically supports dynamic attributes, and 267 in which subtrees in the directory, clients must check the 268 dynamicAttributesSubtrees operational attribute in the root DSE. 270 Once an entry has been created in the directory, that has dynamic 271 attributes, clients are responsible for invoking the refresh extended 272 operation, in order to keep these attributes present in the entry. 273 The same holds true for dynamic attributes that were added to an entry 274 after its creation. 276 Clients must not expect that a dynamic attributes will be present in 277 an entry after they have timed out. However it must not either 278 require that the server remove these attributes immediately (some 279 servers may only process timing out attributes at intervals). If the 280 client wishes to ensure an attribute does not exist it should issue a 281 ModifyRequest to remove this attribute explicitly. 283 Initially, a client needs to know how often it should send refresh 284 requests to the server. This value is defined as the CRP (Client 285 Refresh Period) and is set by the server based on the entryTtl. Since 286 the AddRequest and ModifyRequest are left unchanged and are not 287 modified in this proposal to return this value, a client must issue a 288 Refresh extended operation immediately after an Add or Modify that 289 introduced a dynamic attribute to an entry. The Refresh Response will 290 return the CRP (in responseTtl) to the client as described in [1]. 292 Clients must not issue the refresh request for entries to which they 293 did not add dynamic attributes. Please note that when a client 294 refreshes a static entry to which it added dynamic attribute(s), it 295 refreshes ALL the dynamic attributes in this entry, including ones 296 added by other clients. Also note that servers which allow anonymous 297 clients to create and refresh dynamic entries and attributes will not 298 be able to enforce the above. 300 Clients should always be ready to handle the case in which their 301 dynamic attributes timed out. In such a case, the Refresh operation 302 will fail with an error code such as noSuchAttribute, and the client 303 is expected to re-add their dynamic attributes. 305 Clients should be prepared to experience refresh operations failing 306 with protocolError, even though the add and any previous refresh 307 requests succeeded. This might happen if a proxy between the client 308 and the server goes down, and another proxy is used which does not 309 support the Refresh extended operation. 311 7.2 Server Requirements 313 Servers are responsible for removing dynamic attributes when they time 314 out. Servers are not required to do this immediately. 316 Servers must enforce the schema rules listed in above section 4. 318 Servers must ensure that the entryTtl operational attribute described 319 in [1] is present in entries that contain dynamic attributes. 321 Servers are permitted to check the authentication of the client 322 invoking a refresh extended operation, and only permit the operation 323 if it matches that of the client which created the entry or added 324 dynamic attributes to this entry (please see a note about that in 325 section 7.1). Servers may permit anonymous users to refresh entries. 327 Servers which implement support for dynamic attributes must have the 328 OBJECT IDENTIFIER, described in [1] for the request and response, 329 present as a value of the supportedExtension field in the root DSE. 330 They must also have as values in the attributeTypes attribute of their 331 subschema subentries, the AttributeTypeDescription for entryTtl and 332 dynamicSubtrees, as described in [1]. 334 8. Implementation issues 336 8.1 Storage of dynamic information 338 Dynamic information is expected to change very often. In addition, 339 Refresh requests are expected to arrive at the server very often. 340 Disk-based databases that static directory services often use are 341 likely inappropriate for storing dynamic information. We recommend 342 that server implementations store dynamic attributes in memory 343 sufficient to avoid paging. This is not a requirement. 345 We expect LDAP servers to be able to store static and dynamic entries. 346 If an LDAP server does not support dynamic entries, it should respond 347 with an error code such as objectClassViolation. Such a server might 348 still support setting dynamic attributes on a static entry. 350 8.2 Client refresh behavior 352 In some cases, the client might not get a Refresh response. This may 353 happen as a result of a server crash after receiving the Refresh 354 request, the TCP/IP socket timing out in the connection case, or the 355 UDP packet getting lost in the connection-less case. 357 It is recommended that in such a case, the client will retry the 358 Refresh operation immediately, and if this Refresh request does not 359 get a response as well, it will resort to its original Refresh cycle, 360 i.e. send a Refresh request at its Client Refresh Period (CRP). 362 9. Replication 364 Replication is only partially addressed in this draft. There is a 365 separate effort in progress at the IETF on replication of static and 366 dynamic directories. 368 it is allowed to replicate a dynamic entry or a static entry with 369 dynamic attributes. Since the entryTtl is expressed as a relative 370 time (how many seconds till the entry will expire), replicating it 371 means that the replicated entry will be "off" by the replication time. 373 10. Localization 375 The are no localization issues for this extended operation. 377 11. Security Considerations 379 Security issues are not addressed in this document. Please note, 380 though, that anonymous clients are able to refresh attributes which 381 they did not add to an entry. 383 Also, Care should be taken in making use of information obtained from 384 directory servers that has been supplied by client, as it may now be 385 out of date. In many networks, for example, IP addresses are 386 automatically assigned when a host connects to the network, and may be 387 reassigned if that host later disconnects. An IP address obtained 388 from the directory may no longer be assigned to the host that placed 389 the address in the directory. This issue is not specific to LDAP or 390 dynamic directories. 392 11. Acknowledgments 394 Design ideas included in this document are based on those discussed in 395 ASID and other IETF Working Groups. 397 12. Authors Addresses 399 Yoram Yaacovi 400 Microsoft 401 One Microsoft way 402 Redmond, WA 98052 403 USA 405 Phone: +1 206-936-9629 406 EMail: yoramy@microsoft.com 408 Mark Wahl 409 Critical Angle Inc. 410 4815 W. Braker Lane #502-385 411 Austin, TX 78759 412 USA 414 EMail: M.Wahl@critical-angle.com 416 Tony Genovese 417 Microsoft 418 One Microsoft way 419 Redmond, WA 98052 420 USA 422 Phone: +1 206-703-0852 423 EMail: tonyg@microsoft.com 425 13. Bibliography 427 [1] Y.Yaacovi, M.Wahl, T.Genovese, "Lightweight Directory Access Protocol 428 (v3): Extensions for Dynamic Directory Services". INTERNET DRAFT. 429 431 [2] M.Wahl, T. Howes, S. Kille, "Lightweight Directory Access 432 Protocol (Version 3)". INTERNET DRAFT 433 435 [3] M.Wahl, A.Coulbeck, T. Howes, S. Kille, "Lightweight Directory 436 Access Protocol (v3): Attribute Syntax Definitions". INTERNET DRAFT 437 439 Expires on six months from the post date (see top).