[ippm] Alissa Cooper's Discuss on draft-ietf-ippm-2679-bis-04: (with DISCUSS and COMMENT)

"Alissa Cooper" <alissa@cooperw.in> Tue, 18 August 2015 19:14 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5391A1AD9; Tue, 18 Aug 2015 12:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level:
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no
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 LFp04_cVhsIh; Tue, 18 Aug 2015 12:14:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2334B1A1AF6; Tue, 18 Aug 2015 12:14:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150818191431.10251.89743.idtracker@ietfa.amsl.com>
Date: Tue, 18 Aug 2015 12:14:31 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/ippm/1CZ23K2eQwGMuPmmCs5Il_-5EdU>
Cc: Bill Cerveny <ietf@wjcerveny.com>, ippm-chairs@ietf.org, draft-ietf-ippm-2679-bis@ietf.org, ippm@ietf.org
Subject: [ippm] Alissa Cooper's Discuss on draft-ietf-ippm-2679-bis-04: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Aug 2015 19:14:32 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-ippm-2679-bis-04: 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-2679-bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am confused about the last sentence in this methodology step in Section
3.6:

"+ At the Src host, select Src and Dst IP addresses, and form a test
   packet of Type-P with these addresses.  Any 'padding' portion of the
   packet needed only to make the test packet a given size should be
   filled with randomized bits to avoid a situation in which the
   measured delay is lower than it would otherwise be due to compression
   techniques along the path.  Note that use of transport layer
   encryption will counteract the deployment of network-based analysis
   and may reduce the adoption of network-based payload optimizations
   like compression."

I don't understand what is implied about the relationship between
transport layer encryption and one-way delay measurements. I thought the
metric defined in this document was generally used for end-to-end
measurement of delay, so I don't understand what "network-based analysis"
has to do with this methodology step. Is the implication that if the
measurement packet is encrypted at the transport layer that delay will
change? If that is true, isn't the metric itself agnostic to that
consideration -- that is, couldn't that be precisely what the person
doing the measurements wants to measure? I could quibble with the
conclusions of the note itself (e.g., increased transport layer
encryption may change but not necessarily reduce network-based "analysis"
of various sorts), but mainly I do not understand how it relates to the
specification of the metric.

Unfortunately the rationale given in Section 1 ("Added text recognizing
the impending deployment of transport layer encryption in section 3.6")
does not clarify this either. What impending deployment is this
referencing?


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

>From Section 6:

"The privacy concerns of network measurement are limited by the active
   measurements described in this memo.  Unlike passive measurements,
   there can be no release of existing user data."

I realize this is text from RFC 2679, but I think it would be good to
update it to reflect what has been learned since the publication of that
document. The mere fact that a host is involved in conducting
measurements could well be considered privacy-sensitive in some contexts.
And a collection of measurements about a host, even active measurements,
could leak information about the host's connectivity/availability/etc. if
not appropriately safeguarded. I don't think this changes the protocol
requirements for this document, but I do think the text above should note
these aspects (perhaps similar to how it's done in
<https://tools.ietf.org/html/draft-ietf-lmap-framework-14#section-8.3>).
It's not quite correct to say there can be no release of existing user
data.