--- 1/draft-ietf-mboned-mtrace-v2-16.txt	2017-03-13 07:13:25.644313575 -0700
+++ 2/draft-ietf-mboned-mtrace-v2-17.txt	2017-03-13 07:13:25.716315280 -0700
@@ -1,20 +1,20 @@
 
 MBONED Working Group                                           H. Asaeda
 Internet-Draft                                                      NICT
 Intended status: Standards Track                                K. Meyer
-Expires: May 4, 2017                                               Cisco
+Expires: September 13, 2017                                        Cisco
                                                              W. Lee, Ed.
-                                                        October 31, 2016
+                                                          March 12, 2017
 
          Mtrace Version 2: Traceroute Facility for IP Multicast
-                     draft-ietf-mboned-mtrace-v2-16
+                     draft-ietf-mboned-mtrace-v2-17
 
 Abstract
 
    This document describes the IP multicast traceroute facility, named
    Mtrace version 2 (Mtrace2).  Unlike unicast traceroute, Mtrace2
    requires special implementations on the part of routers.  This
    specification describes the required functionality in multicast
    routers, as well as how an Mtrace2 client invokes a query and
    receives a reply.
 
@@ -26,25 +26,25 @@
    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 May 4, 2017.
+   This Internet-Draft will expire on September 13, 2017.
 
 Copyright Notice
 
-   Copyright (c) 2016 IETF Trust and the persons identified as the
+   Copyright (c) 2017 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
    carefully, as they describe your rights and restrictions with respect
    to this document.  Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
@@ -517,25 +517,25 @@
       The Query Arrival Time is a 32-bit NTP timestamp specifying the
       arrival time of the Mtrace2 Query or Request packet at this
       router.  The 32-bit form of an NTP timestamp consists of the
       middle 32 bits of the full 64-bit form; that is, the low 16 bits
       of the integer part and the high 16 bits of the fractional part.
 
       The following formula converts from a UNIX timeval to a 32-bit NTP
       timestamp:
 
          query_arrival_time
-         = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec << 10) / 15625)
+         = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125)
 
       The constant 32384 is the number of seconds from Jan 1, 1900 to
-      Jan 1, 1970 truncated to 16 bits.  ((tv.tv_usec << 10) / 15625) is
-      a reduction of ((tv.tv_usec / 100000000) << 16).
+      Jan 1, 1970 truncated to 16 bits.  ((tv.tv_nsec << 7) / 1953125)
+      is a reduction of ((tv.tv_nsec / 1000000000) << 16).
 
       Note that Mtrace2 does not require all the routers on the path to
       have synchronized clocks in order to measure one-way latency.
 
       Additionally, Query Arrival Time is useful for measuring the
       packet rate.  For example, suppose that a client issues two
       queries, and the corresponding requests R1 and R2 arrive at router
       X at time T1 and T2, then the client would be able to compute the
       packet rate on router X by using the packet count information
       stored in the R1 and R2, and the time T1 and T2.