--- 1/draft-ietf-mpls-rmr-10.txt	2019-06-08 19:13:09.134091472 -0700
+++ 2/draft-ietf-mpls-rmr-11.txt	2019-06-08 19:13:09.170092460 -0700
@@ -1,19 +1,19 @@
 
 MPLS WG                                                      K. Kompella
 Internet-Draft                                    Juniper Networks, Inc.
 Intended status: Standards Track                            L. Contreras
-Expires: November 22, 2019                                    Telefonica
-                                                            May 21, 2019
+Expires: December 10, 2019                                    Telefonica
+                                                            June 8, 2019
 
                           Resilient MPLS Rings
-                         draft-ietf-mpls-rmr-10
+                         draft-ietf-mpls-rmr-11
 
 Abstract
 
    This document describes the use of the MPLS control and data planes
    on ring topologies.  It describes the special nature of rings, and
    proceeds to show how MPLS can be effectively used in such topologies.
    It describes how MPLS rings are configured, auto-discovered and
    signaled, as well as how the data plane works.  Companion documents
    describe the details of discovery and signaling for specific
    protocols.
@@ -32,21 +32,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 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 November 22, 2019.
+   This Internet-Draft will expire on December 10, 2019.
 
 Copyright Notice
 
    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
@@ -75,21 +75,21 @@
      4.2.  Ring Announcement Phase . . . . . . . . . . . . . . . . .  10
      4.3.  Mastership Phase  . . . . . . . . . . . . . . . . . . . .  11
      4.4.  Ring Identification Phase . . . . . . . . . . . . . . . .  11
      4.5.  Ring Changes  . . . . . . . . . . . . . . . . . . . . . .  12
    5.  Ring Signaling  . . . . . . . . . . . . . . . . . . . . . . .  12
    6.  Ring OAM  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
    7.  Advanced Topics . . . . . . . . . . . . . . . . . . . . . . .  13
      7.1.  Half-rings  . . . . . . . . . . . . . . . . . . . . . . .  13
      7.2.  Hub Node Resilience . . . . . . . . . . . . . . . . . . .  13
    8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
-   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
+   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
    10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
    11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
      11.1.  Normative References . . . . . . . . . . . . . . . . . .  14
      11.2.  Informative References . . . . . . . . . . . . . . . . .  14
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15
 
 1.  Introduction
 
    Rings are a very common topology in transport networks.  A ring is
    the simplest topology offering link and node resilience.  Rings are
@@ -589,35 +589,26 @@
    If H1 fails, traffic from X to Z will drop until the T-LDP session
    from H1 to Z fails, the IGP reconverges, and H2's label to Z is
    chosen.  Thereafter, traffic will go from X to H2 via a ring LSP,
    then to Z via LDP.  However, this convergence could take a long time.
    Since this is a very common and important situation, it is again a
    useful problem to solve.  However, this topic too will not be
    addressed in this document; that task is left for a future document.
 
 8.  Security Considerations
 
-   This document presents a new method of using MPLS in rings.  The use
-   of MPLS in rings is not new, so this per se does not pose security
-   concerns.  The question is, rather, whether the extensions to
-   protocols suggested here do so.  IS-IS and OSPF have security
-   mechanisms that ensure secure exchange of information, as do RSVP-TE
-   and LDP.  The extensions proposed here are protected by the same
-   mechanisms.
-
-   One can also ask whether the semantic content of these extensions can
-   be used to compromise a network or initiate a denial-of-service
-   attack.  To do so would require either compromising the control plane
-   processing these requests, or manipulating the content of the
-   messages.  The former is outside the scope of this document; the
-   latter is addressed by the security mechanisms of the underlying
-   protocols.
+   This document proposes extensions to IS-IS, OSPF, LDP and RSVP-TE,
+   all of which have mechanisms to secure them.  The extensions proposed
+   do not represent per se a compromise to network security when the
+   control plane is secured, since any manipulation of the content of
+   the messages or even the control plane misinterpretation of the
+   semantics are avoided.
 
 9.  Acknowledgments
 
    Many thanks to Pierre Bichon whose exemplar of self-organizing
    networks and whose urging for ever simpler provisioning led to the
    notion of promiscuous nodes.
 
 10.  IANA Considerations
 
    There are no requests as yet to IANA for this document.