Re: [ippm] Barry Leiba's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS)

Greg Mirsky <gregimirsky@gmail.com> Tue, 24 September 2019 17:19 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 4A3B2120883; Tue, 24 Sep 2019 10:19:39 -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 qpFJ7jjgr8Zv; Tue, 24 Sep 2019 10:19:30 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 8A1F612089F; Tue, 24 Sep 2019 10:19:17 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id f5so2707739ljg.8; Tue, 24 Sep 2019 10:19:17 -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=vqv/3x4gQ7yOwEpifj1k6Naxl6VRlFDkpZdJsYPAvLY=; b=kOMysoCGMurkwwRYimta6kblIkqpY6AwKbRxcn+23o8G+lIhAoscRnDDABEkR8zXyB F+bVYpNbmQQyRQJSGg+YheP9+B7LBUI044ICImfomCnSFLWm2lqmdY7PdlWGYbWgnVPx Blufy2fpjIEu0bsvaNaWxkV0YX2CdtOq9/8rc/sLWGPLoJGXcZUygYO7qcDTPecDJRRY hGyu5XKqVTpW3G9FKbcVwrxYEnI77WnwnkM1JVu9wzBAG2XLL40sMktp/CKRRguFA4N1 wqdnJhQtEaF9BpoBeZJ/OObC7AIKoipFu0BdGEbjsdJ2bamVPBnY064+jcFC8k0nG1db gTdA==
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=vqv/3x4gQ7yOwEpifj1k6Naxl6VRlFDkpZdJsYPAvLY=; b=APDy9rjsIhb53s/mmmfoh6hyLrVaoTO2P2Icfidpiw2EPTm+9dcs/zL5Yon1xg18Fy zDssYVvCUgnLgjWCvVKsMpYzqwagHc+QaaeuahnGK2XCg1NehmyVtmH7QRMjft3/Rpmc ejnZGSdFzOBTej0QUM8pTxwtg2nfyJ6o1woyDuQoyYSue7/97Lq7RCSkQuGDuVK30C4M QnI9Oqe8vadp9N0x9OHFeusS8SNoX2uem0GVhTe2ueY7NJVKiRjf+YqbcLc3yDSnt95s lLA/Tn139ocZD/maDjZbrQ7UeKIYpxfFpCRvdJ0rKmHyC8iklvUvjaLTvuIxvFM9BELk CAkg==
X-Gm-Message-State: APjAAAUtr1roAWL2uakcpLOVbhpzG12zcLIKT8yz8K5mYIjSaK25TZc7 YKg7FU9//jzmqYfzS2zJIYwLQ263fbqj09rHtNE=
X-Google-Smtp-Source: APXvYqym5ralBC44mf1kpY/ZfAZpAv98BCZtyaD1lLxjNzV7r7+62XV0B+ATCjXK5uwoqtMcVv3gNBv0vsevA2Wbqj0=
X-Received: by 2002:a2e:5d98:: with SMTP id v24mr2857862lje.56.1569345555405; Tue, 24 Sep 2019 10:19:15 -0700 (PDT)
MIME-Version: 1.0
References: <156761599202.22808.13015902618373150935.idtracker@ietfa.amsl.com> <CA+RyBmV4_HaAC2=petia=SCh6wyAu+eRvbHtt5yKTioqn6jJNg@mail.gmail.com> <CALaySJLoUJX+4hA2inmGfG05Lf0kMv0QgsHTpS1_74+N0XzZvg@mail.gmail.com> <CA+RyBmUsJ3qF8V1B7tFTVc8hd1GUyMFWMn5PXah60H9aYJoXWw@mail.gmail.com> <CALaySJJqkzv+9BWppy16XL-xUqFnmcGJXFziawkVW+PF+4ZDyg@mail.gmail.com>
In-Reply-To: <CALaySJJqkzv+9BWppy16XL-xUqFnmcGJXFziawkVW+PF+4ZDyg@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 24 Sep 2019 10:19:04 -0700
Message-ID: <CA+RyBmUe8XXi4b-teDcvW22=sKC7yCBHC9wK2sTWb4Pe9gmFEw@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ippm-stamp@ietf.org, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, IPPM Chairs <ippm-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000005d2f3805934fbc9d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/yRilyr1RTS7MQ9jpt7PU7S0FQto>
Subject: Re: [ippm] Barry Leiba's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS)
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: Tue, 24 Sep 2019 17:19:39 -0000

Hi Barry,
thank you for your suggestions. Based on your comments, the authors decided
to add a new Operational Consideration section:
NEW TEXT:
5.  Operational Considerations

   STAMP is intended to be used on production networks to enable the
   operator to assess service level agreements based on packet delay,
   delay variation, and loss.  Using STAMP over the Internet, especially
   when STAMP test packets are transmitted with the destination UDP port
   number from the User Ports range, the possible impact of the STAMP
   test packets MUST be thoroughly analyzed.  The use of STAMP for each
   case MUST be agreed by users of nodes hosting the Session-Sender and
   Session-Reflector before starting the STAMP test session.

   Also, the use of the well-known port number as the destination UDP
   port number in STAMP test packets transmitted by a Session-Sender
   would not impede the ability to measure performance in an Equal Cost
   Multipath environment and analysis in Section 5.3 [RFC8545] fully
   applies to STAMP.

As the new section includes the discussion of using port numbers from the
User Ports range, the Security Considerations section has been updated to
avoid the duplication (please see the attached working version and the
diff).

Much appreciate your comments on the updated text.

Regards,
Greg

On Tue, Sep 10, 2019 at 5:51 PM Barry Leiba <barryleiba@computer.org> wrote:

> Thanks, Greg; I look forward to it.
>
> b
>
> On Tue, Sep 10, 2019 at 8:35 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
> >
> > Hi Barry,
> > thank you for the clarification. Yes, I agree that a new section can
> state it more clearly and give sufficient examples, as you've suggested.
> > I'll work on it and will share when it is ready.
> >
> > Regards,
> > Greg
> >
> > On Tue, Sep 10, 2019 at 5:15 PM Barry Leiba <barryleiba@computer.org>
> wrote:
> >>
> >> Hi, Greg, and thanks for the response.
> >>
> >> I think a minor rephrasing of the requirement isn't enough, really.
> >> As I understand it now, after other discussion, it's not that you need
> >> agreement from the users, but that you should put a paragraph (or
> >> maybe a separate section, to highlight the point) that says that this
> >> is not intended for use on the open Internet nor on production
> >> networks, and gives examples of what it *is* intended for... perhaps
> >> test networks, production networks during advertised maintenance
> >> windows, that sort of thing.  And then you don't need to say that the
> >> network's users need to agree, but simply that they need to be aware
> >> that performance testing will be happening during period X, and that
> >> disruptions to normal network operation are possible.  You'd need to
> >> come up with text that the working group agrees with, of course, but I
> >> think that if you do it will address my concern as well as some of the
> >> others that were raised.
> >>
> >> Does that make sense?
> >>
> >> Barry
> >>
> >> On Tue, Sep 10, 2019 at 5:01 PM Greg Mirsky <gregimirsky@gmail.com>
> wrote:
> >> >
> >> > Hi Barry,
> >> > thank you for your pointed question. Please find my explanation and
> the proposed updated below under the GIM>> tag.
> >> >
> >> > Regards,
> >> > Greg
> >> >
> >> > On Wed, Sep 4, 2019 at 9:53 AM Barry Leiba via Datatracker <
> noreply@ietf.org> wrote:
> >> >>
> >> >> Barry Leiba has entered the following ballot position for
> >> >> draft-ietf-ippm-stamp-07: Discuss
> >> >>
> >> >> When responding, please keep the subject line intact and reply to all
> >> >> email addresses included in the To and CC lines. (Feel free to cut
> this
> >> >> introductory paragraph, however.)
> >> >>
> >> >>
> >> >> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> >> for more information about IESG DISCUSS and COMMENT positions.
> >> >>
> >> >>
> >> >> The document, along with other ballot positions, can be found here:
> >> >> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
> >> >>
> >> >>
> >> >>
> >> >>
> ----------------------------------------------------------------------
> >> >> DISCUSS:
> >> >>
> ----------------------------------------------------------------------
> >> >>
> >> >> I'm sure this will be easy to either explain to me or re-phrase:
> >> >>
> >> >> Sections 4 and 6 both say something like "MUST be agreed by all
> users of the
> >> >> network".  What does that really mean?  How is it remotely possible
> to get
> >> >> agreement from all users of your network?  How is it remotely
> possible that
> >> >> they could understand what you're asking them to agree to?
> >> >
> >> >
> >> > GIM>> Yes, looking at the bigger picture, at the Internet rather than
> only at the domain where the test will be performed makes such condition
> unattainable. Would s/network/network domain where the test is planned/  so
> that it reads as:
> >> >
> >> > ... MUST be agreed by all users on the network domain where the test
> is planned ...
> >> >
> >> > make it clearer and the number of parties involved reasonable,
> practical?
> >> > As for what the could be the question users will be asked, I think
> that it should verify whether the application that has the port number
> assigned is active as the same number will be used as the destination port
> number in the STAMP test.
>