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

[Jon Mitchell <[e-mail]>]

SGTM

On Apr 10, 2017 12:31, Greg Mirsky <[e-mail]> wrote:

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 <[e-mail]> 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 <[e-mail]> 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.