idnits 2.17.1 draft-donelan-netmgt-guidelines-00.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 296 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) 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 (October 1996) is 10054 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: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT S. Donelan 2 DRA 3 October 1996 4 Expire in six months 6 Responsible Network Management Guidelines 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 This document provides Responsible Network Management personnel of 29 Internet Service Providers (ISPs) and Internet Service Customers 30 (ISCs) with guidelines for network management when the following 31 conditions arise: Routine Maintenance Activity, Problem Reporting 32 and Referral, Escalation, End-to-End Testing, Customer Notification, 33 Emergency Communications, Network Outage Measurement. 35 Specific procedures will require negotiations between the 36 organizations involved. These guidelines do not replace or supersede 37 contracts or any other legally binding documents. 39 Responsible Internet Service Provider 41 A more familar term in Internet Standards is an Autonomous System. 42 Since this document has additional requirements than an entity 43 represented by an Autonomous System or Systems, this document creates 44 a new entity. 46 The Responsible Internet Service Provider (RISP) has overall 47 responsibility for Internet service between its Internet Service 48 Customers and other Internet Service Providers making up the 49 Internet. 51 An Internet Network, Autonomous System or group of Autonomous Systems 52 may designate another entity to act on its behalf as its Responsible 53 Internet Service Provider. In this document, Internet Service 54 Customer (ISC) shall refer to the collective network, Autonomous 55 System or Systems which designated the Responsible Internet Service 56 Provider as their agent. 58 The Responsible Internet Service Provider is responsible for: 60 -- Providing a contact that is readily accessible 24 hours a day, 7 61 days a week. 63 -- Providing trained personnel. 65 -- Acting as the Internet Service Customer's primary contact in all 66 matters involving Internet Service between Internet Providers. 68 -- Accept problem reports from Internet Service Customers and casual 69 end users or other parties receiving Internet Service problem 70 reports. The RISP may prioritize problem reports from its own ISCs, 71 or refer casual end users to their primary RISP, if known. 72 Nevertheless the RISP should accept problem referrals from other 73 sources. 75 -- Advising the ISC when there is an ISP failure affecting the ISC 77 -- Isolating problems to determine if the reported trouble is in the 78 ISP's facilities or in other providers' service. 80 -- Testing cooperatively, when necessary, with other providers to 81 further identify a problem when it has been isolated to another 82 provider's service. 84 -- Keeping its Internet Service Customer advised of the status of the 85 trouble repair. 87 -- Maintaining complete and accurate records of its own customers and 88 inter-provider gateways. 90 Routine Maintenance Activity 92 Responsible Internet Service Providers should perform routine 93 maintenance work during hours of minimum traffic to impact the least 94 number of customers. In most areas, the period of lowest Internet 95 traffic is between Midnight and 6am local time. Trans-contential and 96 inter-contential connections should consider the local time on each 97 end of the connection. 99 Activities which may affect other Internet Service Providers should 100 be coordinated with the affected providers. 102 Problem Reporting and Referral 104 The Responsible Internet Service Provider is responsible for 105 performing all the necessary tests to determine the nature of the 106 problem detected, or reported by its customers or by referral from 107 other ISPs. If the trouble is isolated to an ISC or another ISP, the 108 RISP will report the trouble to the appropriate ISC or ISP point of 109 contact. 111 An example of the information exchanged in the problem report: 113 -- Description of the problem, and any other useful information such 114 as source and destination IP numbers, circuit numbers, etc. -- The 115 name and contact information of the person referring the problem -- 116 The date and time of the report -- Trouble ticket number and the name 117 or initials of the person accepting the report 119 Periodic status reports shall occur when the problem has been 120 isolated, when there is a significant change in the status of the 121 problem, and when negotiated time intervals expire. Escalation will 122 be according to negotiated procedures. 124 Problem isolation may require cooperative testing between the ISC and 125 ISP(s), which shall be provided when requested. The provider making 126 the test is responsible for coordination. 128 When the problem has been cleared, the ISP/ISP or ISP/ISC shall 129 advise the other the problem has been cleared. When closing a 130 problem report between ISP/ISP or ISP/ISC, the disposition should be 131 furnished by the organization closing the ticket. 133 An example of the information exchanged in the problem disposition: 135 -- Trouble ticket number -- Referral datetime -- Returned datetime -- 136 Trouble identified as -- Resolution details -- Service charges, if 137 the ticket resulted in a service charge 139 If there is a disagreement about the disposition of a problem ticket, 140 the parties involved should document their respective positions and 141 the names of the individuals involved. Escalation will be made 142 according to each organizations escalation procedures. 144 Escalation 146 Each ISP and ISC shall establish procedures for timely escalation of 147 problems to successive levels of management. The procedures should 148 include the provision of status reports to the other provider or 149 customer regarding the ticket status. Both technical and management 150 contacts should be included in the escalation procedures. 152 End-to-End Testing 154 Networks may experience problems which cannot be isolated by each 155 provider individually testing and maintaining its own services. Each 156 providers' service may appear to perform correctly, but trouble 157 appears on an end-to-end service. The ISC's RISP should coordinate 158 end-to-end testing with each sectional provider by problem referral 159 through their Responsible Internet Service Provider. Each Internet 160 Service Provider should accept the referral request for end-to-end 161 testing coordination, and provide the contact information for the 162 next sectional provider to the original requestor. 164 Customer Notification 166 During a major outage a potential concern is customer goodwill and 167 network congestion caused by repeated customer attempts to access the 168 down network. An informed customer can reduce customer frustration, 169 and network congestion. 171 Pre-planning for quick notification can be most beneficial in 172 alerting customers. 174 Some example methods to notify customers include: 176 -- If operational, network access equipment can display an alert when 177 customers connect. The alert should be displayed before the customer 178 logs into the network. If the network fails during or after 179 attempting to validate the access information, the alert should not 180 compromise any authentication done. 182 -- Customer service calls increase dramatically during network 183 failures. An informed customer representative can advise the 184 customer on the best course of action. A method to quickly instruct 185 customer service representatives on the options available is needed. 187 -- The media, radio or television, can be used to inform the public. 188 Pre-arrangements, and planning are needed to ensure only designated 189 contacts are made with the media. 191 -- Other automated announcements, such as World Wide Web pages or e- 192 mail distribution lists with backup through other providers, recorded 193 telephone status lines, or broadcast FAX notifications. 195 Public notifications, when utilized, should not make reference by 196 name to a problem causing network or organization unless the network 197 causing the problem has been identified. Internet network troubles 198 can be difficult to isolate, and can give misleading indications to 199 their true origin. 201 Emergency Communications 203 Recognizing that all Responsible Internet Service Providers have a 204 responsibility to provide an adequate level of support for their 205 service and/or products, it is recommended they participate in an 206 emergency communications system. 208 Each RISP is responsible for providing a Emergency Point Of Contact. 209 It is recommended each Emergency POC have at least one out-of-band 210 contact method, such as an internationally dialable (non 800) voice 211 and/or fax telephone number. Each RISP shall update the Emergency 212 POC information whenever it changes. Each RISP shall test and verify 213 its own emergency POC procedures are accurate and functioning on a 214 regular basis, no less than once a year. 216 Network Outage Measurement 218 Each ISP/ISC should maintain accurate records about network outages 219 to measure, analyze and develop trend analysis of their network 220 outages. 222 Security Considerations 224 Security relevant information may be reported via a wide variety of 225 contacts with the ISP, calls to the NOC, calls to customer service, 226 and even calls to the provider's general business office. Each 227 responsible Internet service provider is responsible for training all 228 its personnel on its internal guidelines for reporting security 229 relevant information to its security point of contact. 231 Emergency points of contact should exchange procedures to verify each 232 other's identity which don't depend on access to the Internet. 234 Author's Address 236 Sean Donelan 237 Data Research Associates, Inc. 238 1276 North Warson Road 239 Saint Louis, MO 63132 241 Phone: +1-314-432-1100 242 EMail: sean@DRA.COM