--- 1/draft-ietf-sidr-roa-validation-08.txt	2010-11-08 03:14:14.000000000 +0100
+++ 2/draft-ietf-sidr-roa-validation-09.txt	2010-11-08 03:14:14.000000000 +0100
@@ -1,19 +1,19 @@
 
 Secure Inter-Domain Routing (SIDR)                             G. Huston
 Internet-Draft                                             G. Michaelson
 Intended status: Informational                                     APNIC
-Expires: April 18, 2011                                 October 15, 2010
+Expires: May 12, 2011                                   November 8, 2010
 
  Validation of Route Origination using the Resource Certificate PKI and
                                   ROAs
-                 draft-ietf-sidr-roa-validation-08.txt
+                 draft-ietf-sidr-roa-validation-09.txt
 
 Abstract
 
    This document defines the semantics of a Route Origin Authorization
    (ROA) in terms of the context of an application of the Resource
    Public Key Infrastructure to validate the origination of routes
    advertised in the Border Gateway Protocol.
 
 Status of this Memo
 
@@ -23,21 +23,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 April 18, 2011.
+   This Internet-Draft will expire on May 12, 2011.
 
 Copyright Notice
 
    Copyright (c) 2010 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
@@ -102,45 +102,40 @@
    destinations described by an IP address prefix with a set of
    attributes of a path to those destinations, as defined in section 1.1
    of [RFC4271].
 
    A route's "origin AS" is defined as follows: If the final path
    segment of the AS_PATH is of type AS_SEQUENCE, the "origin AS" is the
    first element of the sequence (i.e. the AS in the rightmost position
    with respect to the position of octets in the protocol message).  If
    the final path segment of the AS_PATH is of type AS_SET, indicating
    that the route is an aggregate, then the origin AS is taken as the AS
-   component of the AGGREGATOR path attribute [RFC4271], if present.  If
-   the AGGREGATOR path attribute is missing, then the origin AS is the
-   first AS element of the last path segment of type AS_SEQUENCE (i.e.
-   this would conventionally be the AS in the rightmost position of the
-   AS_SEQUENCE path segment immediately preceding the final AS_SET path
-   segment in the protocol message).  Otherwise the route's origin AS
-   cannot be determined.
+   component of the AGGREGATOR path attribute [RFC4271], if present.
+   Otherwise the route's origin AS cannot be determined.
 
    In terms of validation of a route in the context of a routing
    environment, the address prefix value and the origin AS are used in
    the ROA validation operation.
 
    It is assumed here that a Relying Party (RP) has access to a local
    cache of the complete set of valid ROAs when performing validation of
    a route.  (Valid ROAs are defined as ROAs that are determined to be
    syntactically correct and are signed using a signature that can be
    verified using the RPKI, as described in [I-D.ietf-sidr-roa-format].)
    The RP needs to match a route to one or more candidate valid ROAs in
    order to determine a validation outcome, which, in turn, can be used
    to determine the appropriate local actions to perform on the route.
 
    This approach to route origination validation uses a generic model of
    "positive" attestation that has an associated inference that routes
    that cannot be validated within the RPKI framework would
-   conventionally be interpreted by a RP as "invalid".  However, the
+   conventionally be interpreted by an RP as "invalid".  However, the
    considerations of accommodating environments of partial adoption of
    the use of ROAs, where only a subset of validly advertised address
    prefixes have associated published ROAs within the structure of the
    RPKI, imply some modification to this model of positive attestation.
    In the context of route validation it is assumed that once an address
    prefix is described in a ROA, then this ROA specifically encompasses
    all address prefixes that are more specific than that described in
    the ROA.  Thus, any route for a more specific address prefix than
    that described by any valid ROA that does not itself have a matching
    valid ROA can be considered to be "invalid".  However, routes objects