--- 1/draft-ietf-6man-spring-srv6-oam-01.txt	2019-11-20 21:13:19.761217375 -0800
+++ 2/draft-ietf-6man-spring-srv6-oam-02.txt	2019-11-20 21:13:19.805218502 -0800
@@ -1,25 +1,25 @@
 
 6man                                                              Z. Ali
 Internet-Draft                                               C. Filsfils
 Intended status: Standards Track                           Cisco Systems
-Expires: May 6, 2020                                       S. Matsushima
+Expires: May 23, 2020                                      S. Matsushima
                                                                 Softbank
                                                                 D. Voyer
                                                              Bell Canada
                                                                  M. Chen
                                                                   Huawei
-                                                        November 3, 2019
+                                                       November 20, 2019
 
   Operations, Administration, and Maintenance (OAM) in Segment Routing
                   Networks with IPv6 Data plane (SRv6)
-                   draft-ietf-6man-spring-srv6-oam-01
+                   draft-ietf-6man-spring-srv6-oam-02
 
 Abstract
 
    This document defines building blocks for Operations, Administration,
    and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane
    (SRv6).  The document also describes some SRv6 OAM mechanisms.
 
 Requirements Language
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -34,21 +34,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 May 6, 2020.
+   This Internet-Draft will expire on May 23, 2020.
 
 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
@@ -229,38 +229,39 @@
    Implementation of the O-flag is OPTIONAL.  If a node does not support
    the O-flag, then upon reception it simply ignores it.  It is also
    possible that a node is capable of supporting the O-bit but based on
    a local decision it MAY ignore it during processing on some local
    SIDs.
 
    If a node supports the O-flag, it can optionally advertise its
    potential via node capability advertisement in IGP [I-D.ietf-isis-
    srv6- extensions] and BGP-LS [I-D.ietf-idr-bgpls-srv6-ext].
 
-   When N receives a packet whose IPv6 DA is S and S is a local SID, N
-   executes the following pseudo-code, before the execution of the local
-   SID S.  Specifically, for the SID defined in section 4.3.1.1 of [I-
-   D.ietf-6man-segment-routing-header], the O-flag processing happens
-   immediately following S01.
+   When N receives a packet whose IPv6 DA is S and S is a local SID, the
+   pseudo-code associated with the SID S, as defined in section 4.3.1.1
+   of [I-D.ietf-6man-segment-routing-header], is modified as follows for
+   the O-flag processing.
 
-     S01.1. IF SRH.Flags.O-flag is one and local configuration permits THEN
+     S01.1. IF SRH.Flags.O-flag is set and local configuration permits
+            O-flag processing THEN
             a. Make a copy of the packet.
             b. Send the copied packet, along with an accurate timestamp
-               to the OAM process.      ;; Ref1, Ref2, Ref3
+               to the OAM process.      ;; Ref1, Ref2
      Ref1: An implementation SHOULD copy and record the timestamp as soon as
      possible during packet processing. Timestamp is not carried in the packet
      forwarded to the next hop.
      Ref2: An implementation SHOULD NOT generate ICMP error during
      local SID S processing. If local SID S processing requires generation
      of an ICMP error, the error is generated by the local OAM process.
-     Ref3: If multiple SRH are present with O-flag set, an implementation
-     SHOULD only send one copy of the packet to the OAM process.
+
+   Please note that the O-flag processing happens before execution of
+   regular processing of the local SID S.
 
 3.2.  OAM Segments
 
    OAM Segment IDs (SIDs) is another component of the SRv6 OAM building
    Blocks.  This document defines a couple of OAM SIDs.
 
 3.3.  End.OP: OAM Endpoint with Punt
 
    Many scenarios require punting of SRv6 OAM packets at the desired
    nodes in the network.  The "OAM Endpoint with Punt" function (End.OP