Re: [vnrg] Some definitions and way forward

Roland Bless <roland.bless@kit.edu> Thu, 11 August 2011 14:51 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: vnrg@ietfa.amsl.com
Delivered-To: vnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F3821F8AFC for <vnrg@ietfa.amsl.com>; Thu, 11 Aug 2011 07:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.056
X-Spam-Level:
X-Spam-Status: No, score=-6.056 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 xoF8VQpZho9I for <vnrg@ietfa.amsl.com>; Thu, 11 Aug 2011 07:51:10 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 18A0F21F8AEA for <vnrg@irtf.org>; Thu, 11 Aug 2011 07:51:06 -0700 (PDT)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1QrWba-00052b-Un; Thu, 11 Aug 2011 16:51:36 +0200
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1QrWba-0006di-QI; Thu, 11 Aug 2011 16:51:30 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 59D19A804C7; Thu, 11 Aug 2011 16:51:30 +0200 (CEST)
Message-ID: <4E43EC71.9030403@kit.edu>
Date: Thu, 11 Aug 2011 16:51:29 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu><EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E39A744.8010508@kit.edu><EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><4E3A59FE.1090809@kit.edu><EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E3B09D2.70202@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D307A@FIESEXC035.nsn-intra.net> <4E3BA5DE.6010204@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D31C7@FIESEXC035.nsn-intra.net> <4E3BCE47.2000805@kit.edu> <EFDB2B5417263843B5077E12666D8C1018FD2A4C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
In-Reply-To: <EFDB2B5417263843B5077E12666D8C1018FD2A4C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1313074296.206639000
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Some definitions and way forward
X-BeenThere: vnrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Virtual Networks Research Group \(VNRG\) discussion list" <vnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/vnrg>, <mailto:vnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/vnrg>
List-Post: <mailto:vnrg@irtf.org>
List-Help: <mailto:vnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/vnrg>, <mailto:vnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2011 14:51:10 -0000

Hi Dimitri,

sorry for the late reply, but I was traveling...

> The problem is not the inclusion of "control functionality" into the
> architectural related definitions but the assignment and distribution of
> control roles to stakeholders as part of these definitions (cf. VNO,
> VNP, InP, etc.). At this stage, it is important to define WHAT is to be
> controlled and not WHO controls what (and the term, e.g., Provider is
> basically defining the WHO).

Ok, so far agreed, but IMHO it's difficult to come up with control
interfaces if you are not considering the controlling entity/party,
i.e., the user of this control interface.
Maybe I'll try a second round of definitions without these roles.

Regards,
 Roland