[lmap] Feedback on draft-eardley-lmap-framework-01

"Weil, Jason" <jason.weil@twcable.com> Wed, 24 July 2013 22:05 UTC

Return-Path: <jason.weil@twcable.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5C011E8275 for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 15:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level:
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gRbHwqkzhNy for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 15:05:43 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E392511E815E for <lmap@ietf.org>; Wed, 24 Jul 2013 15:05:42 -0700 (PDT)
X-SENDER-IP: 10.136.163.14
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos; i="4.89,737,1367985600"; d="scan'208,217"; a="112560240"
Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Jul 2013 18:04:29 -0400
Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 24 Jul 2013 18:05:41 -0400
From: "Weil, Jason" <jason.weil@twcable.com>
To: "lmap@ietf.org" <lmap@ietf.org>
Date: Wed, 24 Jul 2013 18:05:40 -0400
Thread-Topic: Feedback on draft-eardley-lmap-framework-01
Thread-Index: Ac6Iue+JkB9mX20GQROv2rsQmPcjnQ==
Message-ID: <CE15C7F4.191A4%jason.weil@twcable.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CE15C7F4191A4jasonweiltwcablecom_"
MIME-Version: 1.0
Subject: [lmap] Feedback on draft-eardley-lmap-framework-01
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lmap>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 22:05:50 -0000

Here are my comments and questions on the draft:

Section 1. [use-cases]
Regulators: I would drop the word 'several' from this description. It reads as if regulators are targeting certain providers purposefully out of a group which is not typically the case.
---
The example given in Diversity seems to be another example supporting the interoperability benefits that come with the earlier bullet on Standardization.  A MA on a CPE router and another MA on a WiFi device behind the router or a MA running as a software client on a laptop/desktop might be  a better example?
---
Section 2.


   The MA functions are implemented either in specialised hardware or as
   code on general purpose devices like a PC, tablet or smartphone.  The
   Measurement Peer may be an LMAP device or a normal, non-LMAP device
   (for example if the MA measures the time for a DNS response or a
   webpage download from www.example.com).


A Measurement Peer is an LMAP functional element. It would seem to me that as long as an entity performs in the role of a Measurement Peer it would be considered an LMAP device whether or not it was purpose built for a single test or simply performing as a Measurement Peer based on its normal operational role such as a recursive resolver. As such I don’t believe a Measurement Peer would ever be considered a non-LMAP device if it was being used for a test by the MA.

--

Section 3.

3.2. Each MA may only have a single Controller at any point in time – The 'may' in this sentence makes me wonder where the constraint exists. Is the constraint that it must only take direction from a single Controller at any given time?
--
The topic on NAT an firewalls suggesting a pull model may be better as a separate constraint topic by itself.


Thanks,

Jason

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.