idnits 2.17.1 draft-provan-dhcp-options-dir-serv-01.txt: 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-25) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 74: '... database. Servers SHOULD be listed in...' RFC 2119 keyword, line 78: '..., and the length MUST be a multiple of...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (2 January 1998) is 9610 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) == Unused Reference: '2' is defined on line 132, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2044 (ref. '3') (Obsoleted by RFC 2279) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 don provan 2 INTERNET DRAFT Novell, Inc. 3 2 July 1997 4 Expires 2 January 1998 6 DHCP Options for Novell Directory Services 7 draft-provan-dhcp-options-dir-serv-01.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet 19 Drafts as reference material, or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts 24 Shadow Directories on ds.internic.net (US East Coast), 25 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 26 munnari.oz.au (Pacific Rim). 28 Abstract 30 This document defines three new DHCP options for delivering 31 configuration information to clients of the Novell Directory 32 Services. The first option carries a list of NDS servers. The 33 second option carries the name of the client's NDS tree. The third 34 carries the initial NDS context. These three options provide an NDS 35 client with enough information to connect to an NDS tree without 36 manual configuration of the client. 38 Changes 40 The original draft of this document called for transmitting NDS's 41 Unicode text as 16-bit characters in network byte order. The 42 current version of the document changes this to have Unicode text 43 transformed into octets using UTF-8. 45 1. Introduction 47 Novell Directory Services is a distributed, replicated, 48 hierarchical database of objects representing network resources 49 such as nodes, services, users, and applications. An NDS client 50 must be able to locate an NDS server in order to authenticate 51 itself to the network and gain access to the database. In addition, 52 the node's user is better served if the NDS client's attention is 53 focused on the area of the NDS database likely to be of the most 54 interest to the user. 56 This specification describes DHCP options [1] that carry NDS 57 information to TCP/IP clients of NDS. The first option, the NDS 58 Servers Option, carries a list of NDS servers. The other two 59 options, the NDS Tree Name Option and the NDS Context Option, 60 provide the client with a default context within the NDS database. 62 The NDS Tree Name Option and the NDS Context Option carry 16-bit 63 Unicode text encoded into an octet stream using UTF-8 [3]. A 64 complete DHCP implementation can represent of the entire Unicode 65 character set supported by NDS. At the same time, 7-bit ASCII text 66 is unchanged by the UTF-8 transformation. In environments where the 67 NDS tree name and context are restricted to the range of 7-bit 68 ASCII characters, ASCII-only DHCP clients and servers can support 69 these options by using the ASCII text as the UTF-8 encoded data. 71 2. NDS Servers Option 73 This option specifies one or more NDS servers for the client to 74 contact for access to the NDS database. Servers SHOULD be listed in 75 order of preference. 77 The code for this option is 85. The minimum length of this option 78 is 4 octets, and the length MUST be a multiple of 4. 80 Code Len Address 1 Address 2 81 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-- 82 | 85 | n | a1 | a2 | a3 | a4 | a1 | a2 | a3 | a4 | ... 83 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-- 85 3. NDS Tree Name Option 87 This option specifies the name of the NDS tree the client will be 88 contacting. NDS tree names are 16-bit Unicode strings. For 89 transmission in the NDS Tree Name Option, an NDS tree name is 90 transformed into octets using UTF-8. The string should NOT be zero 91 terminated. 93 The code for this option is 86. The maximum possible length for 94 this option is 255 bytes. 96 Code Len NDS Tree Name 97 +----+----+----+----+----+----+-- 98 | 86 | n | c1 | c2 | c3 | c4 | ... 99 +----+----+----+----+----+----+-- 101 4. NDS Context Option 103 This option specifies the initial NDS context the client should 104 use. NDS contexts are 16-bit Unicode strings. For transmission in 105 the NDS Context Option, an NDS context is transformed into octets 106 using UTF-8. The string should NOT be zero terminated. 108 A single DHCP option can only contain 255 octets. Since an NDS 109 context name can be longer than that, this option can appear more 110 than once in the DHCP packet. The contents of all NDS Context 111 options in the packet should be concatenated as suggested in the 112 DHCP specification [2, page 24] to get the complete NDS context. Be 113 aware that a single UTF-8 encoded character could be split between 114 two NDS Context Options. 116 The code for this option is 87. The maximum length for each 117 instance of this option is 255, but, as just described, the option 118 may appear more than once if the desired NDS context takes up more 119 than 255 octets. Implementations are discouraged from enforcing any 120 specific maximum to the final concatenated NDS context. 122 Code Len Initial NDS Context 123 +----+----+----+----+----+----+-- 124 | 87 | n | c1 | c2 | c3 | c4 | ... 125 +----+----+----+----+----+----+-- 127 References 129 [1] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 130 Extensions", RFC-2132, March 1997. 132 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, 133 March 1997. 135 [3] Yergeau, F., "UTF-8, a transformation format of Unicode and 136 ISO 10646", RFC-2044, October 1996 138 Author's Address 140 Don Provan 141 Novell, Inc. 142 2180 Fortune Drive 143 San Jose, California, 95131 145 Phone: +1 408 577 8440 147 EMail: donp@Novell.Com