Responsible Network Management Guidelines

I've been reminded I was going to update my draft of Responsible
Network Management Guidelines. The latest version is available

In addition to any substantive comments, now is the time to correct
the grammer and spelling nits. I plan on throwing this into the
Informational RFC process before the next IETF meeting.

In addition to any substantive comments, now is the time to correct
the grammer and spelling nits. I plan on throwing this into the
Informational RFC process before the next IETF meeting.

Here goes. Didn't realize it was that small...

(Warning: I got about halfway through, and realized I was editing, rather
than just copyediting -- feel free to ignore those parts if you see fit.)

Operational Requirements Area S. Donelan
<draft-donelan-rnmg-01.txt> September 1997

               Responsible Network Management Guidelines

Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet- Drafts as reference


   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts


   Shadow Directories on (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).

Rational and Scope


   This document provides Responsible Network Management personnel of

All three of those words likely should not be capitalized; you're using
the term generically, not as a job title.

   Internet Service Providers (ISPs) and Internet Service Customers

I know you had to make _something_ up to call them there... but I always
have a vague, unallocated unease about new initialisms. Might you just say
"their customers"?

   (ISCs) with guidelines for network management when the following
   conditions arise:

       - Routine Maintenance Activity
       - Problem Reporting and Referral
       - Escalation
       - End-to-End Testing
       - Customer Notification
       - Emergency Communications
       - Network Service Interuption Measurement

   Specific procedures will require negotiations between the
   organizations involved. These guidelines do not replace or supersede

"are not intended to"?

   agreements or any other legally binding documents.

Responsible Internet Service Provider

   A more familar term in Internet Standards is an Autonomous System.
   Since this document has additional requirements than an entity
   represented by an Autonomous System or Systems, this document creates a
   new entity.

"has...than" is a clumsy construct at best. Are you trying to say

Since this document defines requirements additional to those customarily
expected of the operators of an Autonomous System, it must define a new
entity, encompassing AS's and also other organizations.


   The Responsible Internet Service Provider (RISP) has overall
   responsibility for Internet service between its Internet Service
   Customers and other Internet Service Providers making up the

Ok, so, basically, a RISP is a repository for a contact?

   An Internet Network, Autonomous System or group of Autonomous Systems
   may designate another entity to act on its behalf as its Responsible
   Internet Service Provider. In this document, Internet Service
   Customer (ISC) shall refer to the collective network, Autonomous
   System or Systems which designated the Responsible Internet Service
   Provider as their agent.

Roughly. An agent, in legal terms.

   The Responsible Internet Service Provider is responsible for:

   -- Providing a contact that is readily accessible 24 hours a day, 7
   days a week.

   -- Providing trained personnel.

   -- Acting as the Internet Service Customer's (ISC) primary contact in
   all matters involving Internet Service between Internet Providers.

   -- Accept problem reports from Internet Service Customers and casual


   end users or other parties receiving Internet Service problem
   reports. The RISP may prioritize problem reports from its own ISCs,
   or refer casual end users to their primary RISP, if known.

This graf sounds like it's making an assumption that _I_, at least,
apparently am not equipped to make, as I fell off a couple turns back.

The first sentence could use to be recast.

   -- Advising the ISC when there is an ISP failure affecting the ISC

   -- Isolating problems to determine if the reported trouble is in the
   ISP's facilities or in other providers' service.

   -- Testing cooperatively, when necessary, with other providers to
   further identify a problem when it has been isolated to another
   provider's service.

Suggest moving the parenthetical after "providers".

   -- Keeping its ISC advised of the status of the trouble repair.

   -- Maintaining complete and accurate records of its own customers and

So, basically, a RISC is an administrative and technical Point of Contact

Routine Maintenance Activity

   Responsible Internet Service Providers should perform routine
   maintenance work during hours of minimum traffic to impact the least
   number of customers. In most areas, the period of lowest Internet
   traffic is between 1am and 6am local time. Trans-contential and
   inter-contential connections should consider the local time on each
   end of the connection.

It's worthy of note (it was in one of the last 4 RISKS Digests) that, for
some things -- backbone gear, NAP's, webfarms, etc -- there _is_ _no_
good time to do maintenance. The audience is world wide and,
statistically, you simply can't find a good hour to do it. It might be
suggested that each category of operators ought to keep their own
traffic logs, to roughly hourly granularity, maybe, to facilitate the
determination of "the best time to down the router".

   Activities which may affect other Internet Service Providers should
   be coordinated with the affected providers.

Channels should be designed in advance for this sort of communication
(email, voice, pager, etc.), and tested regularly?

Problem Reporting and Referral

   The Responsible Internet Service Provider is responsible for
   performing all the necessary tests to determine the nature of the
   problem detected, or reported by its customers or by referral from
   other ISPs. If the trouble is isolated to an ISC or another ISP, the
   RISP will report the trouble to the appropriate ISC or ISP point of

   An example of the information exchanged in the problem referral

   -- Description of the problem, including source address/name,
   destination address/name, application or protocol involved, when it
   last worked, when it stopped working, and any diagnostic messages or
   test data (i.e. ping, traceroute).

   -- Customer reported problem severity

   -- RISP determination of problem severity

   -- The name and contact information of the person referring the

   -- The referee's trouble ticket number, and origination date/time

   -- The name of the person accepting the report

   -- The acceptor's trouble ticket number, and acceptance data/time

Oh, _ghod_ if we could design a standardized trouble ticket interchange
format. Excuse me, I feel an RFC coming on. :slight_smile:

   Periodic status reports shall occur when the problem has been
   isolated, when there is a significant change in the status of the
   problem, and when negotiated time intervals expire. Escalation will
   be according to negotiated procedures.

And prior negotiation should probably take place to decide on
equivalencies of severity levels and escalation justifications, etc.

Sorry; I'm a systems designer by trade; the stuff just runs out of my
fingertips. :slight_smile:

   Problem isolation may require cooperative testing between the ISC and
   ISP(s), which shall be provided when requested. The provider making
   the test is responsible for coordination.

   When the problem has been cleared, the ISP/ISP or ISP/ISC shall
   advise the other the problem has been cleared. When closing a problem
   report between ISP/ISP or ISP/ISC, the disposition should be
   furnished by the organization closing the ticket.

Are thos slashed abbreviations _correct_? I guess I missed something; I
don't have an expansion ready to hand that fits.

   An example of the information exchanged in the problem disposition:

   -- Trouble ticket number

   -- Referral datetime

   -- Returned datetime

   -- Trouble identified as

   -- Resolution details

   -- Service charges, if the ticket resulted in a service charge

   If there is a disagreement about the disposition of a problem ticket,
   the parties involved should document their respective positions and
   the names of the individuals involved. Escalation will be made
   according to each organizations escalation procedures.

Glad this is in here... :slight_smile:


   Each ISP and ISC shall establish procedures for timely escalation of
   problems to successive levels of management. The procedures should
   include the provision of status reports to the other provider or
   customer regarding the ticket status. Both technical and management
   contacts should be included in the escalation procedures.

I suspect that's not enough... but we'll see...

End-to-End Testing

   Networks may experience problems which cannot be isolated by each
   provider individually testing and maintaining its own services. Each
   providers' service may appear to perform correctly, but trouble
   appears on an end-to-end service. The ISC's RISP should coordinate
   end-to-end testing with each sectional provider by problem referral
   through their Responsible Internet Service Provider. Each Internet

Pronoun without a referent. Whose? The ISC? The RISP? The sectional
provider? (There's another new piece of terminology.)

   Service Provider should accept the referral request for end-to-end
   testing coordination, and provide the contact information for the
   next sectional provider to the original requestor.

This assumes to some extent that the customers -- even though they're
paying for the lines -- can actually _get_ the information from the
vendors... something which isn't always true. Perhaps a statement
encouraging that?