Operational Security Current Practices in Internet Service Provider Environments
RFC 4778

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    opsec mailing list <opsec@ietf.org>, 
    opsec chair <opsec-chairs@tools.ietf.org>
Subject: Document Action: 'Operational Security Current 
         Practices' to Informational RFC 

The IESG has approved the following document:

- 'Operational Security Current Practices '
   <draft-ietf-opsec-current-practices-08.txt> as an Informational RFC

This document is the product of the Operational Security Capabilities for 
IP Network Infrastructure Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsec-current-practices-08.txt

Technical Summary
 
 This document is a survey of the current practices used in today's
 large ISP operational networks to secure layer 2 and layer 3
 infrastructure devices.  The information listed here is the result of
 information gathered from people directly responsible for defining
 and implementing secure infrastructures in Internet Service Provider
 environments.

Working Group Summary
 
 This document is a product of the opsec working group.
 
Protocol Quality
 
 David Kessens reviewed this document for the IESG. In addition to 
 careful review by the opsec working group, this document also received 
 considerable review from the operator community.

Note to RFC Editor

 Change the title:

 OLD:

  Operational Security Current Practices

 NEW:

  Current Operational Security Practices in Internet Service Provider
  Environments

 In section 1.2., paragraph 5:

   ...
   resent at later time).  A message can also be inserted with any of
   the fields in the message being OspoofedO, such as IP
   addresses, port
   ...

  s/OspoofedO,/spoofed,/

 In section 2.2.3., paragraph 4:
   
   ...    
   internal system.  Also, using SSH for device access ensures that
   noone can spoof the traffic during the SSH session.
   ...

  s/noone/no one/

 In section '2.4.2.  Security Practices':

   ...
   Some large ISPs require that routes be registered in an Internet
   Routing Registry [IRR] which can then be part of the RADB - a public
   registry of routing information for networks in the Internet that can
   be used to generate filter lists.
   ...

  s/[IRR]/(IRR)/

   ...
   registry of routing information for networks in the Internet
   that can be used to generate filter lists.  Some ISPs, especially in
   europe,
   ...

  s/europe,/Europe,/

 In section 5., paragraph 1:
  
   ...  
   Jones, who has been instrumental in providing guidance and
   direction for this document and the insighful comments from Ross
   Callon, Ron
   ...

  s/insighful/insightful/

 In section '6.1.  Normative References':

  Remove reference to 'RFC2119'