[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.
- [ippm] Alissa Cooper's Discuss on draft-ietf-ippm… Alissa Cooper
- Re: [ippm] Alissa Cooper's Discuss on draft-ietf-… MORTON, ALFRED C (AL)
- Re: [ippm] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [ippm] Alissa Cooper's Discuss on draft-ietf-… MORTON, ALFRED C (AL)
- Re: [ippm] Alissa Cooper's Discuss on draft-ietf-… Spencer Dawkins at IETF