--- 1/draft-ietf-speermint-architecture-18.txt	2011-02-18 23:14:14.000000000 +0100
+++ 2/draft-ietf-speermint-architecture-19.txt	2011-02-18 23:14:14.000000000 +0100
@@ -1,19 +1,19 @@
 
 SPEERMINT                                                  D. Malas, Ed.
 Internet-Draft                                                 CableLabs
 Intended status: Informational                         J. Livingood, Ed.
-Expires: August 21, 2011                                         Comcast
-                                                       February 17, 2011
+Expires: August 22, 2011                                         Comcast
+                                                       February 18, 2011
 
         Session PEERing for Multimedia INTerconnect Architecture
-                  draft-ietf-speermint-architecture-18
+                  draft-ietf-speermint-architecture-19
 
 Abstract
 
    This document defines a peering architecture for the Session
    Initiation Protocol (SIP), its functional components and interfaces.
    It also describes the components and the steps necessary to establish
    a session between two SIP Service Provider (SSP) peering domains.
 
 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 August 21, 2011.
+   This Internet-Draft will expire on August 22, 2011.
 
 Copyright Notice
 
    Copyright (c) 2011 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
@@ -78,21 +78,21 @@
          6.1.2.2.  Routing Table  . . . . . . . . . . . . . . . . . . 10
          6.1.2.3.  LRF to LRF Routing . . . . . . . . . . . . . . . . 11
        6.1.3.  The Signaling Path Border Element (SBE)  . . . . . . . 11
          6.1.3.1.  Establishing a Trusted Relationship  . . . . . . . 11
          6.1.3.2.  IPSec  . . . . . . . . . . . . . . . . . . . . . . 11
          6.1.3.3.  Co-Location  . . . . . . . . . . . . . . . . . . . 11
          6.1.3.4.  Sending the SIP Request  . . . . . . . . . . . . . 12
      6.2.  Target SSP Procedures  . . . . . . . . . . . . . . . . . . 12
        6.2.1.  TLS  . . . . . . . . . . . . . . . . . . . . . . . . . 12
        6.2.2.  Receive SIP Requests . . . . . . . . . . . . . . . . . 12
-     6.3.  Data Path Border Element (DBE) . . . . . . . . . . . . . . 12
+     6.3.  Data Path Border Element (DBE) . . . . . . . . . . . . . . 13
    7.  Address Space Considerations . . . . . . . . . . . . . . . . . 13
    8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
    10. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
    11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
    12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15
    13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
      13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
      13.2. Informative References . . . . . . . . . . . . . . . . . . 18
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
@@ -458,21 +458,23 @@
 6.1.3.1.  Establishing a Trusted Relationship
 
    Depending on the security needs and trust relationships between SSPs,
    different security mechanisms can be used to establish SIP calls.
    These are discussed in the following subsections.
 
 6.1.3.2.  IPSec
 
    In certain deployments the use of IPSec between the signaling
    functions of the originating and terminating domains can be used as a
-   security mechanism instead of TLS.
+   security mechanism instead of TLS.  However, such IPSec use should be
+   the subject of a future document as additional specification is
+   necessary to use IPSec properly and effectively.
 
 6.1.3.3.  Co-Location
 
    In this scenario the SFs are co-located in a physically secure
    location and/or are members of a segregated network.  In this case
    messages between the originating and terminating SSPs could be sent
    as clear text (unencrypted).  However, even in these semi-trusted co-
    location facilities, other security or access control mechanisms may
    be appropriate, such as IP access control lists or other mechanisms.
 
@@ -647,20 +649,23 @@
    Global Crossing
 
    Rochester, NY - USA
 
    Email: adam.uzelac@globalcrossing.com
 
 12.  Change Log
 
    NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION.
 
+   o  19: Additional change to the IPSec section at Jari Arkko's
+      request.
+
    o  18: Made several changes based on feedback from Adrian Farrel,
       Bert Wijnen, Dan Romascanu, Avshalom Houri, Russ Housley, Sean
       Turner, Tim Polk, and Russ Mundy during IESG review.
 
    o  17: Misc. updates at the request of Gonzalo, the RAI AD, in order
       to clear his review and move to the IESG.  This included adding
       terminology from RFC 5486 and expanding the document name.
 
    o  16: Yes, one final outdated reference to fix.