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

[Greg Mirsky <[e-mail]>]

Hi Barry,
great catch, thank you!
I've posted the new version
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-08>.

Kind regards,
Greg

On Tue, Sep 24, 2019 at 10:29 AM Barry Leiba <[e-mail]>
wrote:

> Greg, this looks good, and many thanks for that!  Minor typo:
>
>    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.
>
> It should say "When using STAMP over the Internet..."
>
> I'll clear the DISCUSS when this is posted as a draft revision.
>
> Barry
>
> On Tue, Sep 24, 2019 at 1:19 PM Greg Mirsky <[e-mail]> wrote:
> >
> > 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 <[e-mail]>
> wrote:
> >>
> >> Thanks, Greg; I look forward to it.
> >>
> >> b
> >>
> >> On Tue, Sep 10, 2019 at 8:35 PM Greg Mirsky <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
> 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 <
> [e-mail]> 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.
>