idnits 2.17.1 draft-howard-rfc2307bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 27. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1086. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([X500], [RFC2251]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 711 has weird spacing: '... 53/tcp names...' == Line 712 has weird spacing: '... 53/udp names...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 February 2005) is 7005 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2252' is defined on line 862, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) Summary: 20 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Application Working Group L. Howard 3 INTERNET-DRAFT PADL Software 4 Expires in six months M. Ansari 5 Infoblox 7 20 February 2005 8 Intended Category: Informational 9 Obsoletes: RFC 2307 11 An Approach for Using LDAP as a Network Information Service 12 14 Status of this Memo 16 This document is intended to be, after appropriate review and revi- 17 sion, submitted to the RFC Editor for publication as an Experimen- 18 tal document. Distribution of this memo is unlimited. Technical 19 discussion of this document will take place on the IETF LDAP Exten- 20 sions mailing list . Please send editorial com- 21 ments directly to the author . 23 By submitting this Internet-Draft, I accept the provisions of Sec- 24 tion 4 of RFC 3667. By submitting this Internet-Draft, I certify 25 that any applicable patent or other IPR claims of which I am aware 26 have been disclosed, or will be disclosed, and any of which I 27 become aware will be disclosed, in accordance with RFC 3668. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other docu- 36 ments at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in 38 progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 45 Copyright (C) The Internet Society (2005). All Rights Reserved. 47 Please see the Full Copyright section near the end of this document 48 for more information. 50 Abstract 52 This document describes a mechanism for mapping entities related to 53 TCP/IP and the UNIX system into X.500 [X500] entries so that they 54 may be resolved with the Lightweight Directory Access Protocol 55 [RFC2251]. A set of attribute types and object classes are pro- 56 posed, along with specific guidelines for interpreting them. 58 The intention is to assist the deployment of LDAP as an organiza- 59 tional nameservice. No proposed solutions are intended as standards 60 for the Internet. Rather, it is hoped that a general consensus 61 will emerge as to the appropriate solution to such problems, lead- 62 ing eventually to the adoption of standards. The proposed mechanism 63 has already been implemented with some success. 65 1. Background and Motivation 67 The UNIX (R) operating system, and its derivatives (specifically, 68 those which support TCP/IP and conform to the X/Open Single UNIX 69 specification [XOPEN]) require a means of looking up entities, by 70 matching them against search criteria or by enumeration. (Other 71 operating systems that support TCP/IP may provide some means of 72 resolving some of these entities. This schema is applicable to 73 those environments also.) 75 These entities include users, groups, IP services (which map names 76 to IP ports and protocols, and vice versa), IP protocols (which map 77 names to IP protocol numbers and vice versa), RPCs (which map names 78 to ONC Remote Procedure Call [RFC1057] numbers and vice versa), NIS 79 netgroups, booting information (boot parameters and MAC address 80 mappings), filesystem mounts, IP hosts and networks. 82 Resolution requests are made through a set of C functions, provided 83 in the UNIX system's C library. For example, the UNIX system util- 84 ity "ls", which enumerates the contents of a filesystem directory, 85 uses the C library function getpwuid() in order to map user IDs to 86 login names. Once the request is made, it is resolved using a 87 "nameservice" which is supported by the client library. The name- 88 service may be, at its simplest, a collection of files in the local 89 filesystem which are opened and searched by the C library. Other 90 common nameservices include the Network Information Service (NIS) 91 and the Domain Name System (DNS). (The latter is typically used for 92 resolving hosts, services and networks.) Both these nameservices 93 have the advantage of being distributed and thus permitting a com- 94 mon set of entities to be shared amongst many clients. 96 LDAP is a distributed, hierarchical directory service access proto- 97 col which is used to access repositories of users and other net- 98 work-related entities. Because LDAP is often not tightly integrated 99 with the host operating system, information such as users may need 100 to be kept both in LDAP and in an operating system supported name- 101 service such as NIS. By using LDAP as the the primary means of 102 resolving these entities, these redundancy issues are minimized and 103 the scalability of LDAP can be exploited. (By comparison, NIS ser- 104 vices based on flat files do not have the scalability or extensi- 105 bility of LDAP or X.500.) 107 The object classes and attributes defined below are suitable for 108 representing the aforementioned entities in a form compatible with 109 LDAP and X.500 directory services. 111 2. General Issues 113 2.1 Terminology 115 The key words "MUST", "SHOULD", and "MAY" used in this document are 116 to be interpreted as described in [RFC2119]. 118 For the purposes of this document, the term "nameservice" refers to 119 a service, such as NIS or flat files, that is used by the operating 120 system to resolve entities within a single, local naming context. 121 Contrast this with a "directory service" such as LDAP, which sup- 122 ports extensible schema and multiple naming contexts. 124 The term "NIS-related entities" broadly refers to entities which 125 are typically resolved using the Network Information Service. (NIS 126 was previously known as YP.) Deploying LDAP for resolving these 127 entities does not imply that NIS be used, as a gateway or other- 128 wise. In particular, the host and network classes are generically 129 applicable, and may be implemented on any system that wishes to use 130 LDAP or X.500 for host and network resolution. 132 The "DUA" (directory user agent) refers to the LDAP client querying 133 these entities, such as an LDAP to NIS gateway or the C library. 134 The "client" refers to the application which ultimately makes use 135 of the information returned by the resolution. It is irrelevant 136 whether the DUA and the client reside within the same address 137 space. The act of the DUA making this information to the client is 138 termed "republishing". 140 To avoid confusion, the term "login name" refers to the user's 141 login name (being the value of the uid attribute) and the term 142 "user ID" refers to he user's integer identification number (being 143 the value of the uidNumber attribute). 145 The phrases "resolving an entity" and "resolution of entities" 146 refer respectively to enumerating NIS-related entities of a given 147 type, and matching them against a given search criterion. One or 148 more entities are returned as a result of successful "resolutions" 149 (a "match" operation will only return one entity). 151 The use of the term UNIX does not confer upon this schema the 152 endorsement of owners of the UNIX trademark. Where necessary, the 153 term "TCP/IP entity" is used to refer to protocols, services, 154 hosts, and networks, and the term "UNIX entity" to its complement. 155 (The former category does not mandate the host operating system 156 supporting the interfaces required for resolving UNIX entities.) 158 The OIDs defined below are derived from iso(1) org(3) dod(6) inter- 159 net(1) directory(1) nisSchema(1). 161 2.2 Attributes 163 The attributes and classes defined in this document are summarized 164 below. 166 The following attributes are defined in this document: 168 uidNumber 169 gidNumber 170 gecos 171 homeDirectory 172 loginShell 173 shadowLastChange 174 shadowMin 175 shadowMax 176 shadowWarning 177 shadowInactive 178 shadowExpire 179 shadowFlag 180 memberUid 181 memberNisNetgroup 182 nisNetgroupTriple 183 ipServicePort 184 ipServiceProtocol 185 ipProtocolNumber 186 oncRpcNumber 187 ipHostNumber 188 ipNetworkNumber 189 ipNetmaskNumber 190 macAddress 191 bootParameter 192 bootFile 193 nisMapName 194 nisMapEntry 195 nisPublicKey 196 nisSecretKey 197 nisDomain 198 automountMapName 199 automountKey 200 automountInformation 202 Additionally, some of the attributes defined in [RFC2256] and 203 [RFC3112] are required. 205 2.3 Object classes 207 The following object classes are defined in this document: 209 posixAccount 210 shadowAccount 211 posixGroup 212 ipService 213 ipProtocol 214 oncRpc 215 ipHost 216 ipNetwork 217 nisNetgroup 218 nisMap 219 nisObject 220 ieee802Device 221 bootableDevice 222 nisKeyObject 223 nisDomainObject 224 automountMap 225 automount 227 Additionally, some of the classes defined in [RFC2256] are 228 required. 230 3. Attribute definitions 232 This section contains attribute definitions to be implemented by 233 DUAs supporting this schema. 235 ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' 236 DESC 'An integer uniquely identifying a user in an 237 administrative domain' 238 EQUALITY integerMatch 239 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 240 SINGLE-VALUE ) 242 ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' 243 DESC 'An integer uniquely identifying a group in an 244 administrative domain' 245 EQUALITY integerMatch 246 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 247 SINGLE-VALUE ) 249 ( 1.3.6.1.1.1.1.2 NAME 'gecos' 250 DESC 'The GECOS field; the common name' 251 EQUALITY caseIgnoreMatch 252 SUBSTRINGS caseIgnoreSubstringsMatch 253 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 254 SINGLE-VALUE ) 256 ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' 257 DESC 'The absolute path to the home directory' 258 EQUALITY caseExactIA5Match 259 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 260 SINGLE-VALUE ) 262 ( 1.3.6.1.1.1.1.4 NAME 'loginShell' 263 DESC 'The path to the login shell' 264 EQUALITY caseExactIA5Match 265 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 266 SINGLE-VALUE ) 268 ( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange' 269 EQUALITY integerMatch 270 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 271 SINGLE-VALUE ) 273 ( 1.3.6.1.1.1.1.6 NAME 'shadowMin' 274 EQUALITY integerMatch 275 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 276 SINGLE-VALUE ) 278 ( 1.3.6.1.1.1.1.7 NAME 'shadowMax' 279 EQUALITY integerMatch 280 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 281 SINGLE-VALUE ) 283 ( 1.3.6.1.1.1.1.8 NAME 'shadowWarning' 284 EQUALITY integerMatch 285 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 286 SINGLE-VALUE ) 288 ( 1.3.6.1.1.1.1.9 NAME 'shadowInactive' 289 EQUALITY integerMatch 290 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 291 SINGLE-VALUE ) 293 ( 1.3.6.1.1.1.1.10 NAME 'shadowExpire' 294 EQUALITY integerMatch 295 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 296 SINGLE-VALUE ) 298 ( 1.3.6.1.1.1.1.11 NAME 'shadowFlag' 299 EQUALITY integerMatch 300 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 301 SINGLE-VALUE ) 303 ( 1.3.6.1.1.1.1.12 NAME 'memberUid' 304 EQUALITY caseExactMatch 305 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 307 ( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup' 308 EQUALITY caseExactMatch 309 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 311 ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' 312 DESC 'Netgroup triple' 313 EQUALITY caseIgnoreMatch 314 SUBSTRINGS caseIgnoreSubstringsMatch 315 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 317 ( 1.3.6.1.1.1.1.15 NAME 'ipServicePort' 318 DESC 'Service port number' 319 EQUALITY integerMatch 320 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 321 SINGLE-VALUE ) 323 ( 1.3.6.1.1.1.1.16 NAME 'ipServiceProtocol' 324 DESC 'Service protocol name' 325 EQUALITY caseIgnoreMatch 326 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 328 ( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber' 329 DESC 'IP protocol number' 330 EQUALITY integerMatch 331 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 332 SINGLE-VALUE ) 334 ( 1.3.6.1.1.1.1.18 NAME 'oncRpcNumber' 335 DESC 'ONC RPC number' 336 EQUALITY integerMatch 337 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 338 SINGLE-VALUE ) 340 ( 1.3.6.1.1.1.1.19 NAME 'ipHostNumber' 341 DESC 'IPv4 addresses as a dotted decimal omitting leading 342 zeros or IPv6 addresses as defined in RFC2373' 343 EQUALITY caseIgnoreIA5Match 344 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 346 ( 1.3.6.1.1.1.1.20 NAME 'ipNetworkNumber' 347 DESC 'IP network omitting leading zeros, eg. 192.168' 348 EQUALITY caseIgnoreIA5Match 349 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 350 SINGLE-VALUE ) 352 ( 1.3.6.1.1.1.1.21 NAME 'ipNetmaskNumber' 353 DESC 'IP netmask omitting leading zeros, eg. 255.255.255.0' 354 EQUALITY caseIgnoreIA5Match 355 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 356 SINGLE-VALUE ) 358 ( 1.3.6.1.1.1.1.22 NAME 'macAddress' 359 DESC 'MAC address in maximal, colon separated hex 360 notation, eg. 00:00:92:90:ee:e2' 361 EQUALITY caseIgnoreIA5Match 362 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 364 ( 1.3.6.1.1.1.1.23 NAME 'bootParameter' 365 DESC 'rpc.bootparamd parameter' 366 EQUALITY caseExactIA5Match 367 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 369 ( 1.3.6.1.1.1.1.24 NAME 'bootFile' 370 DESC 'Boot image name' 371 EQUALITY caseExactIA5Match 372 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 374 ( 1.3.6.1.1.1.1.26 NAME 'nisMapName' 375 DESC 'Name of a generic NIS map' 376 EQUALITY caseIgnoreMatch 377 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} ) 379 ( 1.3.6.1.1.1.1.27 NAME 'nisMapEntry' 380 DESC 'A generic NIS entry' 381 EQUALITY caseExactMatch 382 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 383 SINGLE-VALUE ) 385 ( 1.3.6.1.1.1.1.28 NAME 'nisPublicKey' 386 DESC 'NIS public key' 387 EQUALITY octetStringMatch 388 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 389 SINGLE-VALUE ) 391 ( 1.3.6.1.1.1.1.29 NAME 'nisSecretKey' 392 DESC 'NIS secret key' 393 EQUALITY octetStringMatch 394 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 395 SINGLE-VALUE ) 397 ( 1.3.6.1.1.1.1.30 NAME 'nisDomain' 398 DESC 'NIS domain' 399 EQUALITY caseIgnoreIA5Match 400 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) 402 ( 1.3.6.1.1.1.1.31 NAME 'automountMapName' 403 DESC 'automount Map Name' 404 EQUALITY caseExactMatch 405 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 406 SINGLE-VALUE ) 408 ( 1.3.6.1.1.1.1.32 NAME 'automountKey' 409 DESC 'Automount Key value' 410 EQUALITY caseExactMatch 411 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 412 SINGLE-VALUE ) 414 ( 1.3.6.1.1.1.1.33 NAME 'automountInformation' 415 DESC 'Automount information' 416 EQUALITY caseExactMatch 417 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 418 SINGLE-VALUE ) 420 4. Class definitions 422 This section contains class definitions to be implemented by DUAs 423 supporting the schema. 425 Various schema for mail routing and delivery using LDAP directories 426 have been proposed, and as such this document does not consider 427 schema for representing mail aliases or distribution lists. 429 ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY 430 DESC 'Abstraction of an account with POSIX attributes' 431 MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) 432 MAY ( authPassword $ userPassword $ loginShell $ gecos $ 433 description ) ) 435 ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' SUP top AUXILIARY 436 DESC 'Additional attributes for shadow passwords' 437 MUST uid 438 MAY ( authPassword $ userPassword $ description $ 439 shadowLastChange $ shadowMin $ shadowMax $ 440 shadowWarning $ shadowInactive $ 441 shadowExpire $ shadowFlag ) ) 443 ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top AUXILIARY 444 DESC 'Abstraction of a group of accounts' 445 MUST gidNumber 446 MAY ( authPassword $ userPassword $ memberUid $ 447 description ) ) 449 ( 1.3.6.1.1.1.2.3 NAME 'ipService' SUP top STRUCTURAL 450 DESC 'Abstraction an Internet Protocol service. 451 Maps an IP port and protocol (such as tcp or udp) 452 to one or more names; the distinguished value of 453 the cn attribute denotes the service's canonical 454 name' 455 MUST ( cn $ ipServicePort $ ipServiceProtocol ) 456 MAY description ) 458 ( 1.3.6.1.1.1.2.4 NAME 'ipProtocol' SUP top STRUCTURAL 459 DESC 'Abstraction of an IP protocol. Maps a protocol number 460 to one or more names. The distinguished value of the cn 461 attribute denotes the protocol canonical name' 462 MUST ( cn $ ipProtocolNumber ) 463 MAY description ) 465 ( 1.3.6.1.1.1.2.5 NAME 'oncRpc' SUP top STRUCTURAL 466 DESC 'Abstraction of an Open Network Computing (ONC) 467 [RFC1057] Remote Procedure Call (RPC) binding. 468 This class maps an ONC RPC number to a name. 469 The distinguished value of the cn attribute denotes 470 the RPC service canonical name' 471 MUST ( cn $ oncRpcNumber ) 472 MAY description ) 474 ( 1.3.6.1.1.1.2.6 NAME 'ipHost' SUP top AUXILIARY 475 DESC 'Abstraction of a host, an IP device. The distinguished 476 value of the cn attribute denotes the host's canonical 477 name. Device SHOULD be used as a structural class' 478 MUST ( cn $ ipHostNumber ) 479 MAY ( authPassword $ userPassword $ l $ description $ manager ) ) 481 ( 1.3.6.1.1.1.2.7 NAME 'ipNetwork' SUP top STRUCTURAL 482 DESC 'Abstraction of a network. The distinguished value of 483 the cn attribute denotes the network canonical name' 484 MUST ipNetworkNumber 485 MAY ( cn $ ipNetmaskNumber $ l $ description $ manager ) ) 487 ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL 488 DESC 'Abstraction of a netgroup. May refer to other netgroups' 489 MUST cn 490 MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) 492 ( 1.3.6.1.1.1.2.9 NAME 'nisMap' SUP top STRUCTURAL 493 DESC 'A generic abstraction of a NIS map' 494 MUST nisMapName 495 MAY description ) 497 ( 1.3.6.1.1.1.2.10 NAME 'nisObject' SUP top STRUCTURAL 498 DESC 'An entry in a NIS map' 499 MUST ( cn $ nisMapEntry $ nisMapName ) 500 MAY description ) 502 ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' SUP top AUXILIARY 503 DESC 'A device with a MAC address; device SHOULD be 504 used as a structural class' 505 MAY macAddress ) 507 ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice' SUP top AUXILIARY 508 DESC 'A device with boot parameters; device SHOULD be 509 used as a structural class' 510 MAY ( bootFile $ bootParameter ) ) 512 ( 1.3.6.1.1.1.2.14 NAME 'nisKeyObject' SUP top AUXILIARY 513 DESC 'An object with a public and secret key' 514 MUST ( cn $ nisPublicKey $ nisSecretKey ) 515 MAY ( uidNumber $ description ) ) 517 ( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top AUXILIARY 518 DESC 'Associates a NIS domain with a naming context' 519 MUST nisDomain ) 521 ( 1.3.6.1.1.1.2.16 NAME 'automountMap' SUP top STRUCTURAL 522 MUST ( automountMapName ) 523 MAY description ) 525 ( 1.3.6.1.1.1.2.17 NAME 'automount' SUP top STRUCTURAL 526 DESC 'Automount information' 527 MUST ( automountKey $ automountInformation ) 528 MAY description ) 530 5. Implementation details 532 5.1 Suggested resolution methods 534 The preferred means of directing a client application (one using 535 the shared services of the C library) to use LDAP as its informa- 536 tion source for the functions listed in Appendix B is to modify the 537 source code to directly query LDAP. As the source to commercial C 538 libraries and applications is rarely available to the end-user, one 539 could emulate a supported nameservice (such as NIS). (This is also 540 an appropriate opportunity to perform caching of entries across 541 process address spaces.) In the case of NIS, reference implementa- 542 tions are widely available and the RPC interface is well known. 544 The means by which the operating system is directed to use LDAP is 545 implementation dependent. For example, some operating systems and C 546 libraries support end-user extensible resolvers using dynamically 547 loadable libraries and a nameservice "switch". The means in which 548 the DUA locates LDAP servers is also implementation dependent. 550 5.2 Interpreting user and group entries 552 User and group resolution is initiated by the functions prefixed by 553 getpw and getgr respectively. The uid attribute contains the user's 554 login name. The cn attribute, in posixGroup entries, contains the 555 group's name. This document preserves the use of the uid attribute 556 even though, being a naming attribute, its syntax is case insensi- 557 tive. This may cause a problem with existing deployments where 558 there exist login names differing only in case. If DUAs support 559 attribute mapping, a different attribute may be used to represent 560 users' login names. 562 The account object class provides a convenient structural class for 563 posixAccount, and SHOULD be used where additional attributes are 564 not required. For groups with one of more distinguished names, the 565 groupOfUniqueNames object class MUST be used as a structural object 566 class. For groups whose members are only login names, the namedOb- 567 ject [namedObject] object class MAY be used as a structural object 568 class. 570 It is suggested that uid and cn are used as the naming attribute 571 for posixAccount and posixGroup entries, respectively. Group mem- 572 bers may either be login names (values of memberUid) or distin- 573 guished names (values of uniqueMember). In the latter case, the 574 distinguished name must be mapped to one or more login names by 575 examining the name's RDN or, if it is not distinguished by uid, 576 performing a base search on the DN with a filter of "(object- 577 class=*)". DUAs may wish to cache DN to login name mappings. The 578 DUA MAY traverse nested groups. 580 An account's GECOS field is preferably determined by a value of the 581 gecos attribute. If no gecos attribute exists, the value of the cn 582 attribute MUST be used. (The existence of the gecos attribute 583 allows information embedded in the GECOS field, such as a user's 584 telephone number, to be returned to the client without overloading 585 the cn attribute. It also accommodates directories where the common 586 name does not contain the user's full name.) 588 An entry of class posixAccount, posixGroup, or shadowAccount with- 589 out an authPassword or userPassword attribute MUST NOT be used for 590 authentication. In this case the client SHOULD be returned a non- 591 matchable password such as "x". 593 If userPassword is used, its values MUST be represented by follow- 594 ing syntax: 596 passwordvalue = schemeprefix encryptedpasswd 597 schemeprefix = "{" scheme "}" 598 scheme = "crypt" / "md5" / "sha" / "ssha" / altscheme 599 altscheme = "x-" keystring 600 encryptedpasswd = encrypted password 602 The encrypted password contains of a plaintext key hashed using the 603 algorithm scheme. If the schema is "sha", the encrypted password 604 is the base64 encoding of the SHA-1 digest of the plaintext pass- 605 word. 607 userPassword values which do not adhere to this syntax MUST NOT be 608 used for authentication. The DUA MUST iterate through the values of 609 the attribute until a value matching the above syntax is found. 610 Only if encryptedpassword is an empty string does the user have no 611 password. DUAs are not required to consider encryption schemes 612 which the client will not recognize; in most cases, it may be suf- 613 ficient to consider only "crypt". 615 DUA MAY use the authPassword attribute instead of userPassword, 616 defined in [RFC3112]. The DUA MUST iterate the values of the auth- 617 Password attribute until a value whose scheme is CRYPT is found. 618 The DUA MAY iterate through the values of the userPassword 619 attribute, using the syntax defined in RFC 2307, until a value 620 whose scheme is CRYPT is found. If no conforming value is found, 621 the client MUST be returned a non-matchable password such as "x". 622 Authentication using schemes other than CRYPT is, although advis- 623 able, beyond the scope of this document. 625 Below is an example of an authPassword attribute: 627 authPassword: CRYPT$X5/DBrWPOQQaI 629 Below is an example of a (deprecated) userPassword attribute: 631 userPassword: {CRYPT}X5/DBrWPOQQaI 633 A DUA MAY utilize the attributes in the shadowAccount class to pro- 634 vide shadow password service (getspnam() and getspent()). In such 635 cases, the DUA MUST NOT make use of the userPassword attribute for 636 getpwnam() et al, and MUST return a non-matchable password (such as 637 "x") to the client instead. 639 5.4 Interpreting hosts and networks 641 The ipHostNumber and ipNetworkNumber attributes are defined in 642 preference to dNSRecord (defined in [RFC1279]), in order to sim- 643 plify the DUA's role in interpreting entries in the directory. A 644 dNSRecord expresses a complete resource record, including time to 645 live and class data, which is extraneous to this schema. 647 Additionally, the ipHost and ipNetwork classes permit a host or 648 network (respectively) and all its aliases to be represented by a 649 single entry in the directory. This is not necessarily possible if 650 a DNS resource record is mapped directly to an LDAP entry. Imple- 651 mentations that wish to use LDAP to master DNS zone information are 652 not precluded from doing so, and may simply avoid the ipHost and 653 ipNetwork classes. 655 This document redefines, although not exclusively, the ipNetwork 656 class defined in [RFC1279], in order to achieve consistent naming 657 with ipHost. The ipNetworkNumber attribute is also used in the 658 siteContact object class [ROSE]. 660 The authPassword and userPassword attributes are included in ipHost 661 such that hosts may be treated as authentication principals. The 662 treatment of these attribute and inherent caveats considered in 663 section 5.2 apply here also. 665 The trailing zeros in a network address MUST be omitted. CIDR-style 666 network addresses (eg. 192.168.1/24) MAY be used. 668 Leading zeros MUST be removed from all components of an IPv6 669 address string as defined by [RFC2373], section 2.2, item 1. The 670 IPv6 address string MUST be further normalized by following the 671 "::" syntax as defined in section 2.2, item 2. In addition, "::" 672 MUST be used to replace the longest string of zero bits. If there 673 are two or more longest strings of zero bits, then the first string 674 MUST be replaced. In addition, the syntax defined by [RFC2373], 675 section 2.2, item 3 MUST NOT be used. IPv4 addresses MUST be rep- 676 resented by the IPv4 dotted decimal string syntax. 678 For example the following address: 680 1080:0000:0:0:08:800:200C:417A 681 FF01:0:0:0:0:0:01 682 0:0:0:0:0:0:0:0001 683 0:0:0:0:0:0:0:0 685 MUST be normalized as: 687 1080::8:800:200C:417A 688 FF01::101 689 0::1 690 :: 692 5.5 Interpreting other entities 694 In general, a one-to-one mapping between entities and LDAP entries 695 is proposed, in that each entity has exactly one representation in 696 the DIT. In some cases this is not feasible; for example, a service 697 which is represented in more than one protocol domain. Consider the 698 following entry: 700 dn: cn=domain,ou=services,dc=aja,dc=com 701 objectClass: top 702 objectClass: ipService 703 cn: domain 704 cn: nameserver 705 ipServicePort: 53 706 ipServiceProtocol: tcp 707 ipServiceProtocol: udp 709 This entry MUST map to the following two (2) services entities: 711 domain 53/tcp nameserver 712 domain 53/udp nameserver 714 While the above two entities may be represented as separate LDAP 715 entities, with different distinguished names (such as 716 cn=domain+ipServiceProtocol=tcp, ... and cn=domain+ipServiceProto- 717 col=udp, ...) it is convenient to represent them as a single entry. 718 (If a service is represented in multiple protocol domains with dif- 719 ferent ports, then multiple entries are required; multivalued RDNs 720 may be used to distinguish them.) 722 With the exception of authPassword and userPassword values, empty 723 values (consisting of a zero length string) are returned by the DUA 724 to the client. The DUA MUST reject any entries which do not conform 725 to the schema (missing mandatory attributes). Non-conforming 726 entries SHOULD be ignored while enumerating entries. 728 The nisDomainObject object class is provided to associate a NIS 729 domain with a naming context. A DUA would retrieve the NIS domain 730 name from a configuration file and enumerate the naming contexts 731 served by an LDAP server, searching each naming context for (nisDo- 732 main=%s). The first matching entry that is found may be used as a 733 search base for configuration profile information or for entries 734 themselves. For example, the following example shows an association 735 between the NIS domain "nis.aja.com" and the naming context 736 "dc=aja,dc=com": 738 dn: dc=aja,dc=com 739 objectClass: top 740 objectClass: domain 741 objectClass: nisDomainObject 742 dc: aja 743 nisDomain: nis.aja.com 745 The nisObject object class MAY be used as a generic means of repre- 746 senting NIS entities. Its use is not encouraged; where support for 747 entities not described in this schema is desired, an appropriate 748 schema should be devised. Implementors are strongly advised to sup- 749 port end-user extensible mappings between NIS entities and object 750 classes. (Where the nisObject class is used, the nisMapName 751 attribute may be used as a RDN.) The nisObject class might be used 752 to represent automount information. 754 5.6 Canonicalizing entries with multi-valued naming attributes 755 For entities such as hosts, services, networks, protocols, and 756 RPCs, where there may be one or more aliases, the respective 757 entry's relative distinguished name SHOULD be used to determine the 758 canonical name. Any other values for the same attribute are used 759 as aliases. For example, the service described in section 5.5 has 760 the canonical name "domain" and exactly one alias, "nameserver". 762 The schema in this document generally only defines one attribute 763 per class which is suitable for distinguishing an entity (excluding 764 any attributes with integer syntax; it is assumed that entries will 765 be distinguished on name). Usually, this is the common name (cn) 766 attribute. This aids the DUA in determining the canonical name of 767 an entity, as it can examine the value of the relative distin- 768 guished name. Aliases are thus any values of the distinguishing 769 attribute (such as cn) which do not match the canonical name of the 770 entity. 772 In the event that a different attribute is used to distinguish the 773 entry, as may be the case where these object classes are used as 774 auxiliary classes, the entry's canonical name may not be present in 775 the RDN. In this case, the DUA MUST choose one of the non-distin- 776 guished values to represent the entity's canonical name. As the 777 directory server guarantees no ordering of attribute values, it may 778 not be possible to distinguish an entry deterministically. This 779 ambiguity SHOULD NOT be resolved by mapping one directory entry 780 into multiple entities. 782 6. Implementation focus 784 Gateways between NIS and LDAP have been developed by PADL Software 785 and Sun Microsystems. They both support this schema. 787 An open source implementation of the C library resolution code has 788 been written and is available from PADL Software. It supports C 789 libraries on GNU, BSD, AIX, and Solaris operating systems. PADL 790 have also made available a set of scripts for migrating flat files 791 into a form suitable for loading into an LDAP server. 793 7. Security considerations 795 The entirety of related security considerations are outside the 796 scope of this document. It is noted that making passwords 797 encrypted with a widely understood hash function (such as crypt()) 798 available to non-privileged users is dangerous because it exposes 799 them to dictionary and brute-force attacks. This is proposed only 800 for compatibility with existing UNIX system implementations. Sites 801 where security is critical SHOULD consider using a strong authenti- 802 cation service for user authentication. 804 Alternatively, the encrypted password could be made available only 805 to a subset of privileged DUAs, which would provide "shadow" pass- 806 word service to client applications. This may be difficult to 807 enforce. 809 Because the schema represents operating system-level entities, 810 access to these entities SHOULD be granted on a discretionary 811 basis. (There is little point in restricting access to data which 812 will be republished without restriction, however.) It is particu- 813 larly important that only administrators can modify entries defined 814 in this schema, with the exception of allowing a principal to 815 change their password (which may be done on behalf of the user by a 816 client bound as a superior principal, such that password restric- 817 tions may be enforced). For example, if a user were allowed to 818 change the value of their uidNumber attribute, they could subvert 819 security by equivalencing their account with the superuser account. 821 A subtree of the DIT which is to be republished by a DUA (such as a 822 NIS gateway) SHOULD be within the same administrative domain that 823 the republishing DUA represents. (For example, principals outside 824 an organization, while conceivably part of the DIT, should not be 825 considered with the same degree of authority as those within the 826 organization.) 828 Finally, care should be exercised with integer attributes of a sen- 829 sitive nature (particularly the uidNumber and gidNumber attributes) 830 which contain zero-length values. DUAs MAY treat such values as 831 corresponding to the "nobody" or "nogroup" user and group, respec- 832 tively. 834 8. Acknowledgements 836 Thanks to Bob Joslin of the Hewlett Packard Company, and to all 837 those that helped with this document's predecessor, RFC 2307. 839 UNIX is a registered trademark of The Open Group. 841 9. References 843 [RFC1057] 844 Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol 845 Specification Version 2", RFC 1057, June 1988. 847 [RFC1279] 848 S. Kille, "X.500 and Domains", RFC 1279, November 1991. 850 [RFC2373] 851 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 852 RFC 2373, July 1998. 854 [RFC2119] 855 S. Bradner, "Key Words for use in RFCs to Indicate Requirement 856 Levels", RFC 2119, March 1997. 858 [RFC2251] 859 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 860 Protocol (v3)", RFC 2251, December 1997. 862 [RFC2252] 863 M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Direc- 864 tory Access Protocol (v3): Attribute Syntax Definitions", RFC 865 2252, December 1997. 867 [RFC2254] 868 T. Howes, "The String Representation of LDAP Search Filters", 869 RFC 2254, December 1997. 871 [RFC2256] 872 M. Wahl, "A Summary of the X.500(96) User Schema for use with 873 LDAPv3", RFC 2256, December 1997. 875 [RFC3112] 876 K. Zeilenga, "LDAP Authentication Password Schema", RFC 3112, 877 May 2001. 879 [ROSE] 880 M. T. Rose, "The Little Black Book: Mail Bonding with OSI 881 Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc., 882 1992. 884 [X500] 885 "Information Processing Systems - Open Systems Interconnection 886 - The Directory: Overview of Concepts, Models and Service", 887 ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. 889 [XOPEN] 890 ISO/IEC 9945-1:1990, Information Technology - Portable Operat- 891 ing Systems Interface (POSIX) - Part 1: Systems Application 892 Programming Interface (API) [C Language] 894 [namedObject] 895 L. Howard, "A Structural Object Class for Arbitrary Auxiliary 896 Object Classes", INTERNET-DRAFT , July 2002. 899 10. Authors' Address 901 Luke Howard 902 PADL Software Pty. Ltd. 903 PO Box 59 904 Central Park, Vic 3145 905 Australia 906 EMail: lukeh@padl.com 908 Morteza Ansari 909 Infoblox Inc. 910 475 Potrero Avenue 911 Sunnyvale, CA 94085 912 USA 913 Phone: +1 408 716 4344 914 EMail: morteza@infoblox.com 916 A. Example entries 918 The examples described in this section are provided to illustrate 919 the schema described in this draft. They are not meant to be 920 exhaustive. 922 The following entry is an example of the posixAccount class: 924 dn: uid=lester,ou=people,dc=aja,dc=com 925 objectClass: top 926 objectClass: account 927 objectClass: posixAccount 928 uid: lester 929 cn: Lester the Nightfly 930 gecos: Lester 931 uidNumber: 10 932 gidNumber: 10 933 loginShell: /bin/csh 934 userPassword: {crypt}$X5/DBrWPOQQaI 935 homeDirectory: /home/lester 937 This corresponds the UNIX system password file entry: 939 lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh 941 The following entry is an example of the ipHost class: 943 dn: cn=josie.aja.com,ou=hosts,dc=aja,dc=com 944 objectClass: top 945 objectClass: device 946 objectClass: ipHost 947 objectClass: bootableDevice 948 objectClass: ieee802Device 949 cn: josie.aja.com 950 cn: www.aja.com 951 ipHostNumber: 10.0.0.1 952 macAddress: 00:00:92:90:ee:e2 953 bootFile: mach 954 bootParameter: root=dan.aja.com:/nfsroot/peg 955 bootParameter: swap=dan.aja.com:/nfsswap/peg 956 bootParameter: dump=dan.aja.com:/nfsdump/peg 958 This entry represents the host canonically josie.aja.com, also 959 known as www.aja.com. The Ethernet address and four boot parameters 960 are also specified. 962 An example of the nisNetgroup class: 964 dn: cn=nightfly,ou=netgroup,dc=aja,dc=com 965 objectClass: top 966 objectClass: nisNetgroup 967 cn: nightfly 968 nisNetgroupTriple: (charlemagne,peg,dunes.aja.com) 969 nisNetgroupTriple: (lester,-,) 970 memberNisNetgroup: kamakiriad 972 This entry represents the netgroup nightfly, which contains two 973 triples (the user charlemagne, the host peg, and the domain 974 dunes.aja.com; and, the user lester, no host, and any domain) and 975 one netgroup (kamakiriad). 977 Finally, an example of the nisObject class: 979 dn: nisMapName=tracks,dc=dunes,dc=aja,dc=com 980 objectClass: top 981 objectClass: nisMap 982 nisMapName: tracks 984 dn: cn=Maxine,nisMapName=tracks,dc=dunes,dc=aja,dc=com 985 objectClass: top 986 objectClass: nisObject 987 cn: Maxine 988 nisMapName: tracks 989 nisMapEntry: Nightfly$4 991 This entry represents the NIS map tracks, and a single map entry. 993 B. Affected library functions 995 The following functions are typically found in the C libraries of 996 most UNIX and POSIX compliant systems. An LDAP search filter 997 [RFC2254] which may be used to satisfy the function call is 998 included alongside each function name. Parameters are denoted by %s 999 and %d for string and integer arguments, respectively. Long lines 1000 are broken. 1002 getpwnam() (&(objectClass=posixAccount)(uid=%s)) 1003 getpwuid() (&(objectClass=posixAccount)(uidNumber=%d)) 1004 getpwent() (objectClass=posixAccount) 1005 getspnam() (&(objectClass=shadowAccount)(uid=%s)) 1006 getspent() (objectClass=shadowAccount) 1008 getgrnam() (&(objectClass=posixGroup)(cn=%s)) 1009 getgrgid() (&(objectClass=posixGroup)(gidNumber=%d)) 1010 getgrent() (objectClass=posixGroup) 1012 getservbyname() (&(objectClass=ipService)(cn=%s) 1013 (ipServiceProtocol=%s)) 1014 getservbyport() (&(objectClass=ipService)(ipServicePort=%d) 1015 (ipServiceProtocol=%s)) 1016 getservent() (objectClass=ipService) 1018 getrpcbyname() (&(objectClass=oncRpc)(cn=%s)) 1019 getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d)) 1020 getrpcent() (objectClass=oncRpc) 1022 getprotobyname() (&(objectClass=ipProtocol)(cn=%s)) 1023 getprotobynumber() (&(objectClass=ipProtocol)(ipProtocolNumber=%d)) 1024 getprotoent() (objectClass=ipProtocol) 1026 gethostbyname() (&(objectClass=ipHost)(cn=%s)) 1027 gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s)) 1028 gethostent() (objectClass=ipHost) 1030 getnetbyname() (&(objectClass=ipNetwork)(cn=%s)) 1031 getnetbyaddr() (&(objectClass=ipNetwork)(ipNetworkNumber=%s)) 1032 getnetent() (objectClass=ipNetwork) 1034 setnetgrent() (&(objectClass=nisNetgroup)(cn=%s)) 1035 getpublickey() (&(objectClass=nisKeyObject)(...)) 1037 C. Suggested DIT structure 1039 The cn attribute is typically used to name entities. The ipHostNum- 1040 ber, ipNetworkNumber, and ipServiceProtocol attributes are also 1041 naming attributes, such that multi-valued RDNs may be used to dis- 1042 tinguish between, for example, different interfaces of a multi- 1043 homed host. 1045 The following DIT structure MAY be used for deploying this schema. 1046 It is not required that DC-naming be used, but it is encouraged. 1048 Naming context ObjectClass 1049 ============================================================ 1050 ou=people,dc=... posixAccount 1051 shadowAcount 1052 ou=group,dc=... posixGroup 1053 ou=services,dc=... ipService 1054 ou=protocols,dc=... ipProtocol 1055 ou=rpc,dc=... oncRpc 1056 ou=hosts,dc=... ipHost 1057 ou=ethers,dc=... ieee802Device 1058 bootableDevice 1059 ou=networks,dc=... ipNetwork 1060 ou=netgroup,dc=... nisNetgroup 1061 nisMapName=...,dc=... nisObject 1062 automountMapName=...,dc=... automountMap 1064 Intellectual Property Rights 1066 The IETF takes no position regarding the validity or scope of any 1067 Intellectual Property Rights or other rights that might be claimed 1068 to pertain to the implementation or use of the technology described 1069 in this document or the extent to which any license under such 1070 rights might or might not be available; nor does it represent that 1071 it has made any independent effort to identify any such rights. 1072 Information on the procedures with respect to rights in RFC docu- 1073 ments can be found in BCP 78 and BCP 79. 1075 Copies of IPR disclosures made to the IETF Secretariat and any 1076 assurances of licenses to be made available, or the result of an 1077 attempt made to obtain a general license or permission for the use 1078 of such proprietary rights by implementers or users of this speci- 1079 fication can be obtained from the IETF on-line IPR repository at 1080 http://www.ietf.org/ipr. 1082 The IETF invites any interested party to bring to its attention any 1083 copyrights, patents or patent applications, or other proprietary 1084 rights that may cover technology that may be required to implement 1085 this standard. Please address the information to the IETF at ietf- 1086 ipr@ietf.org. 1088 Full Copyright Statement 1090 Copyright (C) The Internet Society (2005). This document is sub- 1091 ject to the rights, licenses and restrictions contained in BCP 78, 1092 and except as set forth therein, the authors retain all their 1093 rights. 1095 This document and the information contained herein are provided on 1096 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REP- 1097 RESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1098 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1099 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1100 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1101 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.