Subject: [ippm] Stephen Farrell's No Objection on draft-ietf-ippm-rate-problem-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 04 Feb 2015 06:22:22 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-ippm-rate-problem-09: No Objection

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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I'm not clear why it's a good plan for this document to
state a bunch of MUST level requirements on protocol
specifications, but I assume if that were problematic then
this informational document would be ignored and if it's not
a problem that's fine:-). Including that kind of thing can
lead to unnecessary arguments though so I wondered. For
example, on page 8 it (I think) says that protocols MUST
allow for control (by whom?) of payload lengths, which is not
something I see in typical speed test tools that'd be used by
massive numbers of users, or at least that's not exposed via
a UI that I can see.

- section 6: surely this needs to note the problem that there
can be privacy issues with (esp. multiple uses) of
measurement - e.g. if I use my phone in different places to
do similar measurements I may be open to some new forms of
tracking. Why not note this? Why is there no "MUST NOT"
requirement from this?  (Assuming you stick with including
such.) RFC2330 does recognise privacy for example, so why not
here too? BTW I don't think I see privacy issues considered
in 4656 or 5357, but I only had a very quick look. (This
would be a DISCUSS from me if this were a protocol document,
but I'm ok to just leave it as a comment on one like this.)

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 4 Feb 2015 10:40:31 -0500

Hi Stephen,
replies below,
Al

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Wednesday, February 04, 2015 9:22 AM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [ippm] Stephen Farrell's No Objection on draft-ietf-ippm-rate-
> problem-09: (with COMMENT)
> 

That's exactly right, deployment of speed-test for the masses
necessarily protects users from the details. Nothing precludes
developing a test protocol controlled via CLI on both ends.
"whom" is the person or script or configuration providing
run-time parameters to the controlling host - the test protocol
has to respond to the config/request and possibly negotiate with the
far-end to achieve agreement. These are requirements on protocol
features, applicable to several different test/control protocols.

> but I'm ok to just leave it as a comment on one like this.)

I'm inclined to start citing the Privacy Section (8) of the LMAP
Framework draft as the "best answer so far" for measurement 
protocols.  I'll add that reference.  You're right that 4656
and 5357 pre-date Snowden and the aftermath, but so does the text
of section 6, IIRC.

I also feel that "using my phone in different places" is a matter 
for the implementations of protocols that follow this memo, and
mostly for test methodologies that focus on the mobile environment.
But we're not there yet.  I simply suggest we put the privacy 
considerations where they are most relevant.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Feb 2015 15:48:15 +0000

Hi Al,

Those are fine responses but a bit more at the bottom,

> and 5357 pre-date Snowden and the aftermath, but so does the text

So I don't know if that'd hold you up or not, but if it would,
and you'd prefer to not be held up then as an alternative you
could just say that protocols in this space need to properly
consider privacy. But your call.

> for the implementations of protocols that follow this memo, 

Well, not quite - there are also protocol design issues, e.g. if
a protocol adds some form of identifier that's used across more
than one invocation. A protocol that did not do that would be
more likely to allow for more privacy friendly implementation.

But yes, the implementation or deployment of even a well
designed (from the privacy POV) protocol could make things
worse.

> and

I'm fine with that (and that's exactly why this wasn't a blocking
DISCUSS). OTOH, there's also no harm in noting the issues here too
esp since as you correctly say those weren't considered that big a
deal when the RFCs that are referred to here were written.

Cheers,
S.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 4 Feb 2015 19:52:03 -0500

Hi Kathleen, please see below:

> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Wednesday, February 04, 2015 6:37 PM
> To: MORTON, ALFRED C (AL)
> Cc: Stephen Farrell; The IESG; [email-masked]; draft-ietf-ippm-rate-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [ippm] Stephen Farrell's No Objection on draft-ietf-ippm-
> rate-problem-09: (with COMMENT)
> 
> Hi Al and Stephen,
> 
> On Wed, Feb 4, 2015 at 10:40 AM, MORTON, ALFRED C (AL) <[email-masked]>
> wrote:
> > Hi Stephen,
> > replies below,
> > Al
> >
> I'm wondering if some rephrasing in the introduction might help with
> this point.  Since I've done some testing at an ISP where I had to set
> lengths and patterns for data used in performance testing and then a
> few years later worked at a performance company and was involved with
> testing web site access with simulated sessions, I can certainly see
> the utility of this draft.
> 
> What if there was a description that this might be used as the
> underlying mechanisms for simulated traffic scenarios from an
> application or CLI?  Would that help clarify what this looks like to
> the user described earlier in the draft?  I may be reading into it
> from my own experience.

Although the figure in the Intro identifies the users and their devices,
it's mostly to anchor the geography.  Also, this problem statement is 
at least two steps removed from the eventual systems that users might 
interact with to make measurements - protocol development/enhancement
has to follow, then active measurement methods that the protocol would 
enable, then implementation in a system. I'm willing to append this text
to the last paragraph of the Intro, if it helps:

The eventual protocol solutions to this problem (and the systems that 
utilize the protocol) may not directly involve users, such as when 
tests reach from the Infrastructure to a service-specific device, 
such as a residential gateway. However, no aspect of the problem 
precludes users from developing a test protocol controlled via 
command line interfaces on both ends. Thus, a very wide range of 
test protocols, active measurement methods and system solutions 
are the possible outcomes of this problem statement.

> Could a statement be added to discourage the collection of identifiers
> from applications or devices that use the methods described in this
> draft to protect the privacy of the end user?  If the purpose is for
> an end user to get the results, does to point in the network they use
> for testing need to collect anything? I would think not and am making
> an assumption that the model is of tools used to test speed from an
> end user.  But maybe I missed something.

I realize I'm loading up a careful IESG review for the LMAP Framework, 
but let it be so. I'd rather have a canonical reference to point to 
in the future.

I added this text in the middle of the Security Considerations section:

Privacy considerations for measurement systems, particularly when Internet users participate in the tests in some way, are described in "I-D.ietf-lmap-framework"

thanks and regards,
Al

> Thanks,
> Kathleen
> --
> Best regards,
> Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Feb 2015 18:36:57 -0500

Hi Al and Stephen,

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Feb 2015 20:22:20 -0500

Hi Al & Stephen,

Sent from my iPhone

> On Feb 4, 2015, at 7:52 PM, "MORTON, ALFRED C (AL)" <[email-masked]> wrote:
> 

These were Stephen's comments, but I do like the suggested text to clarify these points further.

Thank you,
Kathleen