From william.d.ivancic@nasa.gov Wed Jul 11 06:12:56 2012 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 Wed Jul 11 07:22:55 2012 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== From mehmet.ersue@nsn.com Mon Jul 16 05:57:57 2012 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-- From mcr@sandelman.ca Mon Jul 16 07:02:25 2012 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----- --=-=-=-- From william.d.ivancic@nasa.gov Mon Jul 16 10:45:17 2012 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_-- From pthubert@cisco.com Mon Jul 16 23:47:25 2012 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_-- From mehmet.ersue@nsn.com Tue Jul 17 03:09:03 2012 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-- From mehmet.ersue@nsn.com Tue Jul 17 03:27:39 2012 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 From levent.gurgen@cea.fr Tue Jul 17 03:34:30 2012 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 From j.schoenwaelder@jacobs-university.de Tue Jul 17 03:55:04 2012 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 From levent.gurgen@cea.fr Tue Jul 17 04:18:56 2012 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 From mehmet.ersue@nsn.com Tue Jul 17 04:41:21 2012 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 From ulrich@herberg.name Tue Jul 17 09:26:58 2012 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--