[Coma] (no subject)

<tayeb.benmeriem@orange.com> Wed, 06 June 2012 20:04 UTC

Return-Path: <tayeb.benmeriem@orange.com>
X-Original-To: coma@ietfa.amsl.com
Delivered-To: coma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C2F21F84B6 for <coma@ietfa.amsl.com>; Wed, 6 Jun 2012 13:04:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.717
X-Spam-Level:
X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, UNPARSEABLE_RELAY=0.001]
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 Z80W1qL3x3TM for <coma@ietfa.amsl.com>; Wed, 6 Jun 2012 13:04:46 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0BC11E80B2 for <coma@ietf.org>; Wed, 6 Jun 2012 13:04:46 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id ED69A2DC4CA for <coma@ietf.org>; Wed, 6 Jun 2012 22:04:44 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D2D8A35C045 for <coma@ietf.org>; Wed, 6 Jun 2012 22:04:44 +0200 (CEST)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 6 Jun 2012 22:04:44 +0200
From: <tayeb.benmeriem@orange.com>
To: "coma@ietf.org" <coma@ietf.org>
Thread-Index: Ac1EH5yYe7jjov2hS8OHDdlrqb9W9A==
Date: Wed, 6 Jun 2012 20:04:43 +0000
Message-ID: <21853_1339013084_4FCFB7DC_21853_10870_1_11027135CD0DCE41B9C193E3D7257738EE73@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_11027135CD0DCE41B9C193E3D7257738EE73PEXCVZYM12corporate_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.6.192415
Subject: [Coma] (no subject)
X-BeenThere: coma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Management of Constrained Networks and Devices <coma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/coma>, <mailto:coma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/coma>
List-Post: <mailto:coma@ietf.org>
List-Help: <mailto:coma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/coma>, <mailto:coma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jun 2012 20:04:48 -0000

Dear all,


It's an excellent idea to investigate this domain. From my perspective, the first requirements related to the management aspect of such devices in their particular environment are auto-configuration which is addressed by design. When it comes to standardization for sure there is some work to do accordingly.



Within operator's environment, could be Fixed or Mobile networks, the Home Gateway and its attached devices, BBF protocol TR-69 is adopted and used for managing (configuration) of HomeNodeB and HomeeNodeBs. Netconf and its associated modeling language Yang have reached a maturity and are implemented in vendors' solutions. Some extensions are considered in order to address management aspects beyond simple configuration.



The requirements and associated solutions should be business driven, and then we address the technical solutions. That means, we should look at the vertical market needs (Health, Digital Home, ...) in terms of expectation of SLAs. Then the question is how to translate these SLAs into SLOs, metrics and how to track, measure, collect and report them (the needed management models and tools) in order to meet the SLAs.



The question related to the management is 3-fold:

- Which protocol: should we adapt the existing ones (TR-69, Netconf, ) to this constrained devices and network, or should designnew ones as IETF did for routing protocols.

- Which interface:  We should not re-invente the wheel

- Which Data model:  We should not re-invente the wheel.



So, this first draft should contain at least the following sections

-    Problem statement

-    Business needs and requirements

-    Technical requirements

-    Gap analysis: missing pieces to be covered by IETF and other SDOs

-    New topics to be investigated





Regards



Tayeb




_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.