idnits 2.17.1 draft-irtf-nmrg-snmp-tcp-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. == 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 106 has weird spacing: '... octets cont...' == Line 191 has weird spacing: '...for the purpo...' -- 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 (23 March 1999) is 9159 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: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder, Editor 3 Internet-Draft TU Braunschweig 4 Expires September 1999 23 March 1999 6 SNMP over TCP Transport Mapping 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 RFC 2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 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 any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Distribution of this document is unlimited. Please send comments to 30 the Network Management Research Group, . 32 Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 Abstract 38 This memo defines a transport mapping for using the Simple Network 39 Management Protocol (SNMP) over TCP. The transport mapping defined in 40 this memo can be used with any version of SNMP. 42 Table of Contents 44 1 Introduction ................................................. 3 45 2 Definitions .................................................. 3 46 3 SNMP over TCP ................................................ 4 47 3.1 Serialization .............................................. 4 48 3.2 Well-known Values .......................................... 4 49 3.3 Connection Management ...................................... 5 50 4 Acknowledgments .............................................. 5 51 5 Editor's Address ............................................. 5 52 6 Full Copyright Statement ..................................... 6 54 1. Introduction 56 This memo defines a transport mapping for using the Simple Network 57 Management Protocol (SNMP) over TCP. The transport mapping defined in 58 this memo can be used with any version of SNMP. This document extends 59 the transport mappings defined in RFC 1906. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119. 65 2. Definitions 67 IRTF-NMRG-SNMP-TM DEFINITIONS ::= BEGIN 69 IMPORTS 70 MODULE-IDENTITY, OBJECT-IDENTITY, experimental 71 FROM SNMPv2-SMI 72 TEXTUAL-CONVENTION 73 FROM SNMPv2-TC; 75 nmrgSnmpDomains MODULE-IDENTITY 76 LAST-UPDATED "9903231800Z" 77 ORGANIZATION "IRTF Network Management Research Group" 78 CONTACT-INFO 79 "Juergen Schoenwaelder 80 TU Braunschweig 81 Bueltenweg 74/75 82 38106 Braunschweig 83 Germany 84 Tel: +49 531 391-3283 85 E-mail: schoenw@ibr.cs.tu-bs.de" 86 DESCRIPTION 87 "This MIB module defines the SNMP over TCP transport mapping." 88 ::= { experimental nmrg(xxxx) 1 } 90 -- SNMP over TCP over IPv4 92 snmpTCPDomain OBJECT-IDENTITY 93 STATUS current 94 DESCRIPTION 95 "The SNMP over TCP/IPv4 transport domain. The corresponding 96 transport address is of type SnmpTCPAddress." 97 ::= { nmrgSnmpDomains 6 } -- matches first unused value 98 -- below snmpDomains 100 SnmpTCPAddress ::= TEXTUAL-CONVENTION 101 DISPLAY-HINT "1d.1d.1d.1d/2d" 102 STATUS current 103 DESCRIPTION 104 "Represents a TCP/IPv4 address: 106 octets contents encoding 107 1-4 IP-address network-byte order 108 5-6 TCP-port network-byte order 109 " 110 SYNTAX OCTET STRING (SIZE (6)) 111 END 113 3. SNMP over TCP 115 This is an optional transport mapping. However, implementors are 116 encouraged to support SNMP over TCP whenever possible because this 117 enables applications to use more efficient MIB data transfers. 119 3.1. Serialization 121 Each instance of a message is serialized into a single BER encoded 122 message, using the algorithm specified in Section 8 of RFC 1906. The 123 BER encoded message is then send over a TCP connection. 125 Note, it is possible to exchange multiple SNMP request/response pairs 126 over a single TCP connection. The length field in the BER encoded 127 SNMP message is used to separate multiple requests send over a single 128 TCP connection. 130 3.2. Well-known Values 132 It is suggested that administrators configure their SNMP entities 133 acting in an agent role to listen on TCP port 161 for incoming 134 connections. Further, it is suggested that notification sinks be 135 configured to listen on TCP port 162. 137 When an SNMP entity uses this transport mapping, it must be capable 138 of accepting messages that are at least 484 octets in size. 139 Implementation of larger values is encouraged whenever possible. 141 3.3. Connection Management 143 The use of TCP connections introduces costs. Connection establishment 144 and shutdown causes additional traffic on the wire. Further, 145 maintaining open connections binds resources in the network layer of 146 the underlying operating system. 148 TCP connections should therefore only be used when the size of the 149 data transferred would otherwise cause large latencies due to small 150 UDP packet sizes and an increased number of interactions. 152 Both, an SNMP entity in the agent role and an SNMP entity in the 153 manager role, are allowed to close the connections at any point in 154 time. This ensures that SNMP entities can control their resource 155 usage and shutdown TCP connections that are not used. Note, SNMP 156 engines are not expected to process any outstanding requests if the 157 underlying TCP connection has been closed. A no response error 158 condition SHOULD be signalled for outstanding requests for command 159 generator applications if the TCP connection is closed. 161 4. Acknowledgments 163 The definitions in this memo are inspired by definitions found in RFC 164 1906. This document is the result of the Network Management Research 165 Group (NMRG). Special thanks go to the following participants for 166 their comments and contributions: 168 Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras, Ron Sprenkels, 169 Bert Wijnen 171 5. Editor's Address 173 Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de 174 TU Braunschweig Tel: +49 531 391-3283 175 Bueltenweg 74/75 176 38106 Braunschweig 177 Germany 179 6. Full Copyright Statement 181 Copyright (C) The Internet Society (1998). All Rights Reserved. 183 This document and translations of it may be copied and furnished to 184 others, and derivative works that comment on or otherwise explain it 185 or assist in its implementation may be prepared, copied, published 186 and distributed, in whole or in part, without restriction of any 187 kind, provided that the above copyright notice and this paragraph are 188 included on all such copies and derivative works. However, this 189 document itself may not be modified in any way, such as by removing 190 the copyright notice or references to the Internet Society or other 191 Internet organizations, except as needed for the purpose of 192 developing Internet standards in which case the procedures for 193 copyrights defined in the Internet Standards process must be 194 followed, or as required to translate it into languages other than 195 English. 197 The limited permissions granted above are perpetual and will not be 198 revoked by the Internet Society or its successors or assigns. 200 This document and the information contained herein is provided on an 201 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 202 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 203 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 204 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 205 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.