[lmap] comments on draft-eardley-lmap-framework-02

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 23 July 2013 13:02 UTC

Return-Path: <dromasca@avaya.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 8EE5311E810A for <lmap@ietfa.amsl.com>; Tue, 23 Jul 2013 06:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 rvDbsoUjE0rK for <lmap@ietfa.amsl.com>; Tue, 23 Jul 2013 06:02:28 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 05D5A11E80FD for <lmap@ietf.org>; Tue, 23 Jul 2013 06:02:27 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigFAOh97lGHCzI1/2dsb2JhbABbgmUhgQXAOoERFnSCJgEBAxIoUQEVBRAUQhcPAQQbGoduAZd1hEKcJo9ig0huA54jiweDEoIq
X-IronPort-AV: E=Sophos;i="4.89,727,1367985600"; d="scan'208";a="21186164"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Jul 2013 09:02:20 -0400
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Jul 2013 08:56:05 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Tue, 23 Jul 2013 09:02:19 -0400
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "lmap@ietf.org" <lmap@ietf.org>
Thread-Topic: comments on draft-eardley-lmap-framework-02
Thread-Index: Ac6HpNxWSlKt/J3PRHm+kNP0wHNi/g==
Date: Tue, 23 Jul 2013 13:02:18 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1287E1FE@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [lmap] comments on draft-eardley-lmap-framework-02
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: Tue, 23 Jul 2013 13:02:34 -0000

Hi,

Here are a few comments at the first reading of draft-eardley-lmap-franework-02. I appreciate that this is one of the pre-wg-document contributions, so my comments and questions are rather high level than trying to point to details. 

1. I am confused by the way the I-D describes the interaction between controllers and MAs. In Section 3.2 I see: 

To avoid problems with NAT and firewalls, it is likely that the MA
   'pulls' the configuration from its Controller, as identified by the
   Initialiser.

But then in the diagram in Figure 1 the arrow points from the Controller to the MA, and later the examples of possible protocols in Section 5.3 include such 'push' protocols as SNMP and NETCONF. 

2. I have a problem imagining what the 'Initialiser' is. Is it a task (running where?) aiming to ensure consistent configuration of controllers in an LMAP system. Or another 'box' in the architecture, part of an hierarchical system, a 'box' not represented because it is out of the LMAP scope? If the later I would prefer to add it to the diagram, maybe together with the other non-LMAP entities (Subscriber Parameter Database, Results Database) so that we can have a full picture of the whole system, with clear representation of what is in scope for LMAP. 

3. Do we also need to include in the diagram (and discussion) some kind a certificate authority to ensure that controllers and MAs, MAs and peers, MA and collectors, are authenticated to each other, as the security considerations section demands. 

4. In a couple of instances OAM is wrongly expanded as Operations, Administrations and Management, and not as per BCP 161. 

5. In Section 5.1 there are a few instances where some procedures or blocks are being defined as 'out (or beyond) the scope of the IETF'. It would be more correct to say 'out of scope for LMAP' as we can make statements about what we do (or do not do) in LMAP but not for the IETF as a whole. 

Thanks and Regards, 

Dan
(as contributor)