Re: [lmap] Feedback on draft-eardley-lmap-terminology

<philip.eardley@bt.com> Wed, 24 July 2013 08:00 UTC

Return-Path: <philip.eardley@bt.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 1FB2711E8396 for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 01:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.854
X-Spam-Level:
X-Spam-Status: No, score=-102.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 3xiCoJHmsCrD for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 01:00:39 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 81B1B11E80D1 for <lmap@ietf.org>; Wed, 24 Jul 2013 01:00:38 -0700 (PDT)
Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 24 Jul 2013 09:00:35 +0100
Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.253]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 24 Jul 2013 09:00:35 +0100
From: philip.eardley@bt.com
To: bclaise@cisco.com, lmap@ietf.org
Date: Wed, 24 Jul 2013 09:00:34 +0100
Thread-Topic: [lmap] Feedback on draft-eardley-lmap-terminology
Thread-Index: Ac6G9kJL9LoTtC34Rxe0kMCmPNNKaQBSjDvA
Message-ID: <9510D26531EF184D9017DF24659BB87F35B7CD1AF5@EMV65-UKRD.domain1.systemhost.net>
References: <51ED59B3.3040701@cisco.com>
In-Reply-To: <51ED59B3.3040701@cisco.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F35B7CD1AF5EMV65UKRDdoma_"
MIME-Version: 1.0
Subject: Re: [lmap] Feedback on draft-eardley-lmap-terminology
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 08:00:43 -0000

Benoit,

Thanks for your comments!

I agree with you that "key assumption" is more accurate than "consensus"

I agree that Section 4, "Commentary and notes" wanders into the territory of the Framework. At some point soon, as you say, terminology will be merged into a framework i-d, so this will need to be fixed. I'll try to ensure that the merged doc keeps some text that explains the terminology a bit (personally I find terminology on its own hard to understand, without some accompanying explanation)

Ps your registry i-d is now on my reading list, thanks

<< I'm not too clear if the Measurement Peer are dedicated test server, or real server (google.com, SIP server, youtube)>>
The Measurement Peer could be either. It's up to the operator of the measurement system to decide what Measurement Methods the Measurement Peer needs and exactly how they're implemented.

Thanks
phil

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: 22 July 2013 17:12
To: lmap@ietf.org
Subject: [lmap] Feedback on draft-eardley-lmap-terminology

Dear authors,

A couple of high level points.
One of the goal behind this email is to generate discussions, either on the list, or during the IETF meeting next week.

-

   The consensus is that the LMAP working group should assume that a

   Measurement Agent receives Instruction from only a single Controller

   at any point in time (however it may Report to more than one

   Collector).
Instead of consensus, I would use "a key assumption"
The charter says:
A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator).
-
Same remark for the term "consensus" in

   The job of a Bootstrap Protocol is to provide an automated way to

   associate a Measurement Agent to its Controller, including

   authentication credentials.  Similarly, there should be a way to pull

   the plug on rogue Measurement Agents.  The current consensus on the

   LMAP mailing list is that the working group should define the

   bootstrap process but not a protocol.
The charter mentions:
"The management protocol to bootstrap the MAs in measurement devices is out of scope of the LMAP charter."
-
I would like to draw your attention to claise-ippm-perf-metric-registry<http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry>, which will be presented in IPPM.

-
I'm not too clear if the Measurement Peer are dedicated test server, or real server (google.com, SIP server, youtube)
Do the Measurement Peer need the functionality of an IP SLA responder or a TWAMP controller?
This might be clarified in the use case draft.

-
This draft is good shape, but it's really a mix of terminology and framework concepts.
I'm glad that there is a single delivery in the charter for both:
"1. The LMAP Framework - provides common terminology, basic architecture elements, and justifies the simplifying constraints"


Regards, Benoit