Return-Path: 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 474E021F86B6 for ; Tue, 17 Jul 2012 09:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] 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 2CT8Vhmul9xq for ; Tue, 17 Jul 2012 09:26:57 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBE321F864B for ; Tue, 17 Jul 2012 09:26:57 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1092173pbc.31 for ; Tue, 17 Jul 2012 09:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nyt1mHw3zICRKn0/afLN2q3jA041XndtLAzHohWGsiQ=; b=ynMeLkL97+XgVtKFYiUmhTV4kCzo8v4sqC7w95Z/CfeMwyvtCVYxq15Ax79wEUiAmT 0PfDO20F3BVZ9FTm+s5y7LPJ5M4nA/Hozt9zLImzK/bztfvSQSPGrQpKijb5rT1vrWNW k1c5cKoYN/WEeIk8acMiEOmM1i6I4dMa/bWZw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nyt1mHw3zICRKn0/afLN2q3jA041XndtLAzHohWGsiQ=; b=KpmcZn94yym6SX6Elc/e0CQyKmOYAJ23iGDwAZuskfYh4lM5WLU3zTC4+Z/scbjCo6 6ebVsS70Ldgsv/Lv1zdJzHhZpUl5nyT3BVv6T/rre5G1dx9Jf+d6wRlmkmhAan+VerWv d+bcO/svtc/m0pVnTJI3QyJTTFdLGt94pBg952ZMKmYbsp8v/f/pCtuat8nMdGtVjIms JH0czU3WyG1DgHMsLZZ/0SxmN9SjxvAJ8kVsgaARkUEhOq4dRjyV5FwQkHT+WPv8g75K ZJD8p6a0s/sLesW3QBQpAXh9v3ryniEsLbbRT39mWvc/jssHJ/FOBW52gDZyMLOuH9ME KMzQ== MIME-Version: 1.0 Received: by 10.68.200.104 with SMTP id jr8mr208178pbc.9.1342542464751; Tue, 17 Jul 2012 09:27:44 -0700 (PDT) Received: by 10.66.26.207 with HTTP; Tue, 17 Jul 2012 09:27:44 -0700 (PDT) In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640405EBA2@DEMUEXC006.nsn-intra.net> References: <83C941F7F59F3F42AC017AD1E650546206BFB090@GDUKADH850.uk1.r-org.net> <80A0822C5E9A4440A5117C2F4CD36A6403DFB8BD@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A640405EBA2@DEMUEXC006.nsn-intra.net> Date: Tue, 17 Jul 2012 09:27:44 -0700 Message-ID: From: Ulrich Herberg To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=047d7b10cff3b5168804c50906f8 X-Gm-Message-State: ALoCoQlXA9P5kCM5DyHXnVTvWEyB0+NOLF3VbWPMUAM2MxomvZPDD/U0XjH7Yxf4jfewZBr+PelR Cc: Jonathan.Hansford@generaldynamics.uk.com, "ext Pascal Thubert \(pthubert\)" , coma@ietf.org Subject: Re: [Coma] Reprogramming Protocols X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 16:26:58 -0000 --047d7b10cff3b5168804c50906f8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I agree with Mehmet. I don't see how this is related to management of networks and devices. RPL is a routing protocol, not a network management protocol. Best Ulrich On Tue, Jul 17, 2012 at 3:09 AM, Ersue, Mehmet (NSN - DE/Munich) < mehmet.ersue@nsn.com> wrote: > Dear Pascal,**** > > ** ** > > I am wondering whether this has to do with network management. I think we > should differentiate between the management and operation of the network.= * > *** > > ** ** > > A programmable routing functionality which improves the operational > behavior might be useful but not in our focus. Coma(n) especially raises > the questions on and discusses the use cases and requirements for the > management of networks with constrained devices.**** > > ** ** > > I can imagine policy management as a requirement on the management of > networks with constrained devices. If you think so, please formulate it a= nd > describe the use case from the application pov. However, I think optimizi= ng > routing functionality is on another level.**** > > ** ** > > Please read also the problem statement in -01 draft which hopefully > describes the focus of Coma(n): > http://tools.ietf.org/html/draft-ersue-constrained-mgmt-01 **** > > Comments are welcome.**** > > ** ** > > Cheers, > Mehmet **** > > ** ** > > *From:* ext Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > *Sent:* Tuesday, July 17, 2012 8:48 AM > *To:* Ersue, Mehmet (NSN - DE/Munich); > Jonathan.Hansford@generaldynamics.uk.com; coma@ietf.org > *Subject:* RE: [Coma] Reprogramming Protocols**** > > ** ** > > Hum=85 I do not necessarily agree.**** > > ** ** > > RPL, which is probably a protocol of choice for such environment, defines > Objective functions that handle metric interpretation and some logic to t= ie > multiple metrics and policies together. **** > > I=92d think that as long as we stay at the abstract (interface) level we = can > push some hints to an existing OF to twist its behavior, and tell RPL to > support a new instance based on a new OF that needs to be installed.**** > > ** ** > > There is probably a way to define:**** > > - an abstract interface between RPL and the OF so that we can dynamically > plug an OF in.**** > > - abstract behavior specifications on which metric are supported and how > they are handled (eg additive, weighted, etc) by an existing OF so we can > tune the graph generation.**** > > - abstract policies specifications so we can control peering, size, power= , > you name it.**** > > ** ** > > What do you think?**** > > ** ** > > Cheers,**** > > ** ** > > Pascal**** > > ** ** > > *From:* coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] > *On Behalf Of *Ersue, Mehmet (NSN - DE/Munich) > *Sent:* vendredi 8 juin 2012 15:02 > *To:* Jonathan.Hansford@generaldynamics.uk.com; coma@ietf.org > *Subject:* Re: [Coma] Reprogramming Protocols**** > > ** ** > > Hi Jonathan,**** > > ** ** > > this could be seen under the SW/firmware distribution, however > reprogramming protocol code is a device specific logic and not a manageme= nt > task.**** > > ** ** > > Cheers, > Mehmet **** > > ** ** > > *From:* coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] *On Behalf > Of *ext Jonathan.Hansford@generaldynamics.uk.com > *Sent:* Friday, June 08, 2012 2:38 PM > *To:* coma@ietf.org > *Subject:* [Coma] Reprogramming Protocols**** > > ** ** > > Hi,**** > > ** ** > > One thing that hasn=92t yet been mentioned (unless I missed it) is the is= sue > or reprogramming protocols for adding new applications or > modifying/patching existing applications/firmware. I imagine this is of > particular interest in Sensor Nets but may also be beneficial in other > scenarios. Will this also be considered within coma?**** > > ** ** > > Thanks,**** > > ** ** > > Jonathan**** > > ** ** > ------------------------------ > > This email and any files attached are intended for the addressee and may > contain information of a confidential nature. If you are not the intended > recipient, be aware that this email was sent to you in error and you shou= ld > not disclose, distribute, print, copy or make other use of this email or > its attachments. Such actions, in fact, may be unlawful. In compliance wi= th > the various Regulations and Acts, General Dynamics United Kingdom Limited > reserves the right to monitor (and examine for viruses) all emails and > email attachments, both inbound and outbound. Email communications and > their attachments may not be secure or error- or virus-free and the compa= ny > does not accept liability or responsibility for such matters or the > consequences thereof. General Dynamics United Kingdom Limited, Registered > Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and > Wales No: 1911653. **** > > _______________________________________________ > Coma mailing list > Coma@ietf.org > https://www.ietf.org/mailman/listinfo/coma > > --047d7b10cff3b5168804c50906f8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

I agree with Mehmet. I don't see how this is related to mana= gement of networks and devices. RPL is a routing protocol, not a network ma= nagement protocol.

Best
Ulrich

On Tue, Jul 17, 2012 at 3:09 AM, Ersue, Mehmet (NSN - DE/Munich) <mehm= et.ersue@nsn.com> wrote:

Dear Pascal,

=A0

= I am wondering whether this has to do with network = management. I think we should differentiate between the management and oper= ation of the network.

=A0

=

A programmable routing funct= ionality which improves the operational behavior might be useful but not in= our focus. Coma(n) especially raises the questions on and discusses the us= e cases and requirements for the management of networks with constrained de= vices.

=A0

=

I can imagine policy managem= ent as a requirement on the management of networks with constrained devices= . If you think so, please formulate it and describe the use case from the a= pplication pov. However, I think optimizing routing functionality is on ano= ther level.

=A0

=

Please read also the problem= statement in -01 draft which hopefully describes the focus of Coma(n): http://tools.ietf.org/html/draft-ersue-constrained-mgmt-01 =

Comments are welcome.=

=A0=

Cheers,
Mehmet

=A0

From: ext Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Tuesday, July 17, 2012 8:48 AM
To: Ersue, Mehmet (NS= N - DE/Munich); Jonathan.Hansford@generaldynamics.uk.com; coma@ietf.org
Subject: RE: [Coma] Reprogramming Protocols

=

=A0=

Hum=85 I do not neces= sarily agree.

=A0<= /p>

RPL, which is probably= a protocol of choice for such environment, defines Objective functions tha= t handle metric interpretation and some logic to tie multiple metrics and p= olicies together.

I=92d think that as long = as we stay at the abstract (interface) level we can push some hints to an e= xisting OF to twist its behavior, and tell RPL to support a new instance ba= sed on a new OF that needs to be installed.

=A0<= /p>

There is probably a wa= y to define:

- an abstract interface b= etween RPL and the OF so that we can dynamically plug an OF in.

- abstract behavior speci= fications on which metric are supported and how they are handled (eg additi= ve, weighted, etc) by an existing OF so we can tune the graph generation.

- abstract policies speci= fications so we can control peering, size, power, you name it.

=A0<= /p>

What do you think?<= /u>

=A0<= /p>

Cheers,<= /span>

=A0<= /p>

Pasca= l

=A0

From: coma-bounces@ietf.org [mailto:coma-= bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) Sent: vendredi 8 juin 2012 15:02
To: Jonathan.Hansford@= generaldynamics.uk.com; coma@ietf.org
Subject: Re: [Coma] Reprogramming Protocols

=

=A0

Hi Jonathan,

=A0

=

this could be seen under the= SW/firmware distribution, however reprogramming protocol code is a device = specific logic and not a management task.

=A0

=

Cheers,
Mehmet

=A0

From: coma-bounc= es@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of ext Jona= than.Hansford@generaldynamics.uk.com
Sent: Friday, June 08, 2012 2:38 PM
To: coma@ietf.org
Subject: [Coma= ] Reprogramming Protocols

=A0

Hi,

= =A0

One thing that hasn=92t ye= t been mentioned (unless I missed it) is the issue or reprogramming protoco= ls for adding new applications or modifying/patching existing applications/= firmware. I imagine this is of particular interest in Sensor Nets but may a= lso be beneficial in other scenarios. Will this also be considered within c= oma?

=A0

Thanks,

=A0

Jonathan

=A0

This email and any files attached are intended for the= addressee and may contain information of a confidential nature. If you are= not the intended recipient, be aware that this email was sent to you in er= ror and you should not disclose, distribute, print, copy or make other use = of this email or its attachments. Such actions, in fact, may be unlawful. I= n compliance with the various Regulations and Acts, General Dynamics United= Kingdom Limited reserves the right to monitor (and examine for viruses) al= l emails and email attachments, both inbound and outbound. Email communicat= ions and their attachments may not be secure or error- or virus-free and th= e company does not accept liability or responsibility for such matters or t= he consequences thereof. General Dynamics United Kingdom Limited, Registere= d Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wa= les No: 1911653.


_____________________________= __________________
Coma mailing list
Coma@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/coma


--047d7b10cff3b5168804c50906f8-- Return-Path: 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 68A4F21F8678 for ; Tue, 17 Jul 2012 04:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 s9Hs1hYKQI8p for ; Tue, 17 Jul 2012 04:41:20 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 318E621F8555 for ; Tue, 17 Jul 2012 04:41:20 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6HBfx8S010225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2012 13:41:59 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6HBfufW007203; Tue, 17 Jul 2012 13:41:59 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jul 2012 13:41:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2012 13:41:35 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640405EC38@DEMUEXC006.nsn-intra.net> In-Reply-To: <50500D873F28A34B84BF6DE8903017D11E5BC4@EXDAG0-A2.intra.cea.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] FW: New Version Notification for draft-ersue-constrained-mgmt-01.txt Thread-Index: AQHNZAq+DMIE/ai2/kyZFMPOovs2PJctUyCggAAGIAA= References: <80A0822C5E9A4440A5117C2F4CD36A640405EBBA@DEMUEXC006.nsn-intra.net> <50500D873F28A34B84BF6DE8903017D11E5B3B@EXDAG0-A2.intra.cea.fr> <20120717105545.GA34043@elstar.local> <50500D873F28A34B84BF6DE8903017D11E5BC4@EXDAG0-A2.intra.cea.fr> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext GURGEN Levent 224981" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 17 Jul 2012 11:41:57.0894 (UTC) FILETIME=[2BFE9A60:01CD6411] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1686 X-purgate-ID: 151667::1342525320-000055D8-F3815A7C/0-0/0-0 Cc: coma@ietf.org, "Le Gall, Franck" Subject: Re: [Coma] FW: New Version Notification for draft-ersue-constrained-mgmt-01.txt X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 11:41:21 -0000 With the requirements document we will also highlight gaps and open = issues. I assume a new development will be derived from there but not = sure whether this will be a new WG. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext GURGEN Levent 224981 [mailto:levent.gurgen@cea.fr] > Sent: Tuesday, July 17, 2012 1:20 PM > To: Juergen Schoenwaelder > Cc: coma@ietf.org; Ersue, Mehmet (NSN - DE/Munich); Le Gall, Franck > Subject: RE: [Coma] FW: New Version Notification for = draft-ersue-constrained-mgmt- > 01.txt >=20 > OK I see, thanks for the clarification. I guess your future plan is to = create a WG based > on the results of the discussions on the list, or to integrate them in = the CORE WG? >=20 > Regards, > Levent >=20 >=20 >=20 > > -----Message d'origine----- > > De=A0: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de] > > Envoy=E9=A0: mardi 17 juillet 2012 12:56 > > =C0=A0: GURGEN Levent 224981 > > Cc=A0: coma@ietf.org; Ersue, Mehmet (NSN - DE/Munich); Le Gall, = Franck > > Objet=A0: Re: [Coma] FW: New Version Notification for draft-ersue- > > constrained-mgmt-01.txt > > > > On Tue, Jul 17, 2012 at 10:35:13AM +0000, GURGEN Levent 224981 = wrote: > > > > > > Dear all, > > > I am happy to see such a working group has been created. > > > > > > > [...] > > > > Just to be clear: this is just a mailing list, not a working group > > of any sort. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 Return-Path: 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 96D4321F86C6 for ; Tue, 17 Jul 2012 04:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.099 X-Spam-Level: X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 gvUF6T9SkThg for ; Tue, 17 Jul 2012 04:18:56 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4A021F86C3 for ; Tue, 17 Jul 2012 04:18:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6HBJfJm029215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Jul 2012 13:19:41 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6HBJfcW026370; Tue, 17 Jul 2012 13:19:41 +0200 (envelope-from levent.gurgen@cea.fr) Received: from excah-b0.intra.cea.fr (excah-b0.intra.cea.fr [132.166.88.85]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6HBJfum007775; Tue, 17 Jul 2012 13:19:41 +0200 Received: from EXDAG0-A2.intra.cea.fr ([fe80::e9c1:64ba:3cea:5551]) by excah-b0.intra.cea.fr ([fe80::7542:b9de:5cc1:f613%11]) with mapi id 14.01.0339.001; Tue, 17 Jul 2012 13:19:40 +0200 From: GURGEN Levent 224981 To: Juergen Schoenwaelder Thread-Topic: [Coma] FW: New Version Notification for draft-ersue-constrained-mgmt-01.txt Thread-Index: AQHNZAq+DMIE/ai2/kyZFMPOovs2PJctUyCg Date: Tue, 17 Jul 2012 11:19:40 +0000 Message-ID: <50500D873F28A34B84BF6DE8903017D11E5BC4@EXDAG0-A2.intra.cea.fr> References: <80A0822C5E9A4440A5117C2F4CD36A640405EBBA@DEMUEXC006.nsn-intra.net> <50500D873F28A34B84BF6DE8903017D11E5B3B@EXDAG0-A2.intra.cea.fr> <20120717105545.GA34043@elstar.local> In-Reply-To: <20120717105545.GA34043@elstar.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.104] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-19046.000 x-tm-as-result: No--47.170100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , "coma@ietf.org" , "Le Gall, Franck" Subject: Re: [Coma] FW: New Version Notification for draft-ersue-constrained-mgmt-01.txt X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 11:18:56 -0000 OK I see, thanks for the clarification. I guess your future plan is to crea= te a WG based on the results of the discussions on the list, or to integrat= e them in the CORE WG? Regards, Levent=20 =20 > -----Message d'origine----- > De=A0: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de= ] > Envoy=E9=A0: mardi 17 juillet 2012 12:56 > =C0=A0: GURGEN Levent 224981 > Cc=A0: coma@ietf.org; Ersue, Mehmet (NSN - DE/Munich); Le Gall, Franck > Objet=A0: Re: [Coma] FW: New Version Notification for draft-ersue- > constrained-mgmt-01.txt >=20 > On Tue, Jul 17, 2012 at 10:35:13AM +0000, GURGEN Levent 224981 wrote: > > > > Dear all, > > I am happy to see such a working group has been created. > > >=20 > [...] >=20 > Just to be clear: this is just a mailing list, not a working group > of any sort. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 Return-Path: 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 7FDB721F86C3 for ; Tue, 17 Jul 2012 03:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0VmvutFSfoaR for ; Tue, 17 Jul 2012 03:55:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A9D3521F86C1 for ; Tue, 17 Jul 2012 03:55:03 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7794C20A1F; Tue, 17 Jul 2012 12:55:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sHPqskEWErD7; Tue, 17 Jul 2012 12:55:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B69820A13; Tue, 17 Jul 2012 12:55:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 779762099F4E; Tue, 17 Jul 2012 12:55:46 +0200 (CEST) Date: Tue, 17 Jul 2012 12:55:45 +0200 From: Juergen Schoenwaelder To: GURGEN Levent 224981 Message-ID: <20120717105545.GA34043@elstar.local> Mail-Followup-To: GURGEN Levent 224981 , "coma@ietf.org" , "Ersue, Mehmet (NSN - DE/Munich)" , "Le Gall, Franck" References: <80A0822C5E9A4440A5117C2F4CD36A640405EBBA@DEMUEXC006.nsn-intra.net> <50500D873F28A34B84BF6DE8903017D11E5B3B@EXDAG0-A2.intra.cea.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50500D873F28A34B84BF6DE8903017D11E5B3B@EXDAG0-A2.intra.cea.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , "coma@ietf.org" , "Le Gall, Franck" Subject: Re: [Coma] FW: New Version Notification for draft-ersue-constrained-mgmt-01.txt X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 10:55:04 -0000 On Tue, Jul 17, 2012 at 10:35:13AM +0000, GURGEN Levent 224981 wrote: > > Dear all, > I am happy to see such a working group has been created. > [...] Just to be clear: this is just a mailing list, not a working group of any sort. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Return-Path: 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 DC7D221F86C3 for ; Tue, 17 Jul 2012 03:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.949 X-Spam-Level: X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_HI=-8] 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 oZxmZlN0jQuG for ; Tue, 17 Jul 2012 03:34:29 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id DFA3521F86C1 for ; Tue, 17 Jul 2012 03:34:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6HAZEW5016417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Jul 2012 12:35:14 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6HAZEMJ015521; Tue, 17 Jul 2012 12:35:14 +0200 (envelope-from levent.gurgen@cea.fr) Received: from EXCAH-A1.intra.cea.fr (excah-a1.intra.cea.fr [132.166.88.75]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6HAZEoT021518; Tue, 17 Jul 2012 12:35:14 +0200 Received: from EXDAG0-A2.intra.cea.fr ([fe80::e9c1:64ba:3cea:5551]) by EXCAH-A1.intra.cea.fr ([fe80::5455:9547:c7e7:4610%12]) with mapi id 14.01.0339.001; Tue, 17 Jul 2012 12:35:14 +0200 From: GURGEN Levent 224981 To: "coma@ietf.org" , "Ersue, Mehmet (NSN - DE/Munich)" Thread-Topic: [Coma] FW: New Version Notification for draft-ersue-constrained-mgmt-01.txt Thread-Index: Ac1jkkS3jUyBlF6pT5qMnIO4MntfhQAdCnqAAAAr+9A= Date: Tue, 17 Jul 2012 10:35:13 +0000 Message-ID: <50500D873F28A34B84BF6DE8903017D11E5B3B@EXDAG0-A2.intra.cea.fr> References: <80A0822C5E9A4440A5117C2F4CD36A640405EBBA@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640405EBBA@DEMUEXC006.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.104] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-19046.000 x-tm-as-result: No--40.162000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Le Gall, Franck" Subject: Re: [Coma] FW: New Version Notification for draft-ersue-constrained-mgmt-01.txt X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 10:34:31 -0000 Dear all,=20 I am happy to see such a working group has been created.=20 Currently in the BUTLER project (A European FP7 IP project on context-aware= Internet of Things, http://www.iot-butler.eu/) we have a task dedicated on= management issues for IoT devices. We have already identified some use cas= es and requirements on that and would be happy to share them with you. Actually I am working on this subject since some time, you can find one of = our works on this topic on the link below that contains some state of the a= rt of device management in different domains and proposes a device manageme= nt model for sensor devices inspired by the existing ones. https://www.dropbox.com/s/yul0j5849i76ruq/article_ICPS%2710.pdf In the past I had also been involved in UPnP Device Management profile spec= ification (http://upnp.org/specs/dm/dm1/). Best regards, Levent G=FCrgen, PhD Research Engineer Project Manager =20 CEA-Leti B=E2timent CTL 7 Avenue de Palestine - ZI de Mayencin 38610 GIERES - FRANCE levent.gurgen@cea.fr T=E9l. : + 33 (0)4 56 52 04 20- Fax : + 33 (0)4 56 52 03 66 www.leti.fr =20 =20 =20 > -----Message d'origine----- > De=A0: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] De la part de > Ersue, Mehmet (NSN - DE/Munich) > Envoy=E9=A0: mardi 17 juillet 2012 12:27 > =C0=A0: coma@ietf.org > Objet=A0: [Coma] FW: New Version Notification for draft-ersue-constrained= - > mgmt-01.txt >=20 > Hi All, >=20 > we posted -01 version of the draft on "Management of Networks of > Constrained Devices: Use Cases and Requirements" as input for discussion. > I appreciate your comments and discussion. >=20 > This topic will be also discussed in the OPSAWG/Opsarea session at IETF 8= 4 > on August 2, 2012, 15:10. >=20 > Cheers, > Mehmet >=20 >=20 > -----Original Message----- > From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 16, 2012 10:33 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: dromasca@avaya.com; j.schoenwaelder@jacobs-university.de > Subject: New Version Notification for draft-ersue-constrained-mgmt-01.txt >=20 >=20 > A new version of I-D, draft-ersue-constrained-mgmt-01.txt > has been successfully submitted by Mehmet Ersue and posted to the > IETF repository. >=20 > Filename: draft-ersue-constrained-mgmt > Revision: 01 > Title: Management of Networks of Constrained Devices: Use > Cases and Requirements > Creation date: 2012-07-16 > WG ID: Individual Submission > Number of pages: 27 > URL: http://www.ietf.org/internet-drafts/draft-ersue- > constrained-mgmt-01.txt > Status: http://datatracker.ietf.org/doc/draft-ersue-constrained- > mgmt > Htmlized: http://tools.ietf.org/html/draft-ersue-constrained-mgmt- > 01 > Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ersue- > constrained-mgmt-01 >=20 > Abstract: > This document raises the questions on and discusses the use cases and > requirements for the management of networks with constrained devices. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > Coma mailing list > Coma@ietf.org > https://www.ietf.org/mailman/listinfo/coma Return-Path: 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 97D2321F86E5 for ; Tue, 17 Jul 2012 03:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Va+XFIuKz2jU for ; Tue, 17 Jul 2012 03:27:39 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B249821F86E3 for ; Tue, 17 Jul 2012 03:27:38 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6HASMI0016987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Jul 2012 12:28:24 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6HASKFH021791 for ; Tue, 17 Jul 2012 12:28:22 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jul 2012 12:28:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 17 Jul 2012 12:27:22 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640405EBBA@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ersue-constrained-mgmt-01.txt Thread-Index: Ac1jkkS3jUyBlF6pT5qMnIO4MntfhQAdCnqA From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 17 Jul 2012 10:28:21.0310 (UTC) FILETIME=[E3815DE0:01CD6406] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2206 X-purgate-ID: 151667::1342520905-000055D8-BBD80EE4/0-0/0-0 Subject: [Coma] FW: New Version Notification for draft-ersue-constrained-mgmt-01.txt X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 10:27:39 -0000 SGkgQWxsLA0KDQp3ZSBwb3N0ZWQgLTAxIHZlcnNpb24gb2YgdGhlIGRyYWZ0IG9uICJNYW5hZ2Vt ZW50IG9mIE5ldHdvcmtzIG9mIENvbnN0cmFpbmVkIERldmljZXM6IFVzZSBDYXNlcyBhbmQgUmVx dWlyZW1lbnRzIiBhcyBpbnB1dCBmb3IgZGlzY3Vzc2lvbi4gSSBhcHByZWNpYXRlIHlvdXIgY29t bWVudHMgYW5kIGRpc2N1c3Npb24uDQoNClRoaXMgdG9waWMgd2lsbCBiZSBhbHNvIGRpc2N1c3Nl ZCBpbiB0aGUgT1BTQVdHL09wc2FyZWEgc2Vzc2lvbiBhdCBJRVRGIDg0IG9uIEF1Z3VzdCAyLCAy MDEyLCAxNToxMC4NCg0KQ2hlZXJzLCANCk1laG1ldCANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogZXh0IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bHkgMTYsIDIwMTIgMTA6MzMg UE0NClRvOiBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpDQpDYzogZHJvbWFzY2FAYXZh eWEuY29tOyBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUNClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZXJzdWUtY29uc3RyYWluZWQtbWdtdC0w MS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZXJzdWUtY29uc3RyYWluZWQt bWdtdC0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWVobWV0IEVy c3VlIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJh ZnQtZXJzdWUtY29uc3RyYWluZWQtbWdtdA0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgTWFuYWdl bWVudCBvZiBOZXR3b3JrcyBvZiBDb25zdHJhaW5lZCBEZXZpY2VzOiBVc2UgQ2FzZXMgYW5kIFJl cXVpcmVtZW50cw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTYNCldHIElEOgkJIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyNw0KVVJMOiAgICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1lcnN1ZS1jb25zdHJhaW5lZC1t Z210LTAxLnR4dCANClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1lcnN1ZS1jb25zdHJhaW5lZC1tZ210IA0KSHRtbGl6ZWQ6ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lcnN1ZS1jb25zdHJhaW5lZC1tZ210LTAxDQpE aWZmOiAgICAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt ZXJzdWUtY29uc3RyYWluZWQtbWdtdC0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQg cmFpc2VzIHRoZSBxdWVzdGlvbnMgb24gYW5kIGRpc2N1c3NlcyB0aGUgdXNlIGNhc2VzIGFuZA0K ICAgcmVxdWlyZW1lbnRzIGZvciB0aGUgbWFuYWdlbWVudCBvZiBuZXR3b3JrcyB3aXRoIGNvbnN0 cmFpbmVkIGRldmljZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0K Return-Path: 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 ED47121F85C0 for ; Tue, 17 Jul 2012 03:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.272 X-Spam-Level: X-Spam-Status: No, score=-106.272 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, 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 hRfQ19pzaMoI for ; Tue, 17 Jul 2012 03:09:01 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8534421F855B for ; Tue, 17 Jul 2012 03:09:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6HA9h4g002114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2012 12:09:43 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6HA9hBf007707; Tue, 17 Jul 2012 12:09:43 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jul 2012 12:09:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD6404.46BFE66D" Date: Tue, 17 Jul 2012 12:09:38 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640405EBA2@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] Reprogramming Protocols Thread-Index: Ac1Fc5UBo1X6J4eTSCi4A/yrOIdUnAAAlDEAB5xMBUAABl/5UA== References: <83C941F7F59F3F42AC017AD1E650546206BFB090@GDUKADH850.uk1.r-org.net> <80A0822C5E9A4440A5117C2F4CD36A6403DFB8BD@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Pascal Thubert (pthubert)" , , X-OriginalArrivalTime: 17 Jul 2012 10:09:42.0942 (UTC) FILETIME=[48E7F3E0:01CD6404] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 19771 X-purgate-ID: 151667::1342519783-000055D8-4252E63F/0-0/0-0 Subject: Re: [Coma] Reprogramming Protocols X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 10:09:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD6404.46BFE66D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Pascal, =20 I am wondering whether this has to do with network management. I think we should differentiate between the management and operation of the network. =20 A programmable routing functionality which improves the operational behavior might be useful but not in our focus. Coma(n) especially raises the questions on and discusses the use cases and requirements for the management of networks with constrained devices. =20 I can imagine policy management as a requirement on the management of networks with constrained devices. If you think so, please formulate it and describe the use case from the application pov. However, I think optimizing routing functionality is on another level. =20 Please read also the problem statement in -01 draft which hopefully describes the focus of Coma(n): http://tools.ietf.org/html/draft-ersue-constrained-mgmt-01=20 Comments are welcome. =20 Cheers,=20 Mehmet=20 =20 From: ext Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Tuesday, July 17, 2012 8:48 AM To: Ersue, Mehmet (NSN - DE/Munich); Jonathan.Hansford@generaldynamics.uk.com; coma@ietf.org Subject: RE: [Coma] Reprogramming Protocols =20 Hum... I do not necessarily agree. =20 RPL, which is probably a protocol of choice for such environment, defines Objective functions that handle metric interpretation and some logic to tie multiple metrics and policies together.=20 I'd think that as long as we stay at the abstract (interface) level we can push some hints to an existing OF to twist its behavior, and tell RPL to support a new instance based on a new OF that needs to be installed. =20 There is probably a way to define: - an abstract interface between RPL and the OF so that we can dynamically plug an OF in. - abstract behavior specifications on which metric are supported and how they are handled (eg additive, weighted, etc) by an existing OF so we can tune the graph generation. - abstract policies specifications so we can control peering, size, power, you name it. =20 What do you think? =20 Cheers, =20 Pascal =20 From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) Sent: vendredi 8 juin 2012 15:02 To: Jonathan.Hansford@generaldynamics.uk.com; coma@ietf.org Subject: Re: [Coma] Reprogramming Protocols =20 Hi Jonathan, =20 this could be seen under the SW/firmware distribution, however reprogramming protocol code is a device specific logic and not a management task. =20 Cheers,=20 Mehmet=20 =20 From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of ext Jonathan.Hansford@generaldynamics.uk.com Sent: Friday, June 08, 2012 2:38 PM To: coma@ietf.org Subject: [Coma] Reprogramming Protocols =20 Hi, =20 One thing that hasn't yet been mentioned (unless I missed it) is the issue or reprogramming protocols for adding new applications or modifying/patching existing applications/firmware. I imagine this is of particular interest in Sensor Nets but may also be beneficial in other scenarios. Will this also be considered within coma? =20 Thanks, =20 Jonathan =20 ________________________________ This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.=20 ------_=_NextPart_001_01CD6404.46BFE66D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dear Pascal,

=  

= I am wondering whether this has to do with network management. I think = we should differentiate between the management and operation of the = network.

=  

= A programmable routing functionality which improves the operational = behavior might be useful but not in our focus. Coma(n) especially raises = the questions on and discusses the use cases and requirements for the = management of networks with constrained devices.

=  

= I can imagine policy management as a requirement on the management of = networks with constrained devices. If you think so, please formulate it = and describe the use case from the application pov. However, I think = optimizing routing functionality is on another = level.

=  

= Please read also the problem statement in -01 draft which hopefully = describes the focus of Coma(n): http:= //tools.ietf.org/html/draft-ersue-constrained-mgmt-01 =

= Comments are welcome.

=  

= Cheers,=
= Mehmet=

=  

From:= = ext Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] =
Sent: Tuesday, July 17, 2012 8:48 AM
To: Ersue, = Mehmet (NSN - DE/Munich); Jonathan.Hansford@generaldynamics.uk.com; = coma@ietf.org
Subject: RE: [Coma] Reprogramming = Protocols

 

Hum… I do not necessarily agree.

 

RPL, which is probably a protocol of choice for such environment, = defines Objective functions that handle metric interpretation and some = logic to tie multiple metrics and policies together. =

I’d think that as long as we stay at the abstract (interface) = level we can push some hints to an existing OF to twist its behavior, = and tell RPL to support a new instance based on a new OF that needs to = be installed.

 

There is probably a way to define:

- an abstract interface between RPL and the OF so that we can = dynamically plug an OF in.

- abstract behavior specifications on which metric are supported and = how they are handled (eg additive, weighted, etc) by an existing OF so = we can tune the graph generation.

- abstract policies specifications so we can control peering, size, = power, you name it.

 

What do you think?

 

Cheers,

 

Pascal

 

From:= = coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] = On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: = vendredi 8 juin 2012 15:02
To: Jonathan.Hansfor= d@generaldynamics.uk.com; coma@ietf.org
Subject: Re: = [Coma] Reprogramming Protocols

 

= Hi Jonathan,

=  

= this could be seen under the SW/firmware distribution, however = reprogramming protocol code is a device specific logic and not a = management task.

=  

= Cheers,=
= Mehmet=

=  

From:= = coma-bounces@ietf.org [mailto:coma-bounces@ietf.= org] On Behalf Of ext Jonathan.Hansfor= d@generaldynamics.uk.com
Sent: Friday, June 08, 2012 2:38 = PM
To: coma@ietf.org
Subject: = [Coma] Reprogramming Protocols

 

Hi,

 

One thing = that hasn’t yet been mentioned (unless I missed it) is the issue = or reprogramming protocols for adding new applications or = modifying/patching existing applications/firmware. I imagine this is of = particular interest in Sensor Nets but may also be beneficial in other = scenarios. Will this also be considered within = coma?

 

Thanks,<= /o:p>

 

Jonathan

 

This email and any files attached = are intended for the addressee and may contain information of a = confidential nature. If you are not the intended recipient, be aware = that this email was sent to you in error and you should not disclose, = distribute, print, copy or make other use of this email or its = attachments. Such actions, in fact, may be unlawful. In compliance with = the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all = emails and email attachments, both inbound and outbound. Email = communications and their attachments may not be secure or error- or = virus-free and the company does not accept liability or responsibility = for such matters or the consequences thereof. General Dynamics United = Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. = Registered in England and Wales No: 1911653. =

------_=_NextPart_001_01CD6404.46BFE66D-- Return-Path: 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 7071111E80A2 for ; Mon, 16 Jul 2012 23:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] 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 zxIDVhVL1eyH for ; Mon, 16 Jul 2012 23:47:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D1F3E11E809C for ; Mon, 16 Jul 2012 23:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=15393; q=dns/txt; s=iport; t=1342507689; x=1343717289; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=r4gutMya7kFcX6s/M4YFbSlPDIeWzQM0KKq/zEl1h/s=; b=UdIJzExiyhvBhMAWlSaubJspARR94dyhwB8KAY36ECxEB8lpXsR/XaZO 0rgwLJi2ncMwVJpNycJ1RxT8VQ6GGZ3unC5TjAAKz97N91tARvrmyq6U0 5Wns1h3ejow5Eaikptf3ouvHCtHXves8s+0seMLhiKfYT0tv2wSB9wYog w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALAJBVCtJXG9/2dsb2JhbABFgkq3D4EHgiABAQEEEgEaWgICAQgRBAEBCx0HFhwUCQgBAQQBEggah2ucMqAfBIs6FAQDhUxgA6NbgWaCX4FWCQ X-IronPort-AV: E=Sophos;i="4.77,599,1336348800"; d="scan'208,217";a="102532260" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 17 Jul 2012 06:48:09 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6H6m9QP000440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 06:48:09 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.219]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 01:48:08 -0500 From: "Pascal Thubert (pthubert)" To: "Ersue, Mehmet (NSN - DE/Munich)" , "Jonathan.Hansford@generaldynamics.uk.com" , "coma@ietf.org" Thread-Topic: [Coma] Reprogramming Protocols Thread-Index: Ac1Fc5UBo1X6J4eTSCi4A/yrOIdUnAAAlDEAB5xMBUA= Date: Tue, 17 Jul 2012 06:48:08 +0000 Deferred-Delivery: Tue, 17 Jul 2012 06:48:00 +0000 Message-ID: References: <83C941F7F59F3F42AC017AD1E650546206BFB090@GDUKADH850.uk1.r-org.net> <80A0822C5E9A4440A5117C2F4CD36A6403DFB8BD@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403DFB8BD@DEMUEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.81.214] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.000 x-tm-as-result: No--40.818300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD807D3AA4Cxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [Coma] Reprogramming Protocols X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 06:47:25 -0000 --_000_E045AECD98228444A58C61C200AE1BD807D3AA4Cxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hum... I do not necessarily agree. RPL, which is probably a protocol of choice for such environment, defines O= bjective functions that handle metric interpretation and some logic to tie = multiple metrics and policies together. I'd think that as long as we stay at the abstract (interface) level we can = push some hints to an existing OF to twist its behavior, and tell RPL to su= pport a new instance based on a new OF that needs to be installed. There is probably a way to define: - an abstract interface between RPL and the OF so that we can dynamically p= lug an OF in. - abstract behavior specifications on which metric are supported and how th= ey are handled (eg additive, weighted, etc) by an existing OF so we can tun= e the graph generation. - abstract policies specifications so we can control peering, size, power, = you name it. What do you think? Cheers, Pascal From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of Ers= ue, Mehmet (NSN - DE/Munich) Sent: vendredi 8 juin 2012 15:02 To: Jonathan.Hansford@generaldynamics.uk.com; coma@ietf.org Subject: Re: [Coma] Reprogramming Protocols Hi Jonathan, this could be seen under the SW/firmware distribution, however reprogrammin= g protocol code is a device specific logic and not a management task. Cheers, Mehmet From: coma-bounces@ietf.org [mailto:coma-boun= ces@ietf.org] On Behalf Of ext Jonat= han.Hansford@generaldynamics.uk.com Sent: Friday, June 08, 2012 2:38 PM To: coma@ietf.org Subject: [Coma] Reprogramming Protocols Hi, One thing that hasn't yet been mentioned (unless I missed it) is the issue = or reprogramming protocols for adding new applications or modifying/patchin= g existing applications/firmware. I imagine this is of particular interest = in Sensor Nets but may also be beneficial in other scenarios. Will this als= o be considered within coma? Thanks, Jonathan ________________________________ This email and any files attached are intended for the addressee and may co= ntain information of a confidential nature. If you are not the intended rec= ipient, be aware that this email was sent to you in error and you should no= t disclose, distribute, print, copy or make other use of this email or its = attachments. Such actions, in fact, may be unlawful. In compliance with the= various Regulations and Acts, General Dynamics United Kingdom Limited rese= rves the right to monitor (and examine for viruses) all emails and email at= tachments, both inbound and outbound. Email communications and their attach= ments may not be secure or error- or virus-free and the company does not ac= cept liability or responsibility for such matters or the consequences there= of. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn = Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. --_000_E045AECD98228444A58C61C200AE1BD807D3AA4Cxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hum… I do not neces= sarily agree.

 <= /p>

RPL, which is probably a = protocol of choice for such environment, defines Objective functions that h= andle metric interpretation and some logic to tie multiple metrics and policies together.

I’d think that as l= ong as we stay at the abstract (interface) level we can push some hints to = an existing OF to twist its behavior, and tell RPL to support a new instance based on a new OF that needs to be installed.

 <= /p>

There is probably a way t= o define:

- an abstract interface b= etween RPL and the OF so that we can dynamically plug an OF in.<= /span>

- abstract behavior speci= fications on which metric are supported and how they are handled (eg additi= ve, weighted, etc) by an existing OF so we can tune the graph generation.

- abstract policies speci= fications so we can control peering, size, power, you name it.

 <= /p>

What do you think?

 <= /p>

Cheers,=

 <= /p>

Pascal

 <= /p>

From: coma-bou= nces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: vendredi 8 juin 2012 15:02
To: Jonathan.Hansford@generaldynamics.uk.com; coma@ietf.org
Subject: Re: [Coma] Reprogramming Protocols

 

Hi Jonathan,

 

this could be seen under the= SW/firmware distribution, however reprogramming protocol code is a device = specific logic and not a management task.

 

Cheers,
Mehmet

 

From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of ext Jonathan.Hansford@generaldynamics.uk.com
Sent: Friday, June 08, 2012 2:38 PM
To: coma@ietf.org
Subject: [Coma] Reprogramming Protocols

 

Hi,

 

One thing that hasn’= t yet been mentioned (unless I missed it) is the issue or reprogramming pro= tocols for adding new applications or modifying/patching existing applications/firmware. I imagine this is of particular interest in Sensor = Nets but may also be beneficial in other scenarios. Will this also be consi= dered within coma?

 

Thanks,<= /p>

 

Jonathan

 

This email and any files attach= ed are intended for the addressee and may contain information of a confiden= tial nature. If you are not the intended recipient, be aware that this emai= l was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or i= ts attachments. Such actions, in fact, may be unlawful. In compliance with = the various Regulations and Acts, General Dynamics United Kingdom Limited r= eserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and ou= tbound. Email communications and their attachments may not be secure or err= or- or virus-free and the company does not accept liability or responsibili= ty for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Ho= lborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653= .

--_000_E045AECD98228444A58C61C200AE1BD807D3AA4Cxmbrcdx01ciscoc_-- Return-Path: 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 926C511E826D for ; Mon, 16 Jul 2012 10:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NVqp8w0437PM for ; Mon, 16 Jul 2012 10:45:16 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id A5BEE11E826A for ; Mon, 16 Jul 2012 10:45:16 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 6BE01108439; Mon, 16 Jul 2012 12:46:01 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q6GHk1fx013385; Mon, 16 Jul 2012 12:46:01 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Mon, 16 Jul 2012 12:46:01 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Ersue, Mehmet (NSN - DE/Munich)" Date: Mon, 16 Jul 2012 12:46:00 -0500 Thread-Topic: [Coma] Store, Carry and Forward (SCF) Technologies for Management of Constrained Networks and Devices Thread-Index: Ac1jet0HfD0v5TEZRd6kCWoZTPuOmQ== Message-ID: <74889C75-7130-4EAF-B011-9A89EDC6BF8E@nasa.gov> References: <80A0822C5E9A4440A5117C2F4CD36A640405E7E8@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640405E7E8@DEMUEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74889C7571304EAFB0119A89EDC6BF8Enasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-16_03:2012-07-16, 2012-07-16, 1970-01-01 signatures=0 Cc: Wesley Eddy , "coma@ietf.org" Subject: Re: [Coma] Store, Carry and Forward (SCF) Technologies for Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:45:17 -0000 --_000_74889C7571304EAFB0119A89EDC6BF8Enasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You might take a look at the Network Management slides here: http://www.dtnrg.org/wiki/DtnBone/JanNetManMeeting Irrespective of disconnection, the idea of sort of compressing network mana= gement information and requests (preconfigured requests and such) is probab= ly useful. Unfortunately, there is not much newer information that I am aware of. - Will On Jul 16, 2012, at 8:57 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: Dear Will, thank you for the information. SCF might be a useful solution e.g. for SW d= istribution in constrained networks. However, our main interest is to collect use cases and to define requiremen= ts for the management of the networks of constrained devices. BR, Mehmet --_000_74889C7571304EAFB0119A89EDC6BF8Enasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You might take a look at the Network Management slides here:


I= rrespective of disconnection, the idea of sort of compressing network manag= ement information and requests (preconfigured requests and such) is probabl= y useful.

Unfortunately, there is not much newer i= nformation that I am aware of.

- Will
On Jul 16, 2012, at 8:57 AM, Ersue, Mehmet (NSN - DE= /Munich) wrote:

Dear Will,
 
thank you for th= e information. SCF might be a useful solution e.g. for SW distribution in c= onstrained networks.
However, our main intere= st is to collect use cases and to define requirements for the management of= the networks of constrained devices.
=  
BR, 
Mehmet

= --_000_74889C7571304EAFB0119A89EDC6BF8Enasagov_-- Return-Path: 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 1A9AF21F88B3 for ; Mon, 16 Jul 2012 07:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 i2ZKFefQVPxU for ; Mon, 16 Jul 2012 07:02:24 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 721FC21F884D for ; Mon, 16 Jul 2012 07:02:24 -0700 (PDT) Received: from marajade.sandelman.ca (herring.sandelman.ca [209.87.252.231]) by relay.sandelman.ca (Postfix) with ESMTPS id C52D4868D; Mon, 16 Jul 2012 09:59:27 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 9EDE72003A; Mon, 16 Jul 2012 10:03:05 -0400 (EDT) Received: from herring.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 842ED1FBD2; Mon, 16 Jul 2012 10:03:05 -0400 (EDT) From: Michael Richardson To: coma@ietf.org X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640405E7E8@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A640405E7E8@DEMUEXC006.nsn-intra.net> X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 16 Jul 2012 10:03:05 -0400 Message-ID: <24362.1342447385@herring.sandelman.ca> Sender: mcr@sandelman.ca Cc: Wesley Eddy , william.d.ivancic@nasa.gov Subject: Re: [Coma] Store, Carry and Forward (SCF) Technologies for Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 14:02:25 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I agree that SCF is out of scope for COMA. It's an exciting protocol though. If there was sufficient multi-vendor excitement, a WG and/or IRTF WG might be appropriate. If not, I strongly suggest individual submission Informational. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUBUAQev4qHRg3pndX9AQKFIgQAn850gTUHP9b5vx2i06MWcbgSruTNFIIx HFywm0Kh1Bj2/1eB+ukt0MfSkGJjSsb3z/bWYpLcNTb5rIA8LXSUtcuaJChKDphr rrZ80KCkz0AW2iJnA6O3drEzwijqu4z55F4EijRMaECdjYYKq6At5BHljYxL3LqH FKBLvj/JE10= =nHJD -----END PGP SIGNATURE----- --=-=-=-- Return-Path: 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 158A121F8813 for ; Mon, 16 Jul 2012 05:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 zCvEPYWoxeKF for ; Mon, 16 Jul 2012 05:57:54 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3F48921F8815 for ; Mon, 16 Jul 2012 05:57:53 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6GCwZ6k024158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jul 2012 14:58:35 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6GCwSep002920; Mon, 16 Jul 2012 14:58:32 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jul 2012 14:58:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD6352.98470753" Date: Mon, 16 Jul 2012 14:57:45 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640405E7E8@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Coma] Store, Carry and Forward (SCF) Technologies for Management of Constrained Networks and Devices Thread-Index: Ac1fZvMgGLYk9I+NQ5GOwwAzW6EUlgD6c/4w References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ivancic, William D. (GRC-RHN0)" , X-OriginalArrivalTime: 16 Jul 2012 12:58:28.0603 (UTC) FILETIME=[B1DB74B0:01CD6352] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 16359 X-purgate-ID: 151667::1342443515-00002E58-893E6EE7/0-0/0-0 Cc: Wesley Eddy Subject: Re: [Coma] Store, Carry and Forward (SCF) Technologies for Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 12:57:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD6352.98470753 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Will, =20 thank you for the information. SCF might be a useful solution e.g. for SW distribution in constrained networks.=20 However, our main interest is to collect use cases and to define requirements for the management of the networks of constrained devices. =20 BR,=20 Mehmet=20 =20 From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of ext Ivancic, William D. (GRC-RHN0) Sent: Wednesday, July 11, 2012 3:13 PM To: coma@ietf.org Cc: Wesley Eddy Subject: [Coma] Store, Carry and Forward (SCF) Technologies for Management of Constrained Networks and Devices =20 Hello, I became aware of this list recently and perused the archives. I am posting with two motives: (1) To see if this group sees a need for store, carry and forward (SCF) technologies. One of the areas we see such technology helping in is updated software to systems in challenged (Constrained) networks. =20 (2) Our approach to bounding the SCF problem and generating requirements may be useful to COMA. After reading the threads, it appears that documenting your scenarios and creating a bounded problem statement may help move discussion along. As is, the problem space appears unbounded or, at least overly large. The following Internet Drafts have recently been posted: http://www.ietf.org/id/draft-ivancic-scf-problem-statement-00.txt http://www.ietf.org/id/draft-ivancic-scf-requirements-expectations-00.tx t =20 http://www.ietf.org/id/draft-ivancic-scf-testing-requirements-00.txt There is also a recent presentation that might help regarding the philosophical approach to the problem. =20 http://roland.grc.nasa.gov/~ivancic/papers_presentations/2012/RobustNetw orkingWorkshop062612.pdf =20 Summarized below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. KISS (Keep it Simple Stupid) 2. Options make interoperability hard. 3. Options are often used as a placeholder for fixing a bad design. 4. Think about terminology. - "Words make a difference. They affect how we thing about something. The terms chosen to describe a concept are a crucial part of any model. The right concepts with terms that give the wrong connotation can make a problem much more difficult. The right terms can make it much easier. Adopting the mindset of the terms may allow you to see thing you might not otherwise see." - John Day, Patterns in Network Architect =20 5. Don't overload the protocol.=20 6. "In anything at all, perfection if finally attained, not when there is no longer anything to add, but when there is no longer anything to take away..." - Antonie de Saint Exupery 7. "A good engineer is a lazy degenerate. He prefers degenerate cases to special cases and will sit around (thinking) until he finds a simple solution, rather that immediately launch into a brute force approach. In other words, the goal of a architect is to use the tools he has to make things simple. (Anyone can make things more complicated)!" - John Day, Patterns in Network Architect - Will =20 ****************************** William D. Ivancic http://roland.grc.nasa.gov/~ivancic =20 ------_=_NextPart_001_01CD6352.98470753 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dear Will,

=  

= thank you for the information. SCF might be a useful solution e.g. for = SW distribution in constrained networks.

= However, our main interest is to collect use cases and to define = requirements for the management of the networks of constrained = devices.

=  

= BR,=
= Mehmet=

=  

From:= = coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of = ext Ivancic, William D. (GRC-RHN0)
Sent: Wednesday, July = 11, 2012 3:13 PM
To: coma@ietf.org
Cc: Wesley = Eddy
Subject: [Coma] Store, Carry and Forward (SCF) = Technologies for Management of Constrained Networks and = Devices

 

Hello,

I became = aware of this list recently and perused the archives.  I am posting = with two motives:

(1)  To see if = this group sees a need for store, carry and forward (SCF) technologies. = One of the areas we see such technology helping in is updated software = to systems in challenged (Constrained) networks.  

(2)  Our = approach to bounding the SCF problem and generating requirements may be = useful to COMA. After reading the threads, it appears that documenting = your scenarios and creating a bounded problem statement may help move = discussion along. As is, the problem space appears unbounded or, at = least overly large.

The = following Internet Drafts have recently been posted:

http://www.ietf.org/id/draft-ivancic-scf-problem-statement-00.txt

http://www.ietf.org/id/draft-ivancic-scf-requirements-expectati= ons-00.txt

 



There is = also a recent presentation that might help regarding the philosophical = approach to the problem. 

http://roland.grc.nasa.gov/~ivancic/pape= rs_presentations/2012/RobustNetworkingWorkshop062612.pdf

 <= /o:p>

Summarized = below:

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1. KISS = (Keep it Simple Stupid)

2. Options = make interoperability hard.

3. Options = are often used as a placeholder for fixing a bad design.

4. Think = about terminology. – “Words make a difference. They affect = how we thing about something. The terms chosen to describe a concept are = a crucial part of any model. The right concepts with terms that give the = wrong connotation can make a problem much more difficult. The right = terms can make it much easier. Adopting the mindset of the terms may = allow you to see thing you might not otherwise see.” - John Day, = Patterns in Network Architect

 

5. = Don’t overload the = protocol. 

6. "In = anything at all, perfection if finally attained, not when there is no = longer anything to add, but when there is no longer anything to take = away..." - Antonie de Saint Exupery

7. "A = good engineer is a lazy degenerate. He prefers degenerate cases to = special cases and will sit around (thinking) until he finds a simple = solution, rather that immediately launch into a brute force approach. In = other words, the goal of a architect is to use the tools he has to make = things simple. (Anyone can make things more complicated)!” - John = Day, Patterns in Network Architect

- Will

 

******************************
William D. Ivancic
http://roland.grc.nasa.gov/~= ivancic

 

------_=_NextPart_001_01CD6352.98470753-- Return-Path: 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 66AF021F86C2 for ; Wed, 11 Jul 2012 07:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 nOmoyLgzriiB for ; Wed, 11 Jul 2012 07:22:53 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9B82A21F86A7 for ; Wed, 11 Jul 2012 07:22:48 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6BENF92030672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jul 2012 16:23:15 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6BENFQx016137; Wed, 11 Jul 2012 16:23:15 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jul 2012 16:23:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 11 Jul 2012 16:23:14 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640401ABCB@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ersue-constrained-mgmt-00.txt Thread-Index: Ac1eEiNNCBp6xz+jRsCE+OMJeQszjABXc3aA From: "Ersue, Mehmet (NSN - DE/Munich)" To: , "ext Benoit Claise" X-OriginalArrivalTime: 11 Jul 2012 14:23:16.0011 (UTC) FILETIME=[B61F8FB0:01CD5F70] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2226 X-purgate-ID: 151667::1342016595-0000425E-B9ED8872/0-0/0-0 Subject: [Coma] FW: New Version Notification for draft-ersue-constrained-mgmt-00.txt X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 14:22:55 -0000 SGkgQWxsLA0KDQp3ZSBzdWJtaXR0ZWQgYW4gLTAwIGRyYWZ0IG9uIHRoZSAiTWFuYWdlbWVudCBv ZiBOZXR3b3JrcyBvZiBDb25zdHJhaW5lZCBEZXZpY2VzOiBVc2UgQ2FzZXMgYW5kIFJlcXVpcmVt ZW50cyIgYXMgaW5wdXQgZm9yIGRpc2N1c3Npb24uIFRoaXMgaXMgYSBlYXJseSBkcmFmdCBhbmQg ZmFyIGF3YXkgZnJvbSBiZWluZyBjb21wbGV0ZS4NCg0KTGV0IHVzIGRpc2N1c3Mgb24gdGhlIG1h aWxsaXN0IG9uIHlvdXIgY29tbWVudHMgYW5kIHJlcXVlc3RzIGNvbmNlcm5pbmcgdGhlIGRvY3Vt ZW50IHN0cnVjdHVyZSBidXQgZXNwZWNpYWxseSB0aGUgY29udGVudCBvZiB0aGUgcmVxdWlyZW1l bnRzIHNlY3Rpb24uIFRoYW5rcy4NCg0KQ2hlZXJzLCANCk1laG1ldCANCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bHkgMDksIDIw MTIgMTA6MzMgUE0NClRvOiBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpDQpDYzogZHJv bWFzY2FAYXZheWEuY29tOyBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUNClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZXJzdWUtY29uc3RyYWlu ZWQtbWdtdC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZXJzdWUtY29u c3RyYWluZWQtbWdtdC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg TWVobWV0IEVyc3VlIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVu YW1lOgkgZHJhZnQtZXJzdWUtY29uc3RyYWluZWQtbWdtdA0KUmV2aXNpb246CSAwMA0KVGl0bGU6 CQkgTWFuYWdlbWVudCBvZiBOZXR3b3JrcyBvZiBDb25zdHJhaW5lZCBEZXZpY2VzOiBVc2UgQ2Fz ZXMgYW5kIFJlcXVpcmVtZW50cw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMDkNCldHIElEOgkJ IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyNA0KVVJMOiAgICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1lcnN1ZS1jb25z dHJhaW5lZC1tZ210LTAwLnR4dCANClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1lcnN1ZS1jb25zdHJhaW5lZC1tZ210IA0KSHRtbGl6ZWQ6ICAg ICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lcnN1ZS1jb25zdHJhaW5lZC1t Z210LTAwIA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCByYWlzZXMgdGhlIHF1ZXN0 aW9ucyBvbiBhbmQgZGlzY3Vzc2VzIHRoZSB1c2UgY2FzZXMsDQogICByZXF1aXJlbWVudHMgYW5k IHRoZSBzb2x1dGlvbnMgcmVxdWlyZWQgZm9yIHRoZSBtYW5hZ2VtZW50IG9mIGENCiAgIG5ldHdv cmsgd2l0aCBjb25zdHJhaW5lZCBkZXZpY2VzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== Return-Path: 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 DDD7321F8694 for ; Wed, 11 Jul 2012 06:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 tOrZW+njxoAP for ; Wed, 11 Jul 2012 06:12:56 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by ietfa.amsl.com (Postfix) with ESMTP id A0CDD21F869D for ; Wed, 11 Jul 2012 06:12:55 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id E60B7D1913; Wed, 11 Jul 2012 08:13:25 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q6BDDOcV024432; Wed, 11 Jul 2012 08:13:24 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Wed, 11 Jul 2012 08:13:23 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "coma@ietf.org" Date: Wed, 11 Jul 2012 08:13:22 -0500 Thread-Topic: Store, Carry and Forward (SCF) Technologies for Management of Constrained Networks and Devices Thread-Index: Ac1fZvMgGLYk9I+NQ5GOwwAzW6EUlg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F95883E2FD434303B9B9D41E389F20D8nasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-11_02:2012-07-11, 2012-07-11, 1970-01-01 signatures=0 Cc: Wesley Eddy Subject: [Coma] Store, Carry and Forward (SCF) Technologies for Management of Constrained Networks and Devices X-BeenThere: coma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 13:12:57 -0000 --_000_F95883E2FD434303B9B9D41E389F20D8nasagov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, I became aware of this list recently and perused the archives. I am postin= g with two motives: (1) To see if this group sees a need for store, carry and forward (SCF) te= chnologies. One of the areas we see such technology helping in is updated s= oftware to systems in challenged (Constrained) networks. (2) Our approach to bounding the SCF problem and generating requirements m= ay be useful to COMA. After reading the threads, it appears that documentin= g your scenarios and creating a bounded problem statement may help move dis= cussion along. As is, the problem space appears unbounded or, at least over= ly large. The following Internet Drafts have recently been posted: http://www.ietf.org/id/draft-ivancic-scf-problem-statement-00.txt http://www.ietf.org/id/draft-ivancic-scf-requirements-expectations-00.txt http://www.ietf.org/id/draft-ivancic-scf-testing-requirements-00.txt There is also a recent presentation that might help regarding the philosoph= ical approach to the problem. http://roland.grc.nasa.gov/~ivancic/papers_presentations/2012/RobustNetwork= ingWorkshop062612.pdf Summarized below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. KISS (Keep it Simple Stupid) 2. Options make interoperability hard. 3. Options are often used as a placeholder for fixing a bad design. 4. Think about terminology. =96 =93Words make a difference. They affect how= we thing about something. The terms chosen to describe a concept are a cru= cial part of any model. The right concepts with terms that give the wrong c= onnotation can make a problem much more difficult. The right terms can make= it much easier. Adopting the mindset of the terms may allow you to see thi= ng you might not otherwise see.=94 - John Day, Patterns in Network Architec= t 5. Don=92t overload the protocol. 6. "In anything at all, perfection if finally attained, not when there is n= o longer anything to add, but when there is no longer anything to take away= ..." - Antonie de Saint Exupery 7. "A good engineer is a lazy degenerate. He prefers degenerate cases to sp= ecial cases and will sit around (thinking) until he finds a simple solution= , rather that immediately launch into a brute force approach. In other word= s, the goal of a architect is to use the tools he has to make things simple= . (Anyone can make things more complicated)!=94 - John Day, Patterns in Net= work Architect - Will ****************************** William D. Ivancic http://roland.grc.nasa.gov/~ivancic --_000_F95883E2FD434303B9B9D41E389F20D8nasagov_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello,

I became aware of this list recently and perused the archives.  I am posting with two motives:

(1)  To see if this group sees a need for store, carry and forward (SCF) technologi= es. One of the areas we see such technology helping in is updated software to systems in challenged (Constrained) networks. 

(2)  Our approach to bounding the SCF problem and generating requirements may be use= ful to COMA. After reading the threads, it appears that documenting your scenar= ios and creating a bounded problem statement may help move discussion along. As= is, the problem space appears unbounded or, at least overly large.

The following Internet Drafts have recently been posted:

http= ://www.ietf.org/id/draft-ivancic-scf-problem-statement-00.txt

http://www.ietf.org/id/draft-ivancic-scf-requirements-expecta= tions-00.txt


=

There is also a recent presentation that might help regarding the philosophical approach to the problem.  

http://roland.grc.nasa.= gov/~ivancic/papers_presentations/2012/RobustNetworkingWorkshop062612.pdf


Summa= rized below:
5. Don=92t overload the protocol. = ;
<= span class=3D"Apple-style-span" style=3D"color: rgb(31, 73, 125); font-size= : 13px; ">

6. "In anything at all, perfection if finally attained, not when there is no longer anything to add, but when there is no longer anything to take away..." - Antonie de Saint Exupery

7. "A good engineer is a lazy degenerate. He prefers degenerate cases to special cases and will sit around (thinking) until he finds a simple soluti= on, rather that immediately launch into a brute force approach. In other words,= the goal of a architect is to use the tools he has to make things simple. (Anyo= ne can make things more complicated)!=94 - John Day, Patterns in Network Archi= tect

- Will

******************************=
William D. Ivancic
<= span class=3D"Apple-style-span" style=3D"color: rgb(31, 73, 125); font-fami= ly: 'Times New Roman', serif; font-size: 13px; ">h= ttp://roland.grc.nasa.gov/~ivancic

= --_000_F95883E2FD434303B9B9D41E389F20D8nasagov_-- From mehmet.ersue@nsn.com Tue Jul 17 10:46:49 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2707C21F8669 for ; Tue, 17 Jul 2012 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 9nidyxg4gfgc for ; Tue, 17 Jul 2012 10:46:48 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3594F21F865E for ; Tue, 17 Jul 2012 10:46:45 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6HHlWG9008684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Jul 2012 19:47:32 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6HHlWMV015178 for ; Tue, 17 Jul 2012 19:47:32 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jul 2012 19:47:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 17 Jul 2012 19:46:35 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640405EE04@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: COMA maillist has been renamed to COMAN maillist Thread-Index: Ac1kPb3hPtpqv92qQh6PlgTh7RMNXgABcjjg From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 17 Jul 2012 17:47:32.0070 (UTC) FILETIME=[3DC84060:01CD6444] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2830 X-purgate-ID: 151667::1342547252-000055D8-F73CA875/0-0/0-0 Subject: [coman] COMA maillist has been renamed to COMAN maillist X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 17:46:49 -0000 RllJDQoNClRoZSBhY3JvbnltIHdhcyBhbiB1bmZvcnR1bmF0ZSBjaG9pY2UgYW5kIG5vdCB3ZWxs IGFjY2VwdGVkLg0KVGhlcmUgaXMgbm8gYWN0aW9uIG5lY2Vzc2FyeSBvbiB5b3VyIHNpZGUuDQoN CkNoZWVycywgDQpNZWhtZXQgDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGV4dCBTdGV2ZSBZb3VuZyB2aWEgUlQgW21haWx0bzppZXRmLWFjdGlvbkBpZXRmLm9yZ10gDQpT ZW50OiBUdWVzZGF5LCBKdWx5IDE3LCAyMDEyIDc6MDAgUE0NClRvOiAiT3RoZXJSZWNpcGllbnRz IG9mIHd3dy5pZXRmLm9yZy9ydCBUaWNrZXQgIzQ5Mjg2Ig0KQ2M6IEVyc3VlLCBNZWhtZXQgKE5T TiAtIERFL011bmljaCk7IHJib25pY2FAanVuaXBlci5uZXQNClN1YmplY3Q6IFt3d3cuaWV0Zi5v cmcvcnQgIzQ5Mjg2XSBSZTogW09QUy1ESVJdIE9QUyBESVIgTHVuY2ggDQoNCkhpIEJlbm9pdCwN Cg0KQ29tYW4gaGFzIGJlZW4gY3JlYXRlZC4gIFRoZSBzdWJzY3JpYmVyIGxpc3QgYW5kIGFyY2hp dmUgaGF2ZSBiZWVuDQpjb3BpZWQgZnJvbSBjb21hIHRvIGNvbWFuLiAgTGlzdCBkZXRhaWxzIGhh dmUgYmVlbiBzZW50IHRvIHRoZSBsaXN0DQphZG1pbnMgdmlhIGVtYWlsLg0KDQpDb21hIGhhcyBi ZWVuIGNsb3NlZC4gIEFueWJvZHkgdHJ5aW5nIHRvIHNlbmQgdG8gY29tYSB3aWxsIHJlY2VpdmUg YQ0KbWVzc2FnZSB0ZWxsaW5nIHRoZW0gdGhlIGxpc3QgaGFzIG1vdmVkIHRvIGNvbWFuLg0KDQpC ZXN0IHJlZ2FyZHMsDQpTdGV2ZQ0KDQpPbiBNb24gSnVsIDE2IDAyOjUxOjM3IDIwMTIsIGJjbGFp c2VAY2lzY28uY29tIHdyb3RlOg0KPiBIaSBTdGV2ZSwNCj4gDQo+ID4gSGkgQmVub2l0LA0KPiA+ DQo+ID4gWWVzLCB3ZSBjYW4gZG8gdGhhdCBieSBjcmVhdGluZyBhIG5ldyBtYWlsaW5nIGxpc3Qg d2l0aCB0aGUgbmV3DQo+IG5hbWUsDQo+ID4gdGhlbiBjb3B5aW5nIHRoZSBzdWJzY3JpYmVycyBh bmQgYXJjaGl2ZSBmcm9tIHRoZSBvbGQgbGlzdCB0byB0aGUNCj4gbmV3IGxpc3QuDQo+ID4NCj4g PiBKdXN0IGxldCBtZSBrbm93IGlmIHlvdSB3b3VsZCBsaWtlIG1lIHRvIGRvIHRoYXQuDQo+IFll cywgcGxlYXNlLiBTdGFydCB0aGUgcHJvY2Vzcy4NCj4gDQo+IFJlZ2FyZHMsIEJlbm9pdC4NCj4g Pg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBTdGV2ZQ0KPiA+DQo+ID4gT24gV2VkIEp1bCAxMSAw ODowMDowMyAyMDEyLCBiY2xhaXNlQGNpc2NvLmNvbSB3cm90ZToNCj4gPj4gRGVhciBzZWNyZXRh cmlhdCwNCj4gPj4NCj4gPj4gSXMgdGhlcmUgYSB3YXkgdG8gY2hhbmdlIGFuIG5vbiB3b3JraW5n IGdyb3VwIG1haWxpbmcgbGlzdCBuYW1lLA0KPiB3aGlsZQ0KPiA+PiBrZWVwaW5nIHRoZSBuYW1l IGFyY2hpdmUgYW5kIGFsbCB0aGUgcGVvcGxlIHN1YnNjcmliZWQ/DQo+ID4+IEluIHRoaXMgY2Fz ZSwgdGhlIHByb3Bvc2FsIGlzIHRvIGNoYW5nZSAiY29tYSIgdG8gImNvbWFuIi4NCj4gPj4NCj4g Pj4gUmVnYXJkcywgQmVub2l0Lg0KPiA+Pg0KPiA+Pj4gSGkgQmVub2l0LA0KPiA+Pj4NCj4gPj4+ IEkgd291bGQgbGlrZSB0byBhZGRyZXNzIHRoZSByZXF1ZXN0IG9mIFJvbiB0byBjaGFuZ2UgdGhl IGFjcm9ueW0NCj4gZnJvbQ0KPiA+Pj4gQ09NQSB0byBzb21ldGhpbmcgZWxzZS4NCj4gPj4+IEFm dGVyIHNvbWUgdGhpbmtpbmcgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdG8gdXNlIENPTUFOIGFz DQo+IGFjcm9ueW0uDQo+ID4+Pg0KPiA+Pj4gSG93IGlzIHRoZSBwcm9jZXNzIGZvciB0aGlzIGNo YW5nZT8gSSBhc3N1bWUgeW91IG5lZWQgdG8gYXNrIHRoZQ0KPiA+Pj4gc2VjcmV0YXJ5IGFuZCB0 aGV5IGhhdmUgdG8gY29weSB0aGUgbWFpbCBhcmNoaXZlLg0KPiA+Pj4gTWF5IGJlIHdlIG5lZWQg dG8ga2VlcCBDT01BIGFsaXZlIGZvciBzb21lIHRpbWUgd2l0aCBhIG1lc3NhZ2UNCj4gc2VudCBi YWNrDQo+ID4+PiB0byB1c2UgQ09NQU4gaW5zdGVhZC4NCj4gPj4+DQo+ID4+PiBUaGFua3MuDQo+ ID4+Pg0KPiA+Pj4gQ2hlZXJzLA0KPiA+Pj4gTWVobWV0DQo+ID4+Pg0KPiA+DQo+ID4NCj4gPg0K PiANCj4gDQoNCg0KDQo= From mcr@sandelman.ca Tue Jul 17 13:17:02 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F5721F8663 for ; Tue, 17 Jul 2012 13:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 d3PviTBLwsON for ; Tue, 17 Jul 2012 13:17:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E94B821F8621 for ; Tue, 17 Jul 2012 13:17:01 -0700 (PDT) Received: from sandelman.ca (herring.sandelman.ca [209.87.252.231]) by relay.sandelman.ca (Postfix) with ESMTPS id BD3D98719; Tue, 17 Jul 2012 16:14:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 274919811D; Tue, 17 Jul 2012 16:17:43 -0400 (EDT) Received: from herring.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 22D3B980DA; Tue, 17 Jul 2012 16:17:43 -0400 (EDT) From: Michael Richardson To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640405EE04@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A640405EE04@DEMUEXC006.nsn-intra.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 17 Jul 2012 16:17:43 -0400 Message-ID: <9972.1342556263@herring.sandelman.ca> Sender: mcr@sandelman.ca Cc: coman@ietf.org Subject: Re: [coman] COMA maillist has been renamed to COMAN maillist X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:17:02 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mehmet" =3D=3D Mehmet Ersue writes: Mehmet> The acronym was an unfortunate choice and not well accepted. Mehmet> There is no action necessary on your side. Too bad :-) COMA =3D Management of nodes with little brain, always sleeping. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAUAXIZ4qHRg3pndX9AQKWiQP+LHGFc/Nh1P00O0OkB6jxRFEOst7oBB8s CQgMp+ZMWya6V8ThiHXDdDFRKl5xpVJ3b+kJnmXhtY6gZ1PL0g0DlHHCIV5JFE+1 LA3pqz5USQA8BYHZSkz8kdj15FVzxQYROBuS30uOheIjh/sijKn2T4SQoyw7NOE0 bYzRHn1k4Zc= =c/P+ -----END PGP SIGNATURE----- --=-=-=-- From ietf-secretariat@ietf.org Wed Jul 18 07:31:51 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2551521F86B9; Wed, 18 Jul 2012 07:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.134 X-Spam-Level: X-Spam-Status: No, score=-103.134 tagged_above=-999 required=5 tests=[AWL=-0.535, 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 X92uAr4U3jGk; Wed, 18 Jul 2012 07:31:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD3F21F8678; Wed, 18 Jul 2012 07:31:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120718143150.32094.9979.idtracker@ietfa.amsl.com> Date: Wed, 18 Jul 2012 07:31:50 -0700 Cc: coman@ietf.org, bclaise@cisco.com, mehmet.ersue@nsn.com, rbonica@juniper.net Subject: [coman] New Non-WG Mailing List: coman -- Management of Constrained Networks and Devices X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 14:31:51 -0000 A new IETF non-working group email list has been created. = List address: coman@ietf.org = Archive: http://www.ietf.org/mail-archive/web/coman/ = To subscribe: https://www.ietf.org/mailman/listinfo/coman = Purpose: This list is for the discussion related to the management of = constrained networks and devices. The IETF so far has not developed = specific technologies for the management of constrained networks. There = is a need to understand the requirements for the management of such a = constrained network and its devices. = For additional information, please contact the list administrators. NOTE: This list replaces the former coma@ietf.org mailing list, which has b= een closed. On May 16, 2012, at 10:39 AM, IETF Secretariat wrote: > A new IETF non-working group email list has been created. = > = > List address: coma@ietf.org = > Archive: http://www.ietf.org/mail-archive/web/coma/ = > To subscribe: https://www.ietf.org/mailman/listinfo/coma = > = > Purpose: This list is for the discussion related to the management of = > constrained networks and devices. The IETF so far has not developed = > specific technologies for the management of constrained networks. = > There is a need to understand the requirements for the management of = > such a constrained network and its devices. = > = > For additional information, please contact the list administrators. From bclaise@cisco.com Fri Jul 20 03:36:15 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EDB21F85A5 for ; Fri, 20 Jul 2012 03:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PnW204P0C-Rw for ; Fri, 20 Jul 2012 03:36:15 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A74A421F85A7 for ; Fri, 20 Jul 2012 03:36:14 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6KAb9Z0028951; Fri, 20 Jul 2012 12:37:09 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6KAb8Q0014114; Fri, 20 Jul 2012 12:37:08 +0200 (CEST) Message-ID: <500934D3.7060803@cisco.com> Date: Fri, 20 Jul 2012 03:37:07 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A640405EE04@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640405EE04@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: coman@ietf.org Subject: Re: [coman] COMA maillist has been renamed to COMAN maillist X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 10:36:15 -0000 Hi Mehmet, And the COMAN acronym stands for? Regards, Benoit. > FYI > > The acronym was an unfortunate choice and not well accepted. > There is no action necessary on your side. > > Cheers, > Mehmet > > > -----Original Message----- > From: ext Steve Young via RT [mailto:ietf-action@ietf.org] > Sent: Tuesday, July 17, 2012 7:00 PM > To: "OtherRecipients of www.ietf.org/rt Ticket #49286" > Cc: Ersue, Mehmet (NSN - DE/Munich); rbonica@juniper.net > Subject: [www.ietf.org/rt #49286] Re: [OPS-DIR] OPS DIR Lunch > > Hi Benoit, > > Coman has been created. The subscriber list and archive have been > copied from coma to coman. List details have been sent to the list > admins via email. > > Coma has been closed. Anybody trying to send to coma will receive a > message telling them the list has moved to coman. > > Best regards, > Steve > > On Mon Jul 16 02:51:37 2012, bclaise@cisco.com wrote: >> Hi Steve, >> >>> Hi Benoit, >>> >>> Yes, we can do that by creating a new mailing list with the new >> name, >>> then copying the subscribers and archive from the old list to the >> new list. >>> Just let me know if you would like me to do that. >> Yes, please. Start the process. >> >> Regards, Benoit. >>> Best regards, >>> Steve >>> >>> On Wed Jul 11 08:00:03 2012, bclaise@cisco.com wrote: >>>> Dear secretariat, >>>> >>>> Is there a way to change an non working group mailing list name, >> while >>>> keeping the name archive and all the people subscribed? >>>> In this case, the proposal is to change "coma" to "coman". >>>> >>>> Regards, Benoit. >>>> >>>>> Hi Benoit, >>>>> >>>>> I would like to address the request of Ron to change the acronym >> from >>>>> COMA to something else. >>>>> After some thinking I would like to propose to use COMAN as >> acronym. >>>>> How is the process for this change? I assume you need to ask the >>>>> secretary and they have to copy the mail archive. >>>>> May be we need to keep COMA alive for some time with a message >> sent back >>>>> to use COMAN instead. >>>>> >>>>> Thanks. >>>>> >>>>> Cheers, >>>>> Mehmet >>>>> >>> >>> >> > > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > > From mehmet.ersue@nsn.com Fri Jul 20 03:37:36 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B4E21F85C4 for ; Fri, 20 Jul 2012 03:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 a9fgxBHwsvTf for ; Fri, 20 Jul 2012 03:37:35 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id BB33421F85C2 for ; Fri, 20 Jul 2012 03:37:28 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6KAcLE0002128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jul 2012 12:38:21 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6KAcLG2031813; Fri, 20 Jul 2012 12:38:21 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jul 2012 12:38:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jul 2012 12:37:59 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64040A3FFF@DEMUEXC006.nsn-intra.net> In-Reply-To: <500934D3.7060803@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [coman] COMA maillist has been renamed to COMAN maillist Thread-Index: Ac1mY5+aYeG4MVkuRuG9XouLELOxmgAABENA References: <80A0822C5E9A4440A5117C2F4CD36A640405EE04@DEMUEXC006.nsn-intra.net> <500934D3.7060803@cisco.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Benoit Claise" X-OriginalArrivalTime: 20 Jul 2012 10:38:20.0891 (UTC) FILETIME=[C81F6AB0:01CD6663] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2808 X-purgate-ID: 151667::1342780701-00002E58-A2150DDC/0-0/0-0 Cc: coman@ietf.org Subject: Re: [coman] COMA maillist has been renamed to COMAN maillist X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 10:37:36 -0000 Constrained MANanagement Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Benoit Claise [mailto:bclaise@cisco.com] > Sent: Friday, July 20, 2012 12:37 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: coman@ietf.org > Subject: Re: [coman] COMA maillist has been renamed to COMAN maillist >=20 > Hi Mehmet, >=20 > And the COMAN acronym stands for? >=20 > Regards, Benoit. > > FYI > > > > The acronym was an unfortunate choice and not well accepted. > > There is no action necessary on your side. > > > > Cheers, > > Mehmet > > > > > > -----Original Message----- > > From: ext Steve Young via RT [mailto:ietf-action@ietf.org] > > Sent: Tuesday, July 17, 2012 7:00 PM > > To: "OtherRecipients of www.ietf.org/rt Ticket #49286" > > Cc: Ersue, Mehmet (NSN - DE/Munich); rbonica@juniper.net > > Subject: [www.ietf.org/rt #49286] Re: [OPS-DIR] OPS DIR Lunch > > > > Hi Benoit, > > > > Coman has been created. The subscriber list and archive have been > > copied from coma to coman. List details have been sent to the list > > admins via email. > > > > Coma has been closed. Anybody trying to send to coma will receive a > > message telling them the list has moved to coman. > > > > Best regards, > > Steve > > > > On Mon Jul 16 02:51:37 2012, bclaise@cisco.com wrote: > >> Hi Steve, > >> > >>> Hi Benoit, > >>> > >>> Yes, we can do that by creating a new mailing list with the new > >> name, > >>> then copying the subscribers and archive from the old list to the > >> new list. > >>> Just let me know if you would like me to do that. > >> Yes, please. Start the process. > >> > >> Regards, Benoit. > >>> Best regards, > >>> Steve > >>> > >>> On Wed Jul 11 08:00:03 2012, bclaise@cisco.com wrote: > >>>> Dear secretariat, > >>>> > >>>> Is there a way to change an non working group mailing list name, > >> while > >>>> keeping the name archive and all the people subscribed? > >>>> In this case, the proposal is to change "coma" to "coman". > >>>> > >>>> Regards, Benoit. > >>>> > >>>>> Hi Benoit, > >>>>> > >>>>> I would like to address the request of Ron to change the acronym > >> from > >>>>> COMA to something else. > >>>>> After some thinking I would like to propose to use COMAN as > >> acronym. > >>>>> How is the process for this change? I assume you need to ask the > >>>>> secretary and they have to copy the mail archive. > >>>>> May be we need to keep COMA alive for some time with a message > >> sent back > >>>>> to use COMAN instead. > >>>>> > >>>>> Thanks. > >>>>> > >>>>> Cheers, > >>>>> Mehmet > >>>>> > >>> > >>> > >> > > > > > > _______________________________________________ > > coman mailing list > > coman@ietf.org > > https://www.ietf.org/mailman/listinfo/coman > > > > From mehmet.ersue@nsn.com Tue Jul 24 09:47:08 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B149321F8611 for ; Tue, 24 Jul 2012 09:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 S0dC1JMgDjsW for ; Tue, 24 Jul 2012 09:47:08 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id EE87E21F8589 for ; Tue, 24 Jul 2012 09:47:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6OGl3YE028372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jul 2012 18:47:03 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6OGkxCV031570 for ; Tue, 24 Jul 2012 18:47:03 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jul 2012 18:46:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jul 2012 18:46:26 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64040F1DEB@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Coman side discussion on August 1st, Wednesday 10:00 - 11:30 Thread-Index: Ac1pu92QG0SdjshPS9e4V5668Uhx5A== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 24 Jul 2012 16:46:27.0270 (UTC) FILETIME=[DE486660:01CD69BB] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 425 X-purgate-ID: 151667::1343148423-00002E58-8A7BD8BB/0-0/0-0 Subject: [coman] Coman side discussion on August 1st, Wednesday 10:00 - 11:30 X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 16:47:08 -0000 Hi All, we will have a Coman side discussion on August 1st, Wednesday 10:00 - 11:30 in the IESG Breakout Room (ask IETF secretary if you cannot find it). Topics: -01 draft, doc structure, use cases, constrained device classes, criteria for requirements, section on requirements, etc. PS: This is just an adhoc discussion. No Jabber, no recording. Some minutes will be made available. Cheers,=20 Mehmet=20 From bclaise@cisco.com Sat Jul 28 18:19:27 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2C921F86DB for ; Sat, 28 Jul 2012 18:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 YxXLfumxPpmt for ; Sat, 28 Jul 2012 18:19:26 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id CF6D321F851E for ; Sat, 28 Jul 2012 18:19:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6T1JOfm012194 for ; Sat, 28 Jul 2012 21:19:24 -0400 (EDT) Received: from [10.21.68.45] (sjc-vpn3-1069.cisco.com [10.21.68.45]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6T1JDbb029499 for ; Sat, 28 Jul 2012 18:19:13 -0700 (PDT) Message-ID: <50148F91.80009@cisco.com> Date: Sat, 28 Jul 2012 18:19:13 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: coman@ietf.org References: <50142868.7090306@cisco.com> In-Reply-To: <50142868.7090306@cisco.com> X-Forwarded-Message-Id: <50142868.7090306@cisco.com> Content-Type: multipart/alternative; boundary="------------090909020208010007000202" Subject: [coman] Feedback on draft-ersue-constrained-mgmt-01 X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 01:19:27 -0000 This is a multi-part message in MIME format. --------------090909020208010007000202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mehmet, Dan, Juergen, Thanks for this draft. Here are a couple of high level points - The abstract contains: "management of networks with constrained devices." However, there are two distinct parts: 1. management of constrained networks 2. management of constrained devices I believe you should be explicit. Reading further, I found was I was after: "However, the IETF so far has not developed any specific technologies for the management of constrained devices and the networks comprised by constrained devices. " - I thought you did a good job explaining the different options in 1.3 . Network Topology Options . . . . . . . . . . . . . . . . .5 1.4 . Management Topology Options . . . . . . . . . . . . . . .5 1.5 . Constrained Device Classes . . . . . . . . . . . . . . . .6 Btw, it deserves it own section. I'm missing the series of requirements based on FCAPS. Examples: * I must be able to upgrade the firmware of all my constrained devices in a limited set of operations from my NMS. * I must be able to push data from my constrained devices * etc.. This is essential to determine which problem we try to solve. So I agree that starting from the use cases is a good way forward. - Instead of talking about constrained device classes primarily in terms of data size, and code size, it might be worth to classify them based on features. Example: a Class-0 is, by definition, so small I can't fit a security protocol in there. In other words, put table 1, as informational, as of 2012. Anyway, this classification (if any) should not come from the OPS people, but from the constrained devices expert. - for 3.1 "environmental monitoring", have a look at this old draft http://www.watersprings.org/pub/id/draft-braun-core-compressed-ipfix-03.txt Applications that use smart sensors for accounting purposes for long time measurements can benefit from the use of Compressed IPFIX. One application for IPFIX can be long term monitoring of large physical volumes. In [Tolle05], Tolle et al. built a system for monitoring a "70-meter tall redwood tree, at a density interval of 5 minutes in time and 2 meters in space". The sensor node infrastructure was deployed to measure the air temperature, relative humidity and photosynthetically active solar radiation over a long time period. - the use cases are good, but I'm missing the specific requirements per use case. Some of them are inserted though, but somehow "hidden" with the paragraph. For example: The constrained devices in such a network need to be able to establish configuration themselves (auto-configuration) and might need to deal with error conditions as much as possible locally. Access control has to be provided with multi-level administrative access and security. I guess that you want to clearly mention the label the requirements within the use case, or have an extra field in the requirement section 4. expressing the use case. A better way would be to group the use cases based on some criterias: architecture, constrained network or not, requirements... whatever makes sense. - In some of the use cases, we should add some numbers regarding how many constrained we speak about. - For some use cases, it's not clear if we speak about constrained network or constrained devices or both. Example: transport application, infrastructure monitoring. - I'm wondering different forums have not been listing the constrained network/devices use cases already? Can we reference some work? - I'm really interested by the feedback on this draft, from constrained device experts. CORE WG might be a good starting point. - " Current network management protocols, such as SNMP and Netconf, may be used (e.g., using interfaces such as the NHDP-MIB [I-D.ietf-manet-nhdp-mib ]), however, given the constrained routers and dynamic topology, not adapted to community networks. " However, you mentioned Linksys as an example. Do you consider a Linksys device as constrained? - Section 4.2. I make a difference between auto-configuration and re-configuration. A NMS might want to push a new config to constrained devices Regards, Benoit. --------------090909020208010007000202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mehmet, Dan, Juergen,

Thanks for this draft.
Here are a couple of high level points

- The abstract contains: "management of networks with constrained devices."
However, there are two distinct parts:
1. management of constrained networks
2. management of constrained devices
I believe you should be explicit.
Reading further, I found was I was after: "However, the IETF so far has not developed any specific technologies for the management of constrained devices and the networks comprised by constrained devices. "


- I thought you did a good job explaining the different options in
     1.3.  Network Topology Options . . . . . . . . . . . . . . . . .  5
     1.4.  Management Topology Options  . . . . . . . . . . . . . . .  5
     1.5.  Constrained Device Classes . . . . . . . . . . . . . . . .  6
Btw, it deserves it own section.
I'm missing the series of requirements based on FCAPS.
Examples:
     * I must be able to upgrade the firmware of all my constrained devices in a limited set of operations from my NMS.
    * I must be able to push data from my constrained devices
    * etc..
This is essential to determine which problem we try to solve. So I agree that starting from the use cases is a good way forward.

- Instead of talking about constrained device classes primarily in terms of data size, and code size, it might be worth to classify them based on features. Example: a Class-0 is, by definition, so small I can't fit  a security protocol in there. In other words, put table 1, as informational, as of 2012. Anyway, this classification (if any) should not come from the OPS people, but from the constrained devices expert.

- for 3.1 "environmental monitoring", have a look at this old draft
http://www.watersprings.org/pub/id/draft-braun-core-compressed-ipfix-03.txt
   Applications that use smart sensors for accounting purposes for long
   time measurements can benefit from the use of Compressed IPFIX.  One
   application for IPFIX can be long term monitoring of large physical
   volumes.  In [Tolle05], Tolle et al. built a system for monitoring a
   "70-meter tall redwood tree, at a density interval of 5 minutes in
   time and 2 meters in space".  The sensor node infrastructure was
   deployed to measure the air temperature, relative humidity and
   photosynthetically active solar radiation over a long time period.

- the use cases are good, but I'm missing the specific requirements per use case.
Some of them are inserted though, but somehow "hidden" with the paragraph.
For example: 
   The constrained devices in such a network need to be able
   to establish configuration themselves (auto-configuration) and might
   need to deal with error conditions as much as possible locally.
   Access control has to be provided with multi-level administrative
   access and security.
I guess that you want to clearly mention the label the requirements within the use case, or have an extra field in the requirement section 4. expressing the use case.
A better way would be to group the use cases based on some criterias: architecture, constrained network or not, requirements... whatever makes sense.

- In some of the use cases, we should add some numbers regarding how many constrained we speak about.

- For some use cases, it's not clear if we speak about constrained network or constrained devices or both. Example: transport application, infrastructure monitoring.

- I'm wondering different forums have not been listing the constrained network/devices use cases already? Can we reference some work?

- I'm really interested by the feedback on this draft, from constrained device experts. CORE WG might be a good starting point.

- " Current network management protocols, such as SNMP and Netconf, may be used (e.g., using interfaces such as the NHDP-MIB [I-D.ietf-manet-nhdp-mib]), however, given the constrained routers and dynamic topology, not adapted to community networks. "
However, you mentioned Linksys as an example. Do you consider a Linksys device as constrained?

- Section 4.2. I make a difference between auto-configuration and re-configuration.
A NMS might want to push a new config to constrained devices

Regards, Benoit.
--------------090909020208010007000202-- From j.schoenwaelder@jacobs-university.de Sat Jul 28 18:39:43 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF4F21F86E1 for ; Sat, 28 Jul 2012 18:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 IH3kNV3bGsk8 for ; Sat, 28 Jul 2012 18:39:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 81BD821F86D9 for ; Sat, 28 Jul 2012 18:39:41 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AC8620C0A; Sun, 29 Jul 2012 03:39:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0dMbXU9JQNwA; Sun, 29 Jul 2012 03:39:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C733B20BE9; Sun, 29 Jul 2012 03:39:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0FBAB20F8966; Sun, 29 Jul 2012 03:39:37 +0200 (CEST) Date: Sun, 29 Jul 2012 03:39:37 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20120729013937.GA73296@elstar.local> Mail-Followup-To: Benoit Claise , coman@ietf.org References: <50142868.7090306@cisco.com> <50148F91.80009@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50148F91.80009@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: coman@ietf.org Subject: Re: [coman] Feedback on draft-ersue-constrained-mgmt-01 X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 01:39:43 -0000 On Sat, Jul 28, 2012 at 06:19:13PM -0700, Benoit Claise wrote: > Mehmet, Dan, Juergen, > > Thanks for this draft. > Here are a couple of high level points > > - The abstract contains: "management of networks with constrained devices." > However, there are two distinct parts: > 1. management of constrained networks > 2. management of constrained devices > I believe you should be explicit. Well, we tried to be specific. ;-) There are constrained networks (e.g. underwater networks or networks in outer space) that we think are not the target of this document. We also thought management of constrained devices to be too restrictive since such devices often form networks that need to be managed as well. Hence we ended up with "management of networks with constrained devices". Probably not perfect but... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Mon Jul 30 10:30:05 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122F421F861A for ; Mon, 30 Jul 2012 10:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 LkcqanrkJP7r for ; Mon, 30 Jul 2012 10:30:03 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09811E816F for ; Mon, 30 Jul 2012 10:29:59 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6UHTvfY025064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Jul 2012 19:29:57 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6UHTv3i014375; Mon, 30 Jul 2012 19:29:57 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jul 2012 19:29:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jul 2012 19:29:54 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6404136172@DEMUEXC006.nsn-intra.net> In-Reply-To: <50148F91.80009@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [coman] Feedback on draft-ersue-constrained-mgmt-01 Thread-Index: Ac1tKDPgt66z9HNUTliZl3lcXCG1SwAe305g References: <50142868.7090306@cisco.com> <50148F91.80009@cisco.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Benoit Claise" , X-OriginalArrivalTime: 30 Jul 2012 17:29:57.0279 (UTC) FILETIME=[F072AAF0:01CD6E78] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5450 X-purgate-ID: 151667::1343669397-00002E58-E62FA2A2/0-0/0-0 Subject: Re: [coman] Feedback on draft-ersue-constrained-mgmt-01 X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 17:30:05 -0000 Hi Benoit, thank you for your comments. In general the document is an early draft and currently does not cover the requirements. > From: coman-bounces@ietf.org [mailto:coman-bounces@ietf.org] On Behalf Of ext Benoit Claise > Sent: Saturday, July 28, 2012 6:19 PM > To: coman@ietf.org > Subject: [coman] Feedback on draft-ersue-constrained-mgmt-01 >=20 > Mehmet, Dan, Juergen, >=20 > Thanks for this draft. > Here are a couple of high level points >=20 > - The abstract contains: "management of networks with constrained devices." > However, there are two distinct parts:=20 > 1. management of constrained networks > 2. management of constrained devices > I believe you should be explicit. > Reading further, I found was I was after: "However, the IETF so far has not developed=20 > any specific technologies for the management of constrained devices and the networks comprised by constrained devices. " Agree. > - I thought you did a good job explaining the different options in > 1.3. Network Topology Options . . . . . . . . . . . . . . . . . 5 > 1.4. Management Topology Options . . . . . . . . . . . . . . . 5 > 1.5. Constrained Device Classes . . . . . . . . . . . . . . . . 6 > Btw, it deserves it own section. Ok. > I'm missing the series of requirements based on FCAPS. > Examples: > * I must be able to upgrade the firmware of all my constrained devices in a limited set=20 > of operations from my NMS. > * I must be able to push data from my constrained devices > * etc.. > This is essential to determine which problem we try to solve. So I agree that starting from=20 > the use cases is a good way forward. How the requirements should be structured is still open for discussion. =20 > - Instead of talking about constrained device classes primarily in terms of data size, and=20 > code size, it might be worth to classify them based on features. Example: a Class-0 is, by definition, so small I can't fit a security protocol in there. In other words, put table 1, as informational, as of 2012. Anyway, this classification (if any) should not come from the OPS people, but from the constrained devices expert. A discussion with constrained devices experts will be valuable. > - for 3.1 "environmental monitoring", have a look at this old draft > http://www.watersprings.org/pub/id/draft-braun-core-compressed-ipfix-03. txt > Applications that use smart sensors for accounting purposes for long > time measurements can benefit from the use of Compressed IPFIX. One > application for IPFIX can be long term monitoring of large physical > volumes. In [Tolle05], Tolle et al. built a system for monitoring a > "70-meter tall redwood tree, at a density interval of 5 minutes in > time and 2 meters in space". The sensor node infrastructure was > deployed to measure the air temperature, relative humidity and > photosynthetically active solar radiation over a long time period. >=20 > - the use cases are good, but I'm missing the specific requirements per use case. > Some of them are inserted though, but somehow "hidden" with the paragraph. > For example:=20 > The constrained devices in such a network need to be able > to establish configuration themselves (auto-configuration) and might > need to deal with error conditions as much as possible locally. > Access control has to be provided with multi-level administrative > access and security. > I guess that you want to clearly mention the label the requirements within the use case,=20 > or have an extra field in the requirement section 4. expressing the use case. > A better way would be to group the use cases based on some criterias: architecture,=20 > constrained network or not, requirements... whatever makes sense.>=20 >=20 > - In some of the use cases, we should add some numbers regarding how many=20 > constrained we speak about. =20 >=20 > - For some use cases, it's not clear if we speak about constrained network or constrained > devices or both. Example: transport application, infrastructure monitoring. >=20 > - I'm wondering different forums have not been listing the constrained network/devices > use cases already? Can we reference some work? > - I'm really interested by the feedback on this draft, from constrained device experts.=20 > CORE WG might be a good starting point. Once we reach some maturity we will ask for feedback. Core experts are welcome to jump into the discussion. > - " Current network management protocols, such as SNMP and Netconf, may be used=20 > (e.g., using interfaces such as the NHDP-MIB [I-D.ietf-manet-nhdp-mib]), however, given=20 > the constrained routers and dynamic topology, not adapted to community networks. " > However, you mentioned Linksys as an example. Do you consider a Linksys device as=20 > constrained? Community networks is a special case where the network has an instable nature but is usually formed by non-constrained devices with sufficient resources. So in this case the network is constrained. PS: We actually were aiming not to propose any technologies. > - Section 4.2. I make a difference between auto-configuration and re-configuration. > A NMS might want to push a new config to constrained devices > > Regards, Benoit. So, it is true. There is still a lot to do. Mehmet From gtolle@cisco.com Tue Jul 31 17:10:32 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585EA21F8831 for ; Tue, 31 Jul 2012 17:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.284 X-Spam-Level: X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] 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 IkCmPl8WiyDA for ; Tue, 31 Jul 2012 17:10:31 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4620721F881C for ; Tue, 31 Jul 2012 17:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gtolle@cisco.com; l=7890; q=dns/txt; s=iport; t=1343779831; x=1344989431; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=T3MD7KMZ4xMnlqaODM1MZVYoQEEMiCeI8+QB2KBaBng=; b=aa8C3nV4+a/RmRNbEzdvC/KRTO1H7IF62MD/aoGcvmKFYV12BZiv//YE +2p3X5W9naIYfXJJq103YO1Ib+u6lLsOXhxxg/lmfgklgos/GSYAl8FGP xJUEbBtY8F1Z+U3DqLe50GEuoTPLWv4uVIe9A5z4vC7rUZe0iNV1y0+Bc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALNzGFCtJV2c/2dsb2JhbABFuXyBB4InEgEnNB0BPkInBCwJh2uaPoEooFuLZAyGAmADhRqQLY4ngWaCX4FWAiE X-IronPort-AV: E=Sophos;i="4.77,690,1336348800"; d="scan'208";a="107235238" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2012 00:10:15 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q710AE9o021867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Aug 2012 00:10:15 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.162]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 19:10:14 -0500 From: "Gilman Tolle (gtolle)" To: "coman@ietf.org" Thread-Topic: Automated Metering Infrastructure (AMI) use case Thread-Index: AQHNb3oFUupeIbwJkU2PS1Xa9CzeRA== Date: Wed, 1 Aug 2012 00:10:13 +0000 Message-ID: <7CB5848F-CDFA-4634-B8DC-3CC18F50A270@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.150.64] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.001 x-tm-as-result: No--30.774000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [coman] Automated Metering Infrastructure (AMI) use case X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 00:10:32 -0000 Hi all, I've been developing a constrained device network management application fo= r my customers, and I've been following the COMAN list. I support the work that's happening here, and am ready to help improve it. Automated Metering Infrastructure (AMI) is one use case that should be adde= d to the requirements document. Here is some text that describes this use c= ase, as well as some constrained network management requirements derived fr= om it. I'm not at the IETF this week, but will be participating in the COMAN effor= t via the mailing list. Gil Automated Metering Infrastructure (AMI) Use Case ------------------------------------------------ An AMI network enables an electric utility to retrieve frequent electric us= age data from each electric meter installed at a customer's home or busines= s. With an AMI network, a utility can also receive immediate notification o= f power outages when they occur, directly from the electric meters that are= experiencing those outages. In addition, if the AMI network is designed to= be open and extensible, it could serve as the backbone for communicating w= ith other distribution automation devices besides meters, which could inclu= de transformers and reclosers. In this use case, each meter in the AMI network contains a constrained devi= ce. These devices are typically Class 2 devices. Each meter connects to a c= onstrained mesh network with a low-bandwidth radio. These radios can be 50,= 150, or 200 kbps at raw link speed, but actual network throughput may be s= ignificantly lower due to forward error correction, multihop delays, MAC de= lays, lossy links, and protocol overhead. The constrained devices are used to connect the metering logic with the net= work, so that usage data and outage notifications can be sent back to the u= tility's headend systems over the network. These headend systems are instal= led in a data center managed by the utility, and may include meter data col= lection systems, meter data management systems, and outage management syste= ms. The meters are connected to a mesh network, and each meter can act as both = a source of traffic and as a router for other meters' traffic. In a typical= AMI application, smaller amounts of traffic (read requests, configuration)= flow "downstream" from the headend to the mesh, and larger amounts of traf= fic flow "upstream" from the mesh to the headend. But, during a firmware up= date operation, larger amounts of traffic might flow downstream while small= er amounts flow upstream. Other applications that make use of the AMI netwo= rk may have their own distinct traffic flows. The mesh network is anchored by a collection of higher-end devices which co= ntain a mesh radio that connects to the constrained network as well as a ba= ckhaul link that connects to a less-constrained network. The backhaul link = could be cellular, WiMAX, or Ethernet, depending on the backhaul networking= technology that the utility has chosen. These higher-end devices (termed "= routers" in this use case) are typically installed on utility poles through= out the service territory. Router devices are typically less constrained th= an meters, and often contain the full routing table for all the endpoints r= outing through them, but this may vary depending on the routing protocol in= use. In this use case, the utility typically installs on the order of 1000 meter= s per router. The collection of meters that are routing through a specific = router is called a "PAN". When powered on, each meter is designed to discov= er the nearby PANs, select the optimal PAN to join, and select the optimal = meters in that PAN to route through when sending data to the headend. After= joining the PAN, the meter is designed to continuously monitor and optimiz= e its connection to the PAN, and it will change routes and change PANs as n= eeded. As a result of this continuous optimization, PAN membership can chan= ge frequently throughout the life of the network. Each PAN may be configured to share an encryption key, providing confidenti= ality for all data traffic within the PAN. This key may be obtained by a me= ter only after an end-to-end authentication process based on certificates, = ensuring that only authorized and authenticated meters are allowed to join = the PAN, and by extension, the mesh network as a whole. After joining the PAN, each endpoint obtains a private routable IPv6 addres= s that enables end-to-end communication between the headend systems and eac= h meter. In this use case, the meters are always "on", and should have a pi= ng round trip time of roughly 200ms per hop. But, due to lossy links and ne= twork optimization, not every meter will be immediately ping-able, though e= ventually every meter will be able to exchange data with the headend. In a large AMI deployment, there may be 10 million meters supported by 10,0= 00 routers, spread across a very large geographic area. Within a single PAN= , the meters may range between 1 and 20 hops from the router. During the deployment process, these meters are installed and turned on in = large batches, and those meters must be authenticated, given addresses, and= provisioned with any configuration information necessary for their operati= on. During deployment and after deployment is finished, the network must be= monitored continuously and failures must be handled. Configuration paramet= ers may need to be changed on large numbers of devices, but most of the dev= ices will be running the same configuration. And, eventually, the firmware = in those meters will need to be upgraded, and this must also be done in lar= ge batches because most of the devices will be running the same firmware im= age. Because there may be thousands of routers, this operational model (batch de= ployment, automatic provisioning, continuous monitoring, batch reconfigurat= ion, batch firmware update) should also apply to the routers as well as the= constrained devices. The scale is different (thousands instead of millions= ) but still large enough to make individual management impractical for rout= ers as well. AMI Management Requirements --------------------------- To support the use case above, the headend must contain a set of management= systems that meet the following requirements. The first two requirements m= ay fall outside the typical definition of "network management system" and i= nto authentication and provisioning systems (e.g. RADIUS, DHCPv6), but the = full use case does require all six. 1. Securely authenticate a large number of constrained devices as they atte= mpt to join the network at the link layer, and check those devices against = a master list of authorized devices. 2. Provide routable IPv6 addresses for a large number of constrained device= s after they have joined the network. 3. Support group-based provisioning and coordinated reconfiguration of a la= rge-scale network of constrained devices with automatic synchronization and= eventual consistency to handle lossy links and temporarily unavailable dev= ices. 4. Collect network status, performance metrics, and fault event information= for a large-scale network of constrained devices into a central location w= ith user interfaces that enable monitoring and troubleshooting of large net= works (millions of devices) by a single person or small team. 5. Support group-based firmware update of those constrained devices, with e= ventual consistency and coordinated reload times. 6. Support this kind of group-based provisioning, configuration, monitoring= , and firmware update functionality for multiple device classes within a si= ngle network, including constrained mesh endpoints and less constrained rou= ters. From bclaise@cisco.com Tue Jul 31 23:18:39 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E2621F86B9 for ; Tue, 31 Jul 2012 23:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 b84SkOH0BpwL for ; Tue, 31 Jul 2012 23:18:38 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id B08FD21F86B6 for ; Tue, 31 Jul 2012 23:18:38 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q716Ibxb017535; Wed, 1 Aug 2012 02:18:37 -0400 (EDT) Received: from [10.82.215.51] (rtp-vpn4-1843.cisco.com [10.82.215.51]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q716IanY005426; Wed, 1 Aug 2012 02:18:37 -0400 (EDT) Message-ID: <5018CA3C.8010805@cisco.com> Date: Tue, 31 Jul 2012 23:18:36 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <80A0822C5E9A4440A5117C2F4CD36A64040F1DEB@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64040F1DEB@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: coman@ietf.org Subject: Re: [coman] Coman side discussion on August 1st, Wednesday 10:00 - 11:30 X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 06:18:39 -0000 Dear all, The room is Lord Byron. Regards, Benoit. > Hi All, > > we will have a Coman side discussion on August 1st, Wednesday 10:00 - > 11:30 in the IESG Breakout Room (ask IETF secretary if you cannot find > it). > Topics: -01 draft, doc structure, use cases, constrained device classes, > criteria for requirements, section on requirements, etc. > > PS: This is just an adhoc discussion. No Jabber, no recording. Some > minutes will be made available. > > Cheers, > Mehmet > > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > >