idnits 2.17.1 draft-mellquist-web-sys-00.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-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 an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (June 13, 1996) is 10178 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? '3' on line 351 looks like a reference -- Missing reference section? '1' on line 343 looks like a reference -- Missing reference section? '4' on line 355 looks like a reference -- Missing reference section? '2' on line 346 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Web Based Management June 13, 1996 3 Web Based System and Network Management 5 7 Brian Harrison 8 Hewlett-Packard Company 9 harrison@ppg01.sc.hp.com 11 Peter E. Mellquist 12 Hewlett-Packard Company 13 mellqust@hprnd.rose.hp.com 15 Adrian Pell 16 Hewlett-Packard Company 17 arp@hplb.hpl.hp.com 19 June, 13 1996 21 Status of this Memo 23 This document is an Internet-Draft. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its 25 areas, and its working groups. Note that other groups may also 26 distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as 32 ``work in progress.'' 34 To learn the current status of any Internet-Draft, please check 35 the ``1id-abstracts.txt'' listing contained in the Internet- 36 Drafts Shadow Directories on ftp.is.co.za (Africa), 37 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 38 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 40 1. Abstract 42 This document describes the application of the Hyper Text 43 Transfer Protocol (HTTP) for system and network management. 44 Presented are mechanisms which facilitate system and network 45 management including the discovery of HTTP management entities, 46 how management content may be accessed, and lastly, the role of 47 a Simple Network Management Protocol (SNMP) agent providing 48 SNMP information through the use of HTTP. 50 Management and HTTP may be categorized into two groups, the 51 management of HTTP[3] and management using HTTP. The focus of 52 this document is on the latter, "web based management". 54 2. Overview 56 Web based management is the application of World Wide Web (WWW) 57 tools for the management of systems and networks. This includes 58 using HTTP servers and browsers for providing static, dynamic and 59 interactive content of management information. An HTTP server 60 acting in a management role can provide information in a variety 61 of forms including Hyper Text Markup Language (HTML), graphics, 62 executable code and binary encoded information. Together, this 63 capability allows HTTP to function as a powerful protocol for 64 the management of systems and networks. For HTTP servers acting 65 in a management role, the HTTP server may also be providing non- 66 management content. It is therefore necessary to provide a mechanism 67 for a WWW browser or network management application to have direct 68 access to the management information. 70 As presented in this document, HTTP is not meant to replace SNMP. 71 HTTP working together with SNMP can provide many benefits including 72 ease-of-use, zero client-side installation, and security. SNMP 73 is required for the instrumentation of systems and networks. 75 3. HTTP Management Transport Control Protocol (TCP) Port Definition 77 The standardized TCP port for HTTP is port 80 [1]. A HTTP server 78 listening on this port may provide content spanning a wide 79 information base including non-management related content. 80 For management usage, this requires that the management content 81 be inter-mixed with non-management content. A WWW browser or 82 network management application must therefore have knowledge or 83 the ability to determine where the management content resides on 84 a HTTP server. A well known HTTP management TCP port solves this 85 problem by allowing only management content through the HTTP 86 management interface. This allows a browser or network management 87 application to easily use or discover a HTTP server acting in a 88 management role. The proposed HTTP management TCP port is 89 port 280 (The actual port number is pending IANA[4] approval). The 90 recommended port for management is therefore port 280. In cases 91 where this port is not available, port 80 may be used. An 92 alternative to a standardized HTTP management port, a standardized 93 Universal Request Indicator (URI), was considered. Although this 94 mechanism could work, it was decided that the problems of 95 attempting to standardize on a character sequence would prove to 96 be too difficult. 98 A HTTP server operating in a management mode on port 280 may 99 also be using port 80 for non-management content. This allows 100 for the clean separation of management and non-management 101 content. A TCP port 280 interface should only supply management 102 content. A HTTP server which does not utilize TCP port 280 for 103 management content may inter-mix management and non-management 104 content on port 80. In this case, a browser or network management 105 application must determine the HTTP management capability through 106 other means, see HTTP Manageable MIB. 108 4. HTTP Manageable MIB 110 A SNMP agent in operation together with an HTTP server allows 111 management information to be accessed using either the SNMP 112 protocol or using HTTP. In order to determine if an SNMP agent 113 also supports HTTP, a SNMP Management Information Base (MIB) is 114 utilized. The "HTTP Manageable MIB" provides SNMP objects which 115 advertise an agent's HTTP capabilities. This allows a network 116 management application using SNMP to query the "HTTP Manageable 117 MIB" to determine its HTTP management capabilities and interface. 118 The presence of this MIB in an agent implies that a HTTP server is 119 operational in a management context. In order to determine the 120 exact interface for HTTP access, the "HTTP Manageable MIB" provides 121 a MIB object, "httpMgDefaultURL". This object represents the 122 complete Universal Request Locator (URL) for management access to 123 the agent via HTTP. The value of this URL will reflect port 280 124 usage when applicable. 126 A second MIB object defines an agent's capability to perform SNMP 127 over HTTP. The "httpMgSNMPEnabled" object represents a truth 128 value indicating if the HTTP server can perform SNMP over HTTP. 129 If set true, the HTTP server supports the SNMP over HTTP tunneling 130 protocol as described in the subsequent section. 132 Below is the MIB definition for the "HTTP Manageable MIB". Note, the 133 MIB is currently designed to reside under the Hewlett-Packard MIB 134 branch. The long term intent will be to move this MIB under a 135 standard branch (The actual MIB branch is pending IANA[4] approval). 137 HP-httpManageable-MIB DEFINITIONS ::= BEGIN 139 IMPORTS 140 OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE 141 FROM SNMPv2-SMI 142 DisplayString, TruthValue 143 FROM SNMPv2-TC 144 OBJECT-GROUP, MODULE-COMPLIANCE 145 FROM SNMPv2-CONF; 147 hp OBJECT IDENTIFIER ::= { enterprises 11 } 148 nm OBJECT IDENTIFIER ::= { hp 2 } 149 hpWebMgmt OBJECT IDENTIFIER ::= { nm 36 } 151 httpMgMod MODULE-IDENTITY 152 LAST-UPDATED "9606120000Z" 153 ORGANIZATION "Hewlett-Packard Web-based Management Working Group" 154 CONTACT-INFO 155 "WG E-mail: webmgmt@sysman.hpl.hp.com 156 Chair: Brian Harrison 157 Postal: Hewlett-Packard 158 5301 Stevens Creek Blvd 159 Santa Clara CA 95052 USA 160 Tel: +1-408-553-3786 161 Fax: +1-408-553-2909 162 E-mail: harrison@ppg01.sc.hp.com" 164 DESCRIPTION 165 "Management information for HTTP manageable devices. 166 This MIB gives SNMP systems information on how to 167 manage a device using HTTP." 168 REVISION "9606120000Z" 169 DESCRIPTION "Initial Version" 171 ::= { hpWebMgmt 1 } 173 httpMgTraps OBJECT IDENTIFIER ::= { httpMgMod 0 } -- future 174 httpMgObjects OBJECT IDENTIFIER ::= { httpMgMod 1 } 175 httpMgGroups OBJECT IDENTIFIER ::= { httpMgMod 2 } 176 httpMgCompliances OBJECT IDENTIFIER ::= { httpMgMod 3 } 178 -- MIB Objects 179 -- Default attributes for managing via HTTP 180 httpMgDefaults OBJECT IDENTIFIER ::= { httpMgObjects 1 } 182 httpMgDefaultURL OBJECT-TYPE 183 SYNTAX DisplayString 184 MAX-ACCESS read-write 185 STATUS current 186 DESCRIPTION 187 "A Uniform Resource Locator (URL), as defined in RFC1738, 188 for the default management information for this device. 189 This URL is typically used by a HTTP browser to display 190 management information for this device. This default 191 page should contain links to any other management 192 pages for this device." 193 ::= { httpMgDefaults 1} 195 httpMgSNMPEnabled OBJECT-TYPE 196 SYNTAX TruthValue 197 MAX-ACCESS read-write 198 STATUS current 199 DESCRIPTION 200 "Indicates whether a HTTP server supports SNMP 201 over HTTP where SNMP requests may be contained 202 in the Entity-Body of a HTTP POST operation" 203 ::= { httpMgDefaults 2 } 205 -- Compliance statements 207 httpMgMinCompliance MODULE-COMPLIANCE 208 STATUS current 209 DESCRIPTION 210 "The compliance statement for SNMP entities which 211 are http manageable." 213 MODULE -- this module 214 MANDATORY-GROUPS { httpMgDefaultGroup } 216 ::= { httpMgCompliances 1 } 218 httpMgDefaultGroup OBJECT-GROUP 219 OBJECTS { httpMgDefaultURL, httpMgSNMPEnabled } 220 STATUS current 221 DESCRIPTION 222 "The objects providing information applicable to all 223 http manageable systems" 224 ::= { httpMgGroups 1 } 226 END 228 5. SNMP over HTTP 230 A HTTP server acting in a management role may provide a variety of 231 content including HTML, graphics, executable code and binary data. 232 SNMP Protocol Data Units (PDUs) may be transmitted over HTTP in the 233 following manner as "application/octet-stream" Content-Type data. 235 As described in the "HTTP Manageable MIB", the "httpMgSNMPEnabled" 236 MIB object determines if a SNMP / HTTP agent can support SNMP over 237 HTTP. If this object is set true, SNMP / HTTP tunneling is 238 supported. The URL used for this capability is the one defined 239 in the "httpMgDefaultURL" MIB object. This URL will include port 240 280 reference when appropriate. 242 Once a HTTP server has been determined to support SNMP over HTTP, 243 SNMP requests may be made by encapsulating the encoded PDU in a 244 HTTP request entity body [1]. 246 Web Based Managed Entity 247 ------------------------------------------ 248 | ----------- ---------- | 249 | | SNMP | SNMP | HTTP | | 250 | | Agent |<============>| Server | | 251 | | | | | | 252 | | | | | | 253 | --|-----|--- --|----|-- | 254 -----|-----|--------------------|----|---- 255 Port 161 | | | | Port 80 256 --<--->-- | | -<----->-- SNMP/HTTP 257 Port 162 | | Port 280 258 ------>-------- ------<----->-- SNMP/HTTP 260 The Backus Naur Form (BNF) for a HTTP 1.0 compliant request is as 261 follows. Please refer to the HTTP 1.0 specification for more 262 details on HTTP [1]. 264 Full-Request = Request-Line 265 *( General-Header 266 | Request-Header 267 | Entity-Header ) CRLF 268 [ Entity-Body ] 270 Entity-Header fields define optional metainformation about the 271 Entity-Body or, if no body is present, about the resource 272 identified by the request. For SNMP / HTTP tunneling, the Entity- 273 Header and Entity-Body fields are utilized. 275 Entity-Header = Allow 276 | Content-Encoding 277 | Content-Length 278 | Content-Type 279 | Expires 280 | Last-Modified 281 | extension-header 283 For the transfer of a SNMP encoded PDU, the "Content-Type" and 284 "Content-Length" specifiers are required. HTTP uses Internet 285 Media Types for the Content-Type found in the Entity-Header 286 field [4].The Content-Type Entity-Header field indicates the 287 media type of the Entity-Body. The PDU is treated as 288 media-type "application/octet-stream". The "Content-Length" 289 value is the length, in octets, of the encoded PDU. 291 SNMP over HTTP is defined for SNMP get, set, get-next, get-bulk 292 and inform operations. When making making SNMP requests over 293 HTTP, the PDU type is encoded within the request PDU. The HTTP 294 POST operation is utilized for all SNMP operations. The POST 295 operation allows sending the enclosed Entity-Body to the 296 specified URL. Applications such as WWW browsers do not cache 297 HTTP POST requests. This allows all transactions to go on the 298 wire. 300 To differentiate a SNMP / HTTP management request from other 301 HTTP management requests, a standard URI, "snmp-request" is 302 utilized. This URI is used for all SNMP get, set, next, bulk 303 and inform PDUs since the PDU type is encoded within the PDU. 305 Example of SNMP get over HTTP. Assume we have an encoded SNMP get 306 PDU of 275 bytes in length. 308 POST /snmp-request HTTP/1.0 309 Content-Type: application/octet-stream 310 Content-Length: 275 311 [ 275 bytes of PDU ] 313 Returned will be the HTTP response with the PDU response found in 314 the Entity-Body. 316 HTTP/1.0 20 OK 317 Content-Type: application/octet-stream 318 Content-Length: 275 319 [ 275 bytes of PDU] 321 SNMP get-next, set, get-bulk and inform SNMP operations work in a 322 similar manner. 324 It should be mentioned that SNMP over HTTP is accomplished without 325 the introduction of yet-another-management protocol. Instead, HTTP 326 can be used to transfer information between a managed entity and WWW 327 browser or network management application. In doing so, HTTP has the 328 potential of offering many benefits including secure transfer of 329 information. 331 6. Conclusion 333 The utilization of web based system and network management offers 334 much potential. Without proper standardization, this new form of 335 management will not provide an open systems solution for the 336 management of heterogenous multi-vendor environments. In intent 337 of this Internet Draft is to offer areas of standardization for 338 web based management and in doing so seek a single unified 339 approach. 341 7. References: 343 [1] T. Berners-Lee, R. Fielding,H. Frystyk, "Hypertext Transfer Protocol 344 HTTP/1.0" RFC 1945, MIT/LCS, UC Irvine, May 1996. 346 [2] McCloghrie, K., and M. Rose, Editors, "Management Information 347 Base for Network Management of TCP/IP-based internets: MIB- 348 II", STD 17, RFC 1213, Hughes LAN Systems, Performance 349 Systems International, March 1991. 351 [3] Hazewinkel, H., E. van Hengstum, A. Pras, "Definitions of Managed 352 Objects for HTTP", draft-hazewinkel-httpmib-00.txt, University of 353 Twente, April 1996 355 [4] J. Postel. "Assigned Numbers", STD 2, RFC 1700, USC/ISI, 356 October 1994. 358 8. Acknowledgments 360 This document was produced as a result of the Hewlett-Packard 361 Web-based Management Working Group and the effort of its 362 participants. 364 The authors gratefully acknowledges the work and comments of 365 the following individuals: 367 Steve Gase,GASE_STEVE/HP-Boise_unixgw1@hpflash 368 Hewlett-Packard Company 370 Jean-Jacques Moreau, jjm@hplb.hpl.hp.com 371 Hewlett-Packard Company 373 Jeff Morgan, morgan@hpl.hp.com 374 Hewlett-Packard Company 376 Brian O'Keefe, bok@nsmdserv.cnd.hp.com 377 Hewlett-Packard Company 379 Jitendra Singh,SINGH_JITENDRA/hp-santaclara_om3@hpflash 380 Hewlett-Packard Company