Thanks for the comments.
-- The media, radio or television, can be used to inform the public. Pre-arrangements, and planning are needed to ensure only designated contacts are made with the media.
Is there _any_ part of the net that's this globally critical?
Since CNN is going to report this stuff anyway, might as well plan for it. This guideline has a dual purpose: 1) to give accurate information to the media, 2) limit the exposure from someone 'spoofing' an ISP to the media.
challenge/response code-word or call-back to a known telephone number.
Note that this isn't always good enough, if the problem is an attack. Call-forwarding and butt-sets, doncha know.
Perhaps I should add an explanation. The goal of these guidelines is to document a minimum set of network management policies a responsible Internet service provider would follow. It is not meant to be the 'Best Common Practice' because I hope most ISPs would maintain a 'higher' level of preparedness than these minimum guidelines. I've deliberately avoided several controversial subjects, such as what constitutes 'abuse' of the network. On the other hand, I have tried to set the bar low, but not too low. If an ISP can't meet this low a set of requirements, I have to wonder if they could really be called a 'responsible' member of the Internet. I deliberately weakened several guidelines to allow an ISP of any size to meet them with hard work. You can't meet these guidelines with a check for $25,000.
Not bad. But, from down here in the trenches, I think it could use another round of flogging. How much commentary have you gotten on it?
The guidelines have been out for 12 months. I've received about a dozen comments or suggestions. I welcome more comments or suggestions. To try to bring this to an end, I intend to dump draft guidelines into the Informational RFC process before the December IETF. At the October NANOG I intend to talk to several ISPs whether they can meet the guidelines, and possibly issue a press release of all the providers who intend to follow them. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation