idnits 2.17.1 draft-ietf-dhc-callcontrolserv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (August 25, 1999) is 9010 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Henry Houh 3 INTERNET DRAFT NBX Corporation 4 February 25, 1999 5 Expires August 25, 1999 7 DHCP Options for Call Control Servers 8 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), 15 its areas, and its working groups. Note that other groups may also 16 distribute working documents 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 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 26 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 29 This document is a submission to the Dynamic Host Configuration 30 Working Group of the Internet Engineering Task Force (IETF). Comments 31 should be submitted to the dhcp-v4@bucknell.edu mailing list. 33 Distribution of this memo is unlimited. 35 Abstract 37 This document defines a new DHCP option for delivering configuration 38 information to telephony enabled hosts in order to locate a call 39 control/signalling server. The option carries several operational 40 parameters that allow multiple call control vendors to utilize this 41 field. 43 1. Introduction 45 Telephony is emerging as a network-based application. The Call 46 Control Server option allows telephony or gateway devices which 47 cannot independently setup up and signal calls to automatically 48 discover an address of a call control server. 50 This specification describes a DHCP option [1] that can carry one or 51 several Call Control Server sub-options. Each sub-option is 52 treated as a separate potential call control server by the hosts. 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119. [2] 58 2. Call Control Server Option 60 This option specifies one or more fields carrying Call Control 61 Server information. The fields that can be carried by this option 62 are described in the sections that follow. 64 The code for this option is TBD, and its maximum length is 255 octets. 66 Code Len Sub-Option 1 Sub-Option 2 67 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-- 68 | TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | a3 | a4 | ... 69 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-- 71 The 'Len' field specifies the number of octets containing sub-option 72 information within the DHCP option. 74 Each sub-option will contain a code followed by a length that 75 specifies the number of octets containing configuration parameter 76 information within the sub-option. 78 Sub Sub 79 Code Len Configuration Parameter(s) 80 +-----+-----+-----+-----+-----+-----+-----+-----+-- 81 | x | n | a1 | a2 | a3 | a4 | a6 | a7 | ... 82 +-----+-----+-----+-----+-----+-----+-----+-----+-- 84 2.1. Call Control Servers 86 This section describes the vendor-specific sub-options. 88 Other types/vendors of call control servers can be added by using 89 new sub-option fields. See section 2.2 for the procedure for 90 adding sub-option fields. 92 2.1.1 NBX Call Control Server Sub-option 94 This sub-option specifies the network address of an NBX Call 95 Control Server. 97 The code for this sub-option is 1. The length specified in the 'Len' 98 field of this sub-option MUST always be 4 octets. 100 Code Len NBX Server Address 101 +-----+-----+-----+-----+-----+-----+ 102 | 1 | 4 | a1 | a2 | a3 | a4 | 103 +-----+-----+-----+-----+-----+-----+ 105 2.1.2 3Com Call Control Server 107 This sub-option specifies the network address of a 3Com Call 108 Control Server. 110 The code for this sub-option is 2. The length specified in the 'Len' 111 field of this sub-option MUST always be 4 octets. 113 Code Len 3Com Server Address 114 +-----+-----+-----+-----+-----+-----+ 115 | 2 | 4 | a1 | a2 | a3 | a4 | 116 +-----+-----+-----+-----+-----+-----+ 118 2.1.3 MEGACO MGC 120 This sub-option specifies the network address of a MEGACO Media 121 Gateway Controller. 123 The code for this sub-option is 3. The length specified in the 'Len' 124 field of this sub-option MUST always be 4 octets. 126 Code Len MEGACO MGC Address 127 +-----+-----+-----+-----+-----+-----+ 128 | 3 | 4 | a1 | a2 | a3 | a4 | 129 +-----+-----+-----+-----+-----+-----+ 131 2.2 Procedure for adding call control server types 133 A vendor may add a new sub-option field by issuing an internet 134 draft that contains the new sub-option. The new sub-option field 135 code MUST be labeled "TBD." This draft will then be submitted to 136 the DHC working group, and, if accepted for inclusion in the DHCP 137 specification, a sub-option field code is assigned and the 138 sub-option specification is published as an RFC which updates this 139 RFC. 141 3. Using Multiple Sub-options 143 More than one sub-option field MAY be returned to the host. 144 In addition, more than one of any sub-option type MAY be present. 145 This allows the host to select the call control server appropriate 146 to own its signaling protocol, allowing a single DHCP server to 147 support multiple homogeneous call control servers as well as 148 heterogeneous telephony and gateway devices. 150 4. References 152 [1] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 153 Extensions", RFC-2132, March 1997. 155 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 156 Levels", RFC-2119, March 1997. 158 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, 159 March 1997. 161 5. Security Considerations 163 DHCP currently provides no authentication or security mechanisms. 164 Potential exposures to attack are discussed in section 7 of the DHCP 165 protocol specification [3]. In particular, these DHCP options allow 166 an unauthorized DHCP server to misdirect a telephone or gateway 167 host to an unauthorized call control server. 169 6. Author's Address 171 Henry Houh 172 NBX Corporation 173 100 Brickstone Square 174 Andover, MA 01810 176 Phone: +1 978 740 0000 x257 178 EMail: hhouh@nbxcorp.com