--- 1/draft-ietf-grow-route-leak-problem-definition-05.txt	2016-05-05 15:16:04.094221787 -0700
+++ 2/draft-ietf-grow-route-leak-problem-definition-06.txt	2016-05-05 15:16:04.118222390 -0700
@@ -1,22 +1,22 @@
 
 Global Routing Operations                                      K. Sriram
 Internet-Draft                                             D. Montgomery
 Intended status: Informational                                   US NIST
-Expires: October 31, 2016                                   D. McPherson
+Expires: November 6, 2016                                   D. McPherson
                                                             E. Osterweil
                                                           Verisign, Inc.
                                                               B. Dickson
-                                                          April 29, 2016
+                                                             May 5, 2016
 
         Problem Definition and Classification of BGP Route Leaks
-            draft-ietf-grow-route-leak-problem-definition-05
+            draft-ietf-grow-route-leak-problem-definition-06
 
 Abstract
 
    A systemic vulnerability of the Border Gateway Protocol routing
    system, known as 'route leaks', has received significant attention in
    recent years.  Frequent incidents that result in significant
    disruptions to Internet routing are labeled "route leaks", but to
    date a common definition of the term has been lacking.  This document
    provides a working definition of route leaks, keeping in mind the
    real occurrences that have received significant attention.  Further,
@@ -34,21 +34,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    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."
 
-   This Internet-Draft will expire on October 31, 2016.
+   This Internet-Draft will expire on November 6, 2016.
 
 Copyright Notice
 
    Copyright (c) 2016 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -189,27 +189,27 @@
    or "peer-to-peer".  This type of route leak typically occurs when,
    for example, three sequential ISP peers (e.g.  ISP-A, ISP-B, and ISP-
    C) are involved, and ISP-B receives a route from ISP-A and in turn
    leaks it to ISP-C.  The typical routing policy between laterally
    (i.e. non-transit) peering ISPs is that they should only propagate to
    each other their respective customer prefixes.
 
    o  Example incidents: In [Mauch-nanog][Mauch], route leaks of this
       type are reported by monitoring updates in the global BGP system
       and finding three or more very large ISP ASNs in a sequence in a
-      BGP update's AS path.  [Mauch] observes that these are anomalies
-      and potentially route leaks because very large ISPs such as ATT,
-      Sprint, Verizon, and Globalcrossing do not in general buy transit
-      services from each other.  However, it also notes that there are
-      exceptions when one very large ISP does indeed buy transit from
-      another very large ISP, and accordingly exceptions are made in its
-      detection algorithm for known cases.
+      BGP update's AS path.  [Mauch] observes that its detection
+      algorithm detects for these anomalies and potentially route leaks
+      because very large ISPs do not in general buy transit services
+      from each other.  However, it also notes that there are exceptions
+      when one very large ISP does indeed buy transit from another very
+      large ISP, and accordingly exceptions are made in its detection
+      algorithm for known cases.
 
 3.3.  Type 3: Leak of Transit-Provider Prefixes to Peer
 
    Description: This type of route leak occurs when an offending AS
    leaks routes learned from its transit provider to a lateral (i.e.
    non-transit) peer.
 
    o  Example incidents: The incidents reported in [Mauch] include the
       Type 3 leaks.