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
INTERNET DRAFT DRA
<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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Rational and Scope
Rationale
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
Internet.
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
Accepting
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
designee?
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
contact.
An example of the information exchanged in the problem referral
report:
-- 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
problem
-- 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. 
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. 
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... 
Escalation
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?