IETF Logo Mail Archive

Re: Review of draft-ietf-ippm-twamp-time-format-05

Greg Mirsky <gregimirsky@gmail.com> Mon, 10 April 2017 16:31 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09034129562; Mon, 10 Apr 2017 09:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCvon_4EYswA; Mon, 10 Apr 2017 09:31:17 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B777129566; Mon, 10 Apr 2017 09:31:08 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id r203so154162158oib.3; Mon, 10 Apr 2017 09:31:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2JVZHc7hX/az4HfFf4s/+OtOczCIPY/kINpgO+x1xLY=; b=aYHzaOqE6IdE7AZP0LWcfGKEJzk9y8hpXDBTm3BQIxnJsEg/dnuYReBqZgOqz6Gfg3 nSNSgPnuXSuOG+ECIyiHs3oD6ia3FhY0jXFw3C9ZsUHBLatAxuBF4WtdxotkuAm/5oCn n3pbQRkgof8OGAijQnv0c+Z2KO0dgKB7AoxRljC670z1LGI6lq/3LWyWXfR0IHFg0lbf VvIKT6NW+b8xL0qCVe5jlEu5fE7h7Vt/hemgWkLs1VkmSjvFEZcHh+E/zOwYjh+yGuUd 1d1tZ11zMiTSNrBHbaOL25iL6OExb3ALDAgqwFGOWhFVvoLiw5EaF5ZaFoG/FvZo9Sez htlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2JVZHc7hX/az4HfFf4s/+OtOczCIPY/kINpgO+x1xLY=; b=sWk/qx9m+BhKbiyrAjrQbBwMethVyz3twUqeldFMiZ+7HrqisQOk1053VUUPMZczkC DdDBiPu55usNMYW3tR4M5T8E0XA8xHZTZtRbaE/IevBprTabNv1AvA80fiYuHhpTt45X 6Iprgv7dp6NolJSYt+LBKTCJlK2bdbkDuRII1aoeCk9fTM1OTH8vTG+u/yP1wBN5Hk/6 +CIqX/h1mmS9pKnhTSKgq/PZxRrYu3YAClq/ukEIvp0D7UCzUwvcD4P+QaLX+x+z0JwX tSHkRwW8bKGs06EZRmaE+vwd7W+X71REfJuxCcFdoY+oVeb86AcAdV1dKHm+o0InVR0n Ta+Q==
X-Gm-Message-State: AN3rC/6gT0KGlwt/WiJy82/b56hNaEnWoO3+cgXaTTeFvO2O7PboiLgS25BfALbrH6Yudb6wP7IjCmlTr4PD1A==
X-Received: by 10.157.42.82 with SMTP id t76mr5477307ota.40.1491841867253; Mon, 10 Apr 2017 09:31:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.39.165 with HTTP; Mon, 10 Apr 2017 09:31:06 -0700 (PDT)
In-Reply-To: <CA+RyBmWLezQVyq+d5OZD3fM5-4EN-qCVTAJ-_LGX+4KmKUCTWA@mail.gmail.com>
References: <148977726052.13049.17633302885192133866@ietfa.amsl.com> <CA+RyBmWLezQVyq+d5OZD3fM5-4EN-qCVTAJ-_LGX+4KmKUCTWA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 10 Apr 2017 09:31:06 -0700
Message-ID: <CA+RyBmWdwf55No_BELKz4TKHiMC-KzGKbmdJNS3zOBRNtiMmag@mail.gmail.com>
Subject: Re: Review of draft-ietf-ippm-twamp-time-format-05
To: Jon Mitchell <jrmitche@puck.nether.net>
Cc: ops-dir@ietf.org, draft-ietf-ippm-twamp-time-format.all@ietf.org, "ietf@ietf.org" <ietf@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="001a113d09de8f0dbb054cd28017"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/yodFC_1JDyI7yvEAuJsWcqqGIps>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Apr 2017 16:31:19 -0000

Hi Jon,
apologies for the extended delay to address your comment. I'd like to add
the following just before the Section 2.1:

   Implementations of OWAMP and/or TWAMP MAY provide a configuration
   knob to bypass the timestamp format negotiation process and to use
   the locally configured values instead.

Hope it captures the idea of and addresses your comment.

Regards,
Greg


On Mon, Mar 20, 2017 at 10:34 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Jon,
> thank you for kind consideration of the draft and thoughtful comment.
> Indeed, TWAMP Test, and the time stamp format to be used, may be controlled
> by means other than TWAMP Control, e.g., local configurable knob exposed
> via data model or CLI. I'll work on text updates for the next version.
>
> Regards,
> Greg
>
> On Fri, Mar 17, 2017 at 2:01 PM, Jon Mitchell <jrmitche@puck.nether.net>
> wrote:
>
>> Reviewer: Jon Mitchell
>> Review result: Has Nits
>>
>> I have reviewed this document as part of the Operational directorate's
>>
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These
>> comments were written with the intent of improving the operational
>> aspects of the
>> IETF drafts. Comments that are not addressed in last call may be
>> included in AD reviews
>> during the IESG review.  Document editors and WG chairs should treat
>> these comments
>> just like any other last call comments.
>>
>> Ready with Nits - this draft adds the ability to use PTP timestamps as
>> an alternative to NTP timestamps for active performance measurement
>> protocols OWAMP and TWAMP.  Although this draft does a good job of
>> discussing interoperability for both sides of the session having or
>> not having support for this operational capability, in several places
>> it states that if a send/receiver support this capability it must be
>> set to 1 in the flags.  However, only for TWAMP Light mode, this seems
>> configurable.  This may just be my interpretation, but it probably
>> should state that local implementations MAY provide a configurable
>> knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2 even if
>> the capability is supported by the implementation.
>>
>>
>>
>

v2.23.0 | Report a Bug | By Email