Re: [ippm] Genart last call review of draft-ietf-ippm-stamp-07

Greg Mirsky <gregimirsky@gmail.com> Mon, 14 October 2019 20:04 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69C2120883; Mon, 14 Oct 2019 13:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.596
X-Spam-Level:
X-Spam-Status: No, score=-0.596 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 v7eFQ2yPbZym; Mon, 14 Oct 2019 13:04:22 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 1D14F12003F; Mon, 14 Oct 2019 13:04:21 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id m7so17865857lji.2; Mon, 14 Oct 2019 13:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1q2mqDc4gtF75bBdFNdTMft8KX4TkcFGBm3dhjLRxWQ=; b=imqrpuMWNbZIY4VNcGap2mEvwIlitEVkguB4a+Dxg2UehX2mC9Wul2cfDYjmZKABVo 5yq58xR/oLBsgrOPsML5GtTct61cuDkWsB5jPjH7a31rCieiQKpHy8fMFvvy048neM5l UQxNuhfdhUreyodA6DZDe5u5bztJ2odJGFJb9VmOIa21YdGdIxFXlSWG9dmNzjbXDWYR ivJiutJNKMJV1GTkFJY5ihnFOj4GiWvGlI86NwObPQbu3vX7WXQRKg5GoG44AsBApOJW XxDkHA5dPiQIcBrpwfOzPiC0jerEyD2bOILi3BSskvx0f2IAXUU2A1gl4q5lvk00tahi vMFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1q2mqDc4gtF75bBdFNdTMft8KX4TkcFGBm3dhjLRxWQ=; b=cGX3mgv1zE1QY7JgEf7u4THxduh2lIDxJ45rlTnYyr4NGNP6MkEZvpTJOP4Ctxd4dw o1Lgexn38C6uDIHo22sXbsZZcRbmgrhslqFDK73iRSAUp1oC0S0c0nOboian3NKpNgMv CClVXsL2fFw5BaC1rPgztCuUEzMhQhK80fr2Wf+bqA1KpCE5mh7SM7x22wmGoLJAlgLy N3FZOvEaqxvzVKzeajxjoGjKdP6rSlL5KoO6ahZjAKtY97kAJpHo41Cubcraq8qzZzSN hPzkbXaSt3yEZgNEDiujANWpihPoFwDFcjAc+tEWYyFSUpjAMa0uB3Htteifz286W8nA JBCQ==
X-Gm-Message-State: APjAAAWcuGpc7CfGvzdm4vlidvqPE/OnCXHKO19JbR10ZiL9tAl5u/Vc I657MikyBT5T+xpbHJal/DxRhY6KSQpn4tafjtw7i0vN0Q0=
X-Google-Smtp-Source: APXvYqxpkrFAvw0wCKc52CAMMsjabXVls/BaKlrv+R2jSsxV2PAEHSm9LjyV+3ru218Le6Vn1cr1VCvayxdjrOfd5K8=
X-Received: by 2002:a05:651c:150:: with SMTP id c16mr14125909ljd.222.1571083458873; Mon, 14 Oct 2019 13:04:18 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmU9z38C66ZVgX=ni72tAcgBT28Www-B=3HmbdZbf1mEEg@mail.gmail.com> <87sgnwnnou.fsf@hobgoblin.ariadne.com>
In-Reply-To: <87sgnwnnou.fsf@hobgoblin.ariadne.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 14 Oct 2019 13:04:06 -0700
Message-ID: <CA+RyBmW_DFyY1_UsNM+USXEEuMx2taR1akmri4uFKNaGvcrccQ@mail.gmail.com>
To: "Dale R. Worley" <worley@ariadne.com>
Cc: gen-art@ietf.org, draft-ietf-ippm-stamp.all@ietf.org, IETF list <ietf@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000007ac0700594e45f7c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/hA9tW42cM5w6-n5rNC1xlzrQOAc>
Subject: Re: [ippm] Genart last call review of draft-ietf-ippm-stamp-07
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Oct 2019 20:04:30 -0000

Hi Dale,
thank you for your kind consideration of the proposed updates, thoughtful
and helpful suggestions. I've clipped parts of our discussion that we've
agreed on the changes. My follow-up notes are in-lined under GIM2>> tag.
Attached, please find the updated working version and its diff to -07
version of the STAMP draft.

Regards,
Greg

On Sun, Oct 13, 2019 at 6:03 PM Dale R. Worley <worley@ariadne.com>; wrote:

> > From: Greg Mirsky <gregimirsky@gmail.com>;
> >
> > Hi Dale,
> > hope this friendly reminder finds you well. I much appreciate your
> > consideration of the responses to your helpful comments.
>
> My apologies for the delay.
>
> All of this looks good.  Although there are a couple of minor points
> that I've added below.
>
> On Mon, Sep 30, 2019 at 5:17 PM Greg Mirsky <gregimirsky@gmail.com>; wrote:
>
> > Hi Dale,
> > thank you for your review, comments, and suggestions. Please find answers
> > and notes in-line under the GIM>> tag.
> > Attached, please find the diff between -07 and the current working
> > version, as well as, the working version of the draft.
> >
> > Regards,
> > Greg
> >
> > On Tue, Sep 3, 2019 at 6:01 PM Dale Worley via Datatracker <
> > noreply@ietf.org>; wrote:
> >
> >>   ----------------------------------------------------------------------
> >> I am the assigned Gen-ART reviewer for this draft. The General Area
> >> Review Team (Gen-ART) reviews all IETF documents being processed
> >> by the IESG for the IETF Chair.  Please treat these comments just
> >> like any other last call comments.
> >>
> >> For more information, please see the FAQ at
> >>
> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
> >>
> >> Document:  draft-ietf-ippm-stamp-07
> >> Reviewer:  Dale R. Worley
> >> Review Date:  2019-09-03
> >> IETF LC End Date:  2019-09-03
> >> IESG Telechat date:  2019-09-19
> >>
> >> Summary:
> >>
> >>        This draft is on the right track but has open issues, described
> >>        in the review.
> >>
>
> >> Editorial issues:
> >>
> >> 1.  Introduction
> >>
> >>    and inherit separation of control (vendor-specific configuration or
> >>    orchestration) and test functions.
> >>
> >> Is "inherit" intended to be "inherent"?
> >>
> > GIM>> Thank you. That was the intention. Done.
> >>
> >>    One of such is Performance
> >>    Measurement from IP Edge to Customer Equipment using TWAMP Light from
> >>    Broadband Forum [BBF.TR-390] used as the reference TWAMP Light that,
> >>    according to [RFC8545], includes sub-set of TWAMP-Test functions in
> >>    combination with other applications that provide, for example,
> >>    control and security.
> >>
> >> This sentence is awkward because of the length of the title in the
> >> middle of the sentence.  Perhaps
> >>
> >>    One of such is [BBF.TR-390] (Performance Measurement from IP Edge
> >>    to Customer Equipment using TWAMP Light from the Broadband Forum),
> >>    a the reference TWAMP Light, that includes a sub-set of TWAMP-Test
> >>    functions along with control and security functions.
> >>
> > GIM>> Thank you for the proposed text. While addressing other comments
> the
> > text has been transformed to the following:
> > CURRENT TEXT:
> >    Recent work on IP Edge to Customer Equipment using TWAMP Light from
> >    Broadband Forum [BBF.TR-390] demonstrated that interoperability among
> >    implementations of TWAMP Light is challenged because the composition
> >    and operation of TWAMP Light were not sufficiently specified in
> >    [RFC5357].  According to [RFC8545], TWAMP Light includes sub-set of
> >    TWAMP-Test functions to provide comprehensive solution requires
> >    support by other applications that provide, for example, control and
> >    security.
> > Hope the current version is clearer and more readable.
>
> I would change "interoperability among implementations of TWAMP Light
> is challenged" to "interoperability among TWAMP Light implementations
> is poor", or perhaps "... is difficult".
>
GIM2>> Will use "difficult".

>
> In the last sentence, I think there are words missing from "to provide
> comprehensive solution requires support"; perhaps "to provide a
> comprhenesive soultion with support"?
>
GIM2>> I agree, that sentence is awkward. Here's its update:
OLD TEXT:
   According to [RFC8545], TWAMP Light includes sub-set of
   TWAMP-Test functions to provide comprehensive solution requires
   support by other applications that provide, for example, control and
   security.
NEW TEXT:
   According to [RFC8545], TWAMP Light includes a sub-set of
   TWAMP-Test functions.  Thus, to have a comprehensive tool to measure
   packet loss and delay requires support by other applications that
   provide, for example, control and security.

>
>
> >>    o  Timestamp is eight octets long field.  STAMP node MUST support
> >>       Network Time Protocol (NTP) version 4 64-bit timestamp format
> >>       [RFC5905], the format used in [RFC5357].  STAMP node MAY support
> >>       IEEE 1588v2 Precision Time Protocol truncated 64-bit timestamp
> >>       format [IEEE.1588.2008], the format used in [RFC8186].
> >>
> >> The specification of how the time format for a particular packet is
> >> chosen is weak.  I think you want to add to the above paragraph that
> >> the choice of format is determined either by configuration or the Z
> >> bit in the Error Estimate field.
> >>
> > GIM>> In regard to the format of a timestamp, STAMP specification follows
> > the idea of RFC 8186 where extension to negotiate timestamp format for
> > TWAMP-Control and the new interpretation of Z flag were defined. For
> STAMP,
> > as defined for TWAMP, the value of the Z flag in the Error Estimate field
> > is only to reflect the format used by the node.
>
> In that case, I think you want to add to the definition of the
> timestamp field that the format it uses is part of the configuration
> of the session.  In any situation, it must be clear how the receiver
> of a STAMP packet determines how to interpret the Timestamp value.
>
GIM2>> Thank you for the suggestion. I've added the sentence to the
definition of Timestamp:
    o  Timestamp is eight octets long field.  STAMP node MUST support
      Network Time Protocol (NTP) version 4 64-bit timestamp format
      [RFC5905], the format used in [RFC5357].  STAMP node MAY support
      IEEE 1588v2 Precision Time Protocol (PTP) truncated 64-bit
      timestamp format [IEEE.1588.2008], the format used in [RFC8186].
      The use of the specific format, NTP or PTP, is part of
      configuration of the Session-Sender or the particular test
      session.
>
>
> >> 4.1.2.  Session-Sender Packet Format in Authenticated Mode
> >>
> >>    Also, MBZ fields are used to align the packet on 16 octets
> >>    boundary.
> >>
> >> You can't align the packet itself using a field within the packet.
> >> You want to say "are used to align the fields within the packet on 16
> >> octets boundaries."  Or perhaps "to make the packet length a multiple
> >> of 16 octets."  Similarly in 4.2.1 and 4.2.2.
> >>
> > GIM>> Thank you for the suggested text. I've used the second option.
> >
> >>
> >> 4.2.  Session-Reflector Behavior and Packet Format
> >>
> >>    Two modes of STAMP Session-Reflector characterize the expected
> >>    behavior and, consequently, performance metrics that can be measured:
> >>
> >>    o  Stateless - STAMP Session-Reflector does not maintain test state
> >>       and will reflect the received sequence number without
> >>       modification.  As a result, only round-trip packet loss can be
> >>       calculated while the reflector is operating in stateless mode.
> >>
> >>    o  Stateful - STAMP Session-Reflector maintains test state thus
> >>       enabling the ability to determine forward loss, gaps recognized in
> >>       the received sequence number.  As a result, both near-end
> >>       (forward) and far-end (backward) packet loss can be computed.
> >>       That implies that the STAMP Session-Reflector MUST keep a state
> >>       for each accepted STAMP-test session, uniquely identifying STAMP-
> >>       test packets to one such session instance, and enabling adding a
> >>       sequence number in the test reply that is individually incremented
> >>       on a per-session basis.
> >>
> >> This seems important enough -- the mode determines what data STAMP
> >> can measure -- to be promoted to part of section 4, "Theory of
> >> Operation".
> >>
> > GIM>> I agree. Moved the text to Section 4 and re-named this section to
> > Session-Reflector Packet Format
>
> That looks good, except that the first words of para 4 are
> "STAMP supports two modes:", just after para 2 and 3 define two
> *other* modes.  So I'd change para 4 to start "STAMP supports two
> authentication modes:".
>
GIM2>> Agree. Thank you.

>
>
> Dale
>