--- 1/draft-ietf-grow-rpki-as-cones-00.txt	2019-03-05 02:13:46.984455231 -0800
+++ 2/draft-ietf-grow-rpki-as-cones-01.txt	2019-03-05 02:13:47.004455716 -0800
@@ -1,20 +1,20 @@
 
 Global Routing Operations                                    J. Snijders
 Internet-Draft                                                       NTT
 Intended status: Informational                                M. Stucchi
-Expires: March 11, 2019                                         RIPE NCC
-                                                       September 7, 2018
+Expires: September 6, 2019                                      RIPE NCC
+                                                           March 5, 2019
 
  RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous
               Systems Numbers To Facilitate BGP Filtering
-                    draft-ietf-grow-rpki-as-cones-00
+                    draft-ietf-grow-rpki-as-cones-01
 
 Abstract
 
    This document describes a way to define groups of Autonomous System
    numbers in RPKI [RFC6480].  We call them AS-Cones.  AS-Cones provide
    a mechanism to be used by operators for filtering BGP-4 [RFC4271]
    announcements.
 
 Requirements Language
 
@@ -32,25 +32,25 @@
    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 https://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 March 11, 2019.
+   This Internet-Draft will expire on September 6, 2019.
 
 Copyright Notice
 
-   Copyright (c) 2018 IETF Trust and the persons identified as the
+   Copyright (c) 2019 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
    (https://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with respect
    to this document.  Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
@@ -237,39 +237,39 @@
 
        1.  An AS-Cone; or
 
        2.  An ASN
 
    3.  If the definition points to an AS-Cone, the operator looks for
        the object referenced, which should be contained in the validated
        cache;
 
    4.  If the validated cache does not contain the referenced object,
-       then the validation moves on to the next downstream network;
+       then the validation moves on to the next downstream ASN;
 
    5.  If the validated cache contains the referenced object, the
        validation process evaluates every entry in the AS-Cone.  For
        each entry:
 
        1.  If there is a reference to an ASN, then the operator adds the
            ASN to the list for the given AS-Cone;
 
        2.  If there is a reference to another AS-Cone, the validating
            process should recursively process all the entries in that
            AS-Cone first, with the same principles contained in this
            list.
 
        Since the goal is to build a list of ASNs announcing routes in
        the AS-Cone, then if an ASN or an AS-Cone are referenced more
        than once in the process, their contents should only be added
        once to the list.  This is intended to avoid endless loops, and
-       in order to avoid cross-reference of AS-Cones
+       in order to avoid cross-reference of AS-Cones.
 
    6.  When all the AS-Cones referenced in the policies have been
        recursively iterated, and all the originating ASNs have been
        taken into account, the operator can then build a full prefix-
        list with all the prefixes originated in its AS-Cone.  This can
        be done by querying the RPKI validator software for all the
        networks originated by every ASN referenced in the AS-Cone.
 
 4.  Recommendations for use of AS-Cones at Internet Exchange points