Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16

Alissa Cooper <alissa@cooperw.in> Wed, 08 February 2017 19:40 UTC

Return-Path: <alissa@cooperw.in>
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 638A0129FE3 for <lmap@ietfa.amsl.com>; Wed, 8 Feb 2017 11:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=gd0ZMW78; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=iB6uB+My
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 pI2fG6T-gK79 for <lmap@ietfa.amsl.com>; Wed, 8 Feb 2017 11:39:59 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2AE129FE4 for <lmap@ietf.org>; Wed, 8 Feb 2017 11:39:59 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8968D20B7D; Wed, 8 Feb 2017 14:39:58 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 08 Feb 2017 14:39:58 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=AnA6j5bAFqufbUJ2RkP1A0mcVuk=; b=gd0ZMW 78r8ujs4CNM9bDtxjyTbKxiN04cETsOS+KJcDrvZ9EfzToWoruWPXx1xfS4zmWMD 5DK/vqSwObMGyvG0gpMTkav+CIkM0PCsZx6DMkI05Z3s6l64C8tC7AyZeFJdQh+Z JJGi1fLQZAkelNmVdKG/ZJmoiDHCTHlTPKvtQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=AnA6j5bAFqufbU J2RkP1A0mcVuk=; b=iB6uB+MytvkfTAF6UKSC0eSFfQ4vbVU+PA0wTCrvAvsV4l hYw8Cyn258I9v43RZ89gp0L6HxBSIqRCkTLJgXQHLpSxrZA1aNK+Zx4PFa7ZjNH3 nKNgrGv69D+jI/d5+LvJ3b1+Iz2WyQBzjtL7GDbeu2gg/0gAcnJ2ucoAsB7V4=
X-ME-Sender: <xms:DnSbWGB4hjDzZX4Ufbj1mjiyo9pUawgIkn1xSDxA5894jzU_bgYilQ>
X-Sasl-enc: EjkJ5oEzebBvR73KRhDH4rC2EPxShiTAkQc+PZu6cNXr 1486582798
Received: from dhcp-10-150-9-221.cisco.com (unknown [173.38.117.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 303FB7E06B; Wed, 8 Feb 2017 14:39:58 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_86B20CEC-BD07-4F18-8F11-C72A21342C9D"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in>
Date: Wed, 8 Feb 2017 14:39:58 -0500
Message-Id: <AEBB4343-671F-4EFF-9B65-1A65B76B489C@cooperw.in>
References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> <20170131194757.GA78531@elstar.local> <B05AB715-8270-4F89-92A2-0EB810E07A8C@cooperw.in> <20170208152353.GI98457@elstar.local> <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/eGgryTl1aAF-S6w5aCmdzZRXv3k>
Cc: lmap@ietf.org
Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 08 Feb 2017 19:40:03 -0000

> On Feb 8, 2017, at 2:38 PM, Alissa Cooper <alissa@cooperw.in> wrote:
> 
>> 
>> On Feb 8, 2017, at 10:23 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>> 
>> On Tue, Feb 07, 2017 at 10:26:30AM -0500, Alissa Cooper wrote:
>>> 
>>>> On Jan 31, 2017, at 2:47 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>> 
>>>> On Tue, Jan 31, 2017 at 09:15:52AM -0500, Alissa Cooper wrote:
>>>>> 
>>>>>> On Jan 31, 2017, at 4:44 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>>>>> 
>>>>>> 
>>>>>> The status reports go to the LMAP controller, so I do not really see
>>>>>> why there is a specific risk since the controller has access to the
>>>>>> device ID anyway.
>>>>> 
>>>>> I still am missing what is the rationale for sending the device ID in the status reports. I thought the agent ID was meant to uniquely identify the MA.
>>>>> 
>>>> 
>>>> So here we go. I propose the following change:
>>>> 
>>>> - The ma-status-agent-id becomes optional.
>>>> - The ma-status-device-id becomes mandatory again.
>>>> 
>>>> Rationale:
>>>> 
>>>> If a device does not yet have an MA-ID, then the device-id must be
>>>> accessible such that the controller can configure an MA-ID.
>>> 
>>> Section 3.1 says:
>>> 
>>> "The MA may be pre-configured with an MA ID, or may use a Device ID in
>>>  the first Controller contact before it is assigned an MA ID.  The
>>>  Device ID may be a MAC address or some other device identifier
>>>  expressed as a URI.  If the MA ID is not provided at this stage then
>>>  it must be provided by the Controller during Configuration.”
>>> 
>>> Why would an MA be sending a status report before configuration?
>>> 
>> 
>> The ma-status-obj models status information, it is not modeling a
>> status report. I think the reason for having the device-id in the
>> status information is that this is the only way to obtain it if it is
>> not configured.
> 
> Ok. But in a setup where the controller doesn’t actually need the device-id (because the agent-id is pre-configured and the controller uses that to uniquely identify the MA), this requires the device-id to be divulged to the controller unnecessarily. That case could be accommodated by making both the agent-id and the device-id optional and specifying that the device-id should be provided if it was not provided in pre-configuration.

Actually, that last bit should say: if it was not provided in pre-configuration and if the MA has no agent-id.

Alissa

> 
> Alissa
> 
>> 
>> /js
>> 
>> -- 
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> 
> _______________________________________________
> lmap mailing list
> lmap@ietf.org <mailto:lmap@ietf.org>
> https://www.ietf.org/mailman/listinfo/lmap <https://www.ietf.org/mailman/listinfo/lmap>