--- 1/draft-ietf-rtgwg-enterprise-pa-multihoming-10.txt	2019-07-03 19:13:08.406410277 -0700
+++ 2/draft-ietf-rtgwg-enterprise-pa-multihoming-11.txt	2019-07-03 19:13:08.526413326 -0700
@@ -2,21 +2,21 @@
 Routing Working Group                                           F. Baker
 Internet-Draft
 Intended status: Informational                                 C. Bowers
 Expires: January 4, 2020                                Juniper Networks
                                                               J. Linkova
                                                                   Google
                                                             July 3, 2019
 
  Enterprise Multihoming using Provider-Assigned IPv6 Addresses without
          Network Prefix Translation: Requirements and Solutions
-             draft-ietf-rtgwg-enterprise-pa-multihoming-10
+             draft-ietf-rtgwg-enterprise-pa-multihoming-11
 
 Abstract
 
    Connecting an enterprise site to multiple ISPs over IPv6 using
    provider-assigned addresses is difficult without the use of some form
    of Network Address Translation (NAT).  Much has been written on this
    topic over the last 10 to 15 years, but it still remains a problem
    without a clearly defined or widely implemented solution.  Any
    multihoming solution without NAT requires hosts at the site to have
    addresses from each ISP and to select the egress ISP by selecting a
@@ -244,27 +244,26 @@
    of traffic with external destinations.
 
    This document is organized as follows.  Section 4 looks in more
    detail at the enterprise networking environments in which this
    solution is expected to operate.  The discussion of Section 4 uses
    the concepts of source-prefix-scoped routing advertisements and
    forwarding tables and provides a description of how source-prefix-
    scoped routing advertisements are used to generate source-prefix-
    scoped forwarding tables.  Instead, this detailed description is
    provided in Section 5.  Section 6 discusses existing and proposed
-   mechanisms for hosts to select the default source address applied to
-   packets.  It also discusses the requirements for routing that are
-   needed to support these enterprise network scenarios and the
-   mechanisms by which hosts are expected to select source addresses for
-   new connetions dynamically based on network state.  Section 7
-   discusses deployment considerations, while Section 8 discusses other
-   solutions.
+   mechanisms for hosts to select the default source address to be used
+   by applications.  It also discusses the requirements for routing that
+   are needed to support these enterprise network scenarios and the
+   mechanisms by which hosts are expected to update default source
+   addresses based on network state.  Section 7 discusses deployment
+   considerations, while Section 8 discusses other solutions.
 
 2.  Requirements Language
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in BCP
    14 [RFC2119] [RFC8174] when, and only when, they appear in all
    capitals, as shown here.
 
 3.  Terminology