From dromasca@avaya.com Mon Oct 8 03:01:44 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 1AEB821F8762 for ; Mon, 8 Oct 2012 03:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.012 X-Spam-Level: X-Spam-Status: No, score=-103.012 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p785xSjNaY2 for ; Mon, 8 Oct 2012 03:01:43 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4092321F8732 for ; Mon, 8 Oct 2012 03:01:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFmiclDGmAcF/2dsb2JhbABFvySBCIIgAQEBAQIBAQEBDx4+EAcGAQgNBAQBAQsGDAsBByYfBwEBBQQBBAoJCBqHXQYLmBiEJZwhBItPG4JUgkFgA4gjk0yKKoJv X-IronPort-AV: E=Sophos;i="4.80,552,1344225600"; d="scan'208";a="327693738" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Oct 2012 05:55:42 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Oct 2012 05:53:08 -0400 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: Mon, 8 Oct 2012 12:01:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] [6lowpan] Constrained Node/Network Cluster @ IETF85 Thread-Index: Ac2kbrgHQ8JjMTVnSuGYOo7VXeqcxQAzQR6A From: "Romascanu, Dan (Dan)" To: Subject: [coman] FW: [core] [6lowpan] Constrained Node/Network Cluster @ IETF85 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, 08 Oct 2012 10:01:44 -0000 Some if not all these meetings should interest also the folks who are = looking at the constrained management space.=20 Regards, Dan -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Carsten Bormann Sent: Sunday, October 07, 2012 11:32 AM To: lwip@ietf.org; core@ietf.org WG; roll WG; 6lowpan@ietf.org Subject: Re: [core] [6lowpan] Constrained Node/Network Cluster @ IETF85 On Oct 5, 2012, at 00:09, Carsten Bormann wrote: > Here is my usual eclectic condensed agenda. ... and here is an update based on yesterday's changes. As you can see, the lwig/core overlap is fixed (thanks, Barry), and = there have been a few other relocations to avoid other conflicts. Gr=FC=DFe, Carsten MONDAY, November 5, 2012 0900-1130 Morning Session I Salon A APP apparea Applications Area Open Meeting - Combined with = APPSAWG Salon D INT 6man IPv6 Maintenance WG 1300-1500 Afternoon Session I Salon D APP httpbis Hypertext Transfer Protocol Bis WG Grand C INT intarea Internet Area Working Group WG 1520-1720 Afternoon Session II Salon C RTG *** roll Routing Over Low power and Lossy networks WG Grand D TSV tsvarea Transport Area Open Meeting 1740-1940 Afternoon Session III Salon E INT *** lwig Light-Weight Implementation Guidance WG TUESDAY, November 6, 2012 0900-1130 Morning Session I Salon E APP httpbis Hypertext Transfer Protocol Bis WG 1300-1500 Afternoon Session I Grand C APP *** core Constrained RESTful Environments WG WEDNESDAY, November 7, 2012 0900-1130 Morning Session I Salon D INT homenet Home Networking WG Salon A SEC jose Javascript Object Signing and Encryption WG 1300-1430 Afternoon Session I Grand D SEC httpauth HTTP Authentication Mechanisms BOF THURSDAY, November 8, 2012 0900-1130 Morning Session I Salon A SEC oauth Web Authorization Protocol WG 1300-1500 Afternoon Session I Salon D OPS v6ops IPv6 Operations WG Grand D RTG rtgarea Routing Area Open Meeting Salon E TSV rmcat RTP Media Congestion Avoidance Techniques WG 1510-1710 Afternoon Session II Salon A OPS eman Energy Management WG Salon D OPS v6ops IPv6 Operations WG Salon C SEC saag Security Area Open Meeting Grand C TSV tsvwg Transport Area Working Group WG FRIDAY, November 9, 2012 0900-1100 Morning Session I Salon D TSV tsvwg Transport Area Working Group WG 1120-1330 Afternoon Session I/II Salon E APP *** core Constrained RESTful Environments WG _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From mehmet.ersue@nsn.com Wed Oct 17 01:18:04 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 2D0E821F879F; Wed, 17 Oct 2012 01:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve0MDJ3nsF0I; Wed, 17 Oct 2012 01:18:03 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0DB21F8771; Wed, 17 Oct 2012 01:18:02 -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 q9H8Hxbl016776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Oct 2012 10:17:59 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9H8HqMJ016304; Wed, 17 Oct 2012 10:17:59 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Oct 2012 10:17:49 +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: Wed, 17 Oct 2012 10:17:48 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt Thread-Index: Ac2sP+SCkqdxpWNGTieoJPjKQSY0pA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 17 Oct 2012 08:17:49.0553 (UTC) FILETIME=[E56B1610:01CDAC3F] 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: 1790 X-purgate-ID: 151667::1350461879-000048BF-F962D7E1/0-0/0-0 Cc: opsawg@ietf.org Subject: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt 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, 17 Oct 2012 08:18:04 -0000 Hi All, we submitted an update for the constrained-mgmt draft on the "Management of Networks with Constrained Devices: Use Cases and Requirements". The draft hopefully addresses most of the issues we discussed in the last meeting.=20 I think it is already time to split the draft into three; e.g. problem statement, use cases and requirements. But this can be done after getting your feedback before and during IETF 85. I would highly appreciate your comments and any kind of discussion on the draft content especially on the requirements section. Thank you. Cheers,=20 Mehmet=20 -----Original Message----- From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 15, 2012 9:59 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-02.txt A new version of I-D, draft-ersue-constrained-mgmt-02.txt has been successfully submitted by Mehmet Ersue and posted to the IETF repository. Filename: draft-ersue-constrained-mgmt Revision: 02 Title: Management of Networks with Constrained Devices: Use Cases and Requirements Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 78 URL: http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt Status: http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt Htmlized: http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrained-mgmt-02 Abstract: This document raises the questions on and discusses the use cases and requirements for the management of networks with constrained devices. =20 The IETF Secretariat From ulrich@herberg.name Fri Oct 19 16:45:41 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 AAD9C21F8869 for ; Fri, 19 Oct 2012 16:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6tzXMtm9qpT for ; Fri, 19 Oct 2012 16:45:40 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35C1221F8834 for ; Fri, 19 Oct 2012 16:45:40 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1249340vbb.31 for ; Fri, 19 Oct 2012 16:45:39 -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=urjZBRUBkr7gH3jUSvvdW7gdzRtrFHknlzOrjakFdZc=; b=cx6v/15csiUZtPitg+u/+TUgkYZHr+BUOnyUpFiIUB0Mh9Kjy8bb3ORAqxhgTKOSz+ /Yw2UZVhxuykUX1lMu3vsOsbnCfQOE6XtEN7xU8rp1f/7/ldP2CeJPtIer+yeKU0MqRW 4xPy94YkgdNfgWcldqzvoUhUWbZ0U2G3IYLII= 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=urjZBRUBkr7gH3jUSvvdW7gdzRtrFHknlzOrjakFdZc=; b=RPs2rZXIv5GpZP2NCcoBWbEf4xNE0ocx96Z2+KvdyqWe/WK/kNbqChcAokyURgDxDj wUB75YfSZxlBYxdd+dBn7v6m+Oj05SE4aucWedhdp8+tj2J/QBGxdc0b0miMe4daxKNB V2KeJ/McJF3PXFEzL2PE4jHGA6jknyBOYqmTM2rWX335q/tkxpkDihmdIU4DN+Kt6PN/ F9s3feuqtcDCPcmEppSvCMLRNLFC2lBng33jDGs4QNhIJi2yl6BJKBKV1Uj82sLhfa9G P5aLhzCSi59eBHcXe8O05F/GxibpoYdIeYfizIN2gSq+BanyB6WvMqOnQBtngQK9ro2b lkYQ== MIME-Version: 1.0 Received: by 10.52.89.146 with SMTP id bo18mr2925278vdb.33.1350690339613; Fri, 19 Oct 2012 16:45:39 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Fri, 19 Oct 2012 16:45:39 -0700 (PDT) In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> Date: Fri, 19 Oct 2012 16:45:39 -0700 Message-ID: From: Ulrich Herberg To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=bcaec50162b5e4ea0c04cc7219c8 X-Gm-Message-State: ALoCoQl5tB/GpBzldH11+nEw8u17pTzAyW6sukce62xyn3N3oUKZi2rmum7dsWkxi8IiVGwLX+yG Cc: coman@ietf.org, opsawg@ietf.org Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt 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, 19 Oct 2012 23:45:41 -0000 --bcaec50162b5e4ea0c04cc7219c8 Content-Type: text/plain; charset=ISO-8859-1 Hi Mehmet, thank you for updating the draft. There is a huge amount of great work in it, and I think this will provide a great basis for further discussions. Indeed, splitting up the document would be required at some point. Some high-level comments: - Section 1.2 (Terminology): The definition of MANET and Intermediate entity (in COAP) come a bit surprising, since there has been no discussion before. Also, it seems inconsistent to define MANET, but not all the other use cases, such as AMI. - Section 1.3 (Constrained Device Classes): I know that this definition is taken from Lwig, but I doubt that it is of much use. The absolute values will change. While now there are still many C0 devices out, in five years, they will not exist (or rather, the number 10KB would need to be replaced by a larger number). I think I would prefer a classification based on the capabilities (e.g. can support full IP stack, or not) - Section 1.4 (constrained networks): I don't think this is a very consistent classification of networks. First, CN0 seems to be the least constrained network, whereas C0 devices are the most constrained. I would suggest the remain the same ordering (0 the most constrained up to a positive number). More importantly, there is a mixture with constrained devices in this definition. Since we talk about the network only, we should only talk about topology, lossy links, multi-hop, mobility etc. but not constrained devices. I don't understand why MANETs are not supported. Several of the use cases, such as the military use case, community networks and AMI are multi-hop networks with dynamic topology and lossy links. That is what I call a MANET. Even the definition of CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are nothing else than MANETs (only difference is that routers are usually non-mobile; nevertheless, the topology is still dynamic because of fluctuating links.). Is the intention to focus on non-mobile devices? Constrained networks are more difficult to define, as there are several aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I think that we need more discussion (but maybe after a BOF has been initiated?) - Section 1.5: (Network Topology Options): I think there is a mix between the topology (i.e., the graph that represents routers and communication links), traffic flows (which devices communicate with which other devices), and application layer (proxies and NMS). - Section 1.6: I like that. - Section 1.7: There is mixture of constrained networks (first bullet); I thought that constrained devices only means that they have little CPU power and memory. Can't that device still use cable connectivity (i.e. unconstrained network)? Or is it necessarily linked? I am unclear about the purpose of this whole section. What does it serve for? - Section 2: I think that the problem statement is not quite clear yet. It is hard to identify what the problems are; there are so many useful requirements in section 4, so maybe it could be better matched to these requirements. It would be nice to read section 4, and then say "ah, requirement x indeed logically follows from the problem y that has been described in section 2". - Section 3: I like the diverse use cases. That can be very useful to identify different requirements and problems. - Section 4: I very much appreciate the enormous effort for gathering the requirements. There will be detailed discussions about them (hopefully), but this is a very good list to start from. We have to define if the security related requirements also fit in this discussion, or better some place else (SOLACE?). Again, I appreciate the effort of the authors, and hope that we can continue the discussions in Atlanta. I apologize that I only provided this high-level review, but the last weeks were very busy for me. If you need help authoring the documents once they are split up, I could help out. Is there a meeting already planned? Best regards Ulrich On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) < mehmet.ersue@nsn.com> wrote: > Hi All, > > we submitted an update for the constrained-mgmt draft on the "Management > of Networks with Constrained Devices: Use Cases and Requirements". The > draft hopefully addresses most of the issues we discussed in the last > meeting. > > I think it is already time to split the draft into three; e.g. problem > statement, use cases and requirements. But this can be done after > getting your feedback before and during IETF 85. > > I would highly appreciate your comments and any kind of discussion on > the draft content especially on the requirements section. Thank you. > > Cheers, > Mehmet > > > -----Original Message----- > From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 15, 2012 9:59 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-02.txt > > > A new version of I-D, draft-ersue-constrained-mgmt-02.txt > has been successfully submitted by Mehmet Ersue and posted to the > IETF repository. > > Filename: draft-ersue-constrained-mgmt > Revision: 02 > Title: Management of Networks with Constrained Devices: Use > Cases and Requirements > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 78 > URL: > http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt > Status: > http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt > Htmlized: > http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ersue-constrained-mgmt-02 > > Abstract: > This document raises the questions on and discusses the use cases and > requirements for the management of networks with constrained devices. > > > > > > The IETF Secretariat > > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > --bcaec50162b5e4ea0c04cc7219c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mehmet,

thank you for updating the draft. There is a = huge amount of great work in it, and I think this will provide a great basi= s for further discussions. Indeed, splitting up the document would be requi= red at some point.

Some high-level comments:
=A0 - Section 1.2 (= Terminology): The definition of MANET and Intermediate entity (in COAP) com= e a bit surprising, since there has been no discussion before. Also, it see= ms inconsistent to define MANET, but not all the other use cases, such as A= MI.

=A0 - Section 1.3 (Constrained Device Classes): I know = that this definition is taken from Lwig, but I doubt that it is of much use= . The absolute values will change. While now there are still many C0 device= s out, in five years, they will not exist (or rather, the number 10KB would= need to be replaced by a larger number). I think I would prefer a classifi= cation based on the capabilities (e.g. can support full IP stack, or not)

=A0 - Section 1.4 (constrained networks): I don't t= hink this is a very consistent classification of networks. First, CN0 seems= to be the least constrained network, whereas C0 devices are the most const= rained. I would suggest the remain the same ordering (0 the most constraine= d up to a positive number).
More importantly, there is a mixture with constrained devices in this = definition. Since we talk about the network only, we should only talk about= topology, lossy links, multi-hop, mobility etc. but not constrained device= s.=A0
I don't understand why MANETs are not supported. Several of the us= e cases, such as the military use case, community networks and AMI are mult= i-hop networks with dynamic topology and lossy links. That is what I call a= MANET. Even the definition of CN1 is, IMO, entirely a MANET; you even ment= ion Mesh networks, which are nothing else than MANETs (only difference is t= hat routers are usually non-mobile; nevertheless, the topology is still dyn= amic because of fluctuating links.). Is the intention to focus on non-mobil= e devices?
Constrained networks are more difficult to define, as there are severa= l aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I thin= k that we need more discussion (but maybe after a BOF has been initiated?)<= /div>

- Section 1.5: (Network Topology Options): I think ther= e is a mix between the topology (i.e., the graph that represents routers an= d communication links), traffic flows (which devices communicate with which= other devices), and application layer (proxies and NMS).

- Section 1.6: I like that.

- = Section 1.7: There is mixture of constrained networks (first bullet); I tho= ught that constrained devices only means that they have little CPU power an= d memory. Can't that device still use cable connectivity (i.e. unconstr= ained network)? Or is it necessarily linked?
I am unclear about the purpose of this whole section. What does it ser= ve for?

- Section 2: I think that the problem stat= ement is not quite clear yet. It is hard to identify what the problems are;= there are so many useful requirements in section 4, so maybe it could be b= etter matched to these requirements. It would be nice to read section 4, an= d then say "ah, requirement x indeed logically follows from the proble= m y that has been described in section 2".

- Section 3: I like the diverse use cases. That can be = very useful to identify different requirements and problems.

=
- Section 4: I very much appreciate the enormous effort for gath= ering the requirements. There will be detailed discussions about them (hope= fully), but this is a very good list to start from.=A0
We have to define if the security related requirements also fit in thi= s discussion, or better some place else (SOLACE?).=A0

<= div>Again, I appreciate the effort of the authors, and hope that we can con= tinue the discussions in Atlanta. I apologize that I only provided this hig= h-level review, but the last weeks were very busy for me. If you need help = authoring the documents once they are split up, I could help out.


Is there a meeting already planned?=A0

Best regards
Ulrich=A0


=
On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (= NSN - DE/Munich) <mehmet.ersue@nsn.com> wrote:
Hi All,

we submitted an update for the constrained-mgmt draft on the "Manageme= nt
of Networks with Constrained Devices: Use Cases and Requirements". The=
draft hopefully addresses most of the issues we discussed in the last
meeting.

I think it is already time to split the draft into three; e.g. problem
statement, use cases and requirements. But this can be done after
getting your feedback before and during IETF 85.

I would highly appreciate your comments and any kind of discussion on
the draft content especially on the requirements section. Thank you.

Cheers,
Mehmet


-----Original Message-----
From: ext internet-drafts@ietf.= org [mailto:internet-drafts= @ietf.org]
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: dromasca@avaya.com; j.schoenwaelder@jacobs-uni= versity.de
Subject: New Version Notification for
draft-ersue-constrained-mgmt-02.txt


A new version of I-D, draft-ersue-constrained-mgmt-02.txt
has been successfully submitted by Mehmet Ersue and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ersue-constrained-mgmt
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Management of Networks with Constrained Devices:= Use
Cases and Requirements
Creation date: =A0 2012-10-15
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 78
URL:
http://www.ietf.org/internet-drafts/draft-ersue-= constrained-mgmt-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ersue-constrained-mgm= t
Htmlized:
http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constr= ained-mgmt-02

Abstract:
=A0 =A0This document raises the questions on and discusses the use cases an= d
=A0 =A0requirements for the management of networks with constrained devices= .





The IETF Secretariat


_______________________________________________
coman mailing list
coman@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/coman

--bcaec50162b5e4ea0c04cc7219c8-- From cabo@tzi.org Fri Oct 19 21:33:34 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 4F48321F8A02; Fri, 19 Oct 2012 21:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.446 X-Spam-Level: X-Spam-Status: No, score=-104.446 tagged_above=-999 required=5 tests=[AWL=-1.847, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxxhgFyKJGQE; Fri, 19 Oct 2012 21:33:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 837A721F8993; Fri, 19 Oct 2012 21:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9K4XLcO011445; Sat, 20 Oct 2012 06:33:23 +0200 (CEST) Message-Id: <3921D6F6-57AA-43BA-8B71-D8C7465B7F26@tzi.org> From: Carsten Bormann To: Ulrich Herberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 20 Oct 2012 06:33:20 +0200 References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> X-Mailer: Apple Mail (2.936) Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , coman@ietf.org, Carsten Bormann , opsawg@ietf.org Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt 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: Sat, 20 Oct 2012 04:33:34 -0000 On Oct 20 2012, at 01:45, Ulrich Herberg wrote: > - Section 1.3 (Constrained Device Classes): I know that this > definition is taken from Lwig, but I doubt that it is of much use. Well, I can only say that it has been extremely useful in the discussions abou protocol capabilities so far. It may have been the single most useful piece of output of the Prague workshop. This is a discussion we should have in LWIG, but I'm curious: > The absolute values will change. Why? Because we make the protocols more complex all the time so a device that is class 1 today will be class 0 in five years? This madness has to stop. > While now there are still many C0 devices out, in five years, they > will not exist (or rather, the number 10KB would need to be replaced > by a larger number). That is not the feedback I'm getting from industry types. Yes, one would hope that class 0 devices are eventually going away, so we can have full Internet capabilities on all smart object style devices. But that doesn't mean hat the class as an abstract concept is no longer useful (if only to say, "fortunately, there are no class 0 devices any more"). (And they are not going away that fast, at all.) > I think I would prefer a classification based on the capabilities > (e.g. can support full IP stack, or not) The classes have been defined the way they are because they mirror a step function in capabilities. (They also haven been defined on approximate orders of magnitude because you can't nail these steps down to a kilobyte.) What do you think is missing? Gruesse, Carsten From ulrich@herberg.name Fri Oct 19 22:04:34 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 4983F21F84DF for ; Fri, 19 Oct 2012 22:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usxh4nR2FU5l for ; Fri, 19 Oct 2012 22:04:33 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id C452C21F84F8 for ; Fri, 19 Oct 2012 22:04:33 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so831837pad.31 for ; Fri, 19 Oct 2012 22:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=sydiE4/fEzGyTFGmaNpK1/DY4cGxNn9Gx16ZCn57eEA=; b=oKuDEX2njGTZ30Rx69lWzNEMGrlVp8osg8g4nYFiT94tryl1VcmgYFEp+bzsqB83cW WQoOaYVgLRiq7W0AhKCwP88TK/9X4ODbsuyvKHv4t0Cq1Bsu0zd5Ak3Vx1X7t9MjKlD9 mLMen6BjRRfV/xxwsFbYjf8uefVo2nzZZ2Yak= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=sydiE4/fEzGyTFGmaNpK1/DY4cGxNn9Gx16ZCn57eEA=; b=PipN6Do1rZyW/k5fRIX2jXJ4V3ixKS/UX3pD39NOwCDbACT4eDTtJzcMZ0oTiUdlkc 1Wb9ZCTBdqRPuN1XF3UQeg40fBWl9+EbH2IEVBHLIG+QEXW3aHKoodWbB74QtpxaVIqD R/LL2d9MBfMfOzd/REL5kFPP1aXVZRmCxMbY+2qnmUZrrZhkmAJeIplvVTGykTK07knN udJESZVbfrr0Xb8eJh7MCRamO5k0IZ1Hip+YHRjGF6G6nn3/0PdwSZ4uZBz7DNVwDhBm fphdmvB0B7Hp7aGrBayltLLFsft/ofqZ/tgSWToHViWomaewuSN5GTIWhyS68Q8xaFvm 4cig== Received: by 10.68.229.138 with SMTP id sq10mr12577889pbc.126.1350709472666; Fri, 19 Oct 2012 22:04:32 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id kn8sm2297564pbc.24.2012.10.19.22.04.30 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 22:04:31 -0700 (PDT) References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> <3921D6F6-57AA-43BA-8B71-D8C7465B7F26@tzi.org> Mime-Version: 1.0 (1.0) In-Reply-To: <3921D6F6-57AA-43BA-8B71-D8C7465B7F26@tzi.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Fri, 19 Oct 2012 22:04:31 -0700 To: Carsten Bormann X-Gm-Message-State: ALoCoQnxEB0L3V+429Ca7NZE6s/Ph37pFD0DORCpr/vCOvy1BLYba/ezmYIaEWbB7qsl2VtdXA4D Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , "coman@ietf.org" , "opsawg@ietf.org" Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt 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: Sat, 20 Oct 2012 05:04:34 -0000 Hi Carsten, On Oct 19, 2012, at 21:33, Carsten Bormann wrote: > On Oct 20 2012, at 01:45, Ulrich Herberg wrote: >=20 >> - Section 1.3 (Constrained Device Classes): I know that this definition i= s taken from Lwig, but I doubt that it is of much use. >=20 > Well, I can only say that it has been extremely useful in the discussions a= bou protocol capabilities so far. Let me reformulate what I meant: I don't mean it's not useful. I am just won= dering if using absolute values for memory is the right way to distinguish t= he different classes. > It may have been the single most useful piece of output of the Prague work= shop. >=20 > This is a discussion we should have in LWIG, but I'm curious: Right, it was not the main point of my review, and it's fine for me to have t= he argument in lwig, not here. >=20 >> The absolute values will change. >=20 > Why? Because memory will get much cheaper (Moore's law). > Because we make the protocols more complex all the time so a device that i= s class 1 today will be class 0 in five years? > This madness has to stop. Which madness? >=20 >> While now there are still many C0 devices out, in five years, they will n= ot exist (or rather, the number 10KB would need to be replaced by a larger n= umber). >=20 > That is not the feedback I'm getting from industry types. Which feedback do you get then? >=20 > Yes, one would hope that class 0 devices are eventually going away, so we c= an have full Internet capabilities on all smart object style devices. Right. > But that doesn't mean hat the class as an abstract concept is no longer us= eful (if only to say, "fortunately, there are no class 0 devices any more").= I don't object. Let me clarify what I meant: a device classification is very= useful, but I was only wondering if absolute values for memory is the right= approach. An RFC defining these classes will be around for a long time, but= memory will get so much cheaper in the meantime. What was a lot of memory 1= 0 years ago, is not much today. > (And they are not going away that fast, at all.) I am unsure about that.=20 >=20 >> I think I would prefer a classification based on the capabilities (e.g. c= an support full IP stack, or not) >=20 > The classes have been defined the way they are because they mirror a step f= unction in capabilities. > (They also haven been defined on approximate orders of magnitude because y= ou can't nail these steps down to a kilobyte.) >=20 > What do you think is missing? Don't get me wrong.. If the Lwig wg group believes that this is the right wa= y to classify devices, I won't object this. Best Ulrich >=20 > Gruesse, Carsten >=20 From j.schoenwaelder@jacobs-university.de Fri Oct 19 23:46:03 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 9FC5C21F8610; Fri, 19 Oct 2012 23:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2SPYWKjX4Bl; Fri, 19 Oct 2012 23:46: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 ECE8C21F860F; Fri, 19 Oct 2012 23:46:02 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D016820C00; Sat, 20 Oct 2012 08:46:00 +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 BnmkQGc6bL01; Sat, 20 Oct 2012 08:46:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02F9220BFE; Sat, 20 Oct 2012 08:45:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 137092258B4F; Sat, 20 Oct 2012 08:45:59 +0200 (CEST) Date: Sat, 20 Oct 2012 08:45:59 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20121020064558.GA93702@elstar.local> Mail-Followup-To: Carsten Bormann , "Ersue, Mehmet (NSN - DE/Munich)" , coman@ietf.org, opsawg@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> <3921D6F6-57AA-43BA-8B71-D8C7465B7F26@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3921D6F6-57AA-43BA-8B71-D8C7465B7F26@tzi.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , coman@ietf.org, opsawg@ietf.org Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt 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: Sat, 20 Oct 2012 06:46:03 -0000 On Sat, Oct 20, 2012 at 06:33:20AM +0200, Carsten Bormann wrote: > > The classes have been defined the way they are because they mirror a > step function in capabilities. > (They also haven been defined on approximate orders of magnitude > because you can't nail these steps down to a kilobyte.) > > What do you think is missing? > Hijacking the thread, I do actually think we should have some more classes. For coman, in the use cases also devices included that have the memory to run embedded linux. I think we would do well to cover devices such xports or even raspberrys. Yes, those boxes probably are not the target of lwig but they will exist in the internet of things and some of them will exhibit properties (like mostly sleeping) that coman I think needs to address. /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 Oct 22 03:55: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 B51CA21F8A10; Mon, 22 Oct 2012 03:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4hMIcevHCic; Mon, 22 Oct 2012 03:55:34 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 79EE121F8A2F; Mon, 22 Oct 2012 03:55:33 -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 q9MAtRhs021835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Oct 2012 12:55:27 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9MAtP9K032180; Mon, 22 Oct 2012 12:55:25 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 12:55:25 +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_01CDB043.BD20BFE6" Date: Mon, 22 Oct 2012 12:55:23 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt Thread-Index: Ac2uU9pfo1K6uzZVTMS7jQJxzNvPGAB3OHBg References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ulrich Herberg" , "Carsten Bormann" X-OriginalArrivalTime: 22 Oct 2012 10:55:25.0195 (UTC) FILETIME=[BD7C4DB0:01CDB043] 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: 31107 X-purgate-ID: 151667::1350903327-00006DFC-B9AE0A9A/0-0/0-0 Cc: coman@ietf.org, opsawg@ietf.org Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt 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, 22 Oct 2012 10:55:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDB043.BD20BFE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ulrich, =20 see my comments below. =20 Cheers,=20 Mehmet=20 =20 From: ext Ulrich Herberg [mailto:ulrich@herberg.name]=20 Sent: Saturday, October 20, 2012 1:46 AM To: Ersue, Mehmet (NSN - DE/Munich) Cc: coman@ietf.org; opsawg@ietf.org Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt =20 Hi Mehmet, =20 thank you for updating the draft. There is a huge amount of great work in it, and I think this will provide a great basis for further discussions. Indeed, splitting up the document would be required at some point. =20 Some high-level comments: - Section 1.2 (Terminology): The definition of MANET and Intermediate entity (in COAP) come a bit surprising, since there has been no discussion before. Also, it seems inconsistent to define MANET, but not all the other use cases, such as AMI. =20 [ME]: The terminology section is incomplete and should be extended e.g. with AMI. =20 - Section 1.3 (Constrained Device Classes): I know that this definition is taken from Lwig, but I doubt that it is of much use. The absolute values will change. While now there are still many C0 devices out, in five years, they will not exist (or rather, the number 10KB would need to be replaced by a larger number). I think I would prefer a classification based on the capabilities (e.g. can support full IP stack, or not) =20 [ME]: The definition was actually first introduced by Carsten in the Smart Object workshop before IETF 80 in Prague. This is an important point. See my other mail. =20 - Section 1.4 (constrained networks): I don't think this is a very consistent classification of networks. First, CN0 seems to be the least constrained network, whereas C0 devices are the most constrained. I would suggest the remain the same ordering (0 the most constrained up to a positive number). =20 [ME]: The "0" in CN0 and C0 don't relate to each other. The constrainedness of a network is mostly dependent on the wireless technology used. I found it more useful to differentiate the type of the network, where the wireless technology can be manifold. =20 More importantly, there is a mixture with constrained devices in this definition. Since we talk about the network only, we should only talk about topology, lossy links, multi-hop, mobility etc. but not constrained devices.=20 =20 [ME]: I agree, we should talk here on devices only. =20 I don't understand why MANETs are not supported. Several of the use cases, such as the military use case, community networks and AMI are multi-hop networks with dynamic topology and lossy links. That is what I call a MANET.=20 =20 [ME]: The agreement in our last f2f meeting was that we want to include the MANET use case to highlight what it is but exclude from the requirements discussion. The reason is that MANETs can be based on very distinct scenarios and have specifics which are unique compared to other networks. The essential point is that MANETs are infrastructureless (i.e. without any hierarchy), which seems to be not the case in other network types the draft describes and makes network management essentially different. =20 Even the definition of CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are nothing else than MANETs (only difference is that routers are usually non-mobile; nevertheless, the topology is still dynamic because of fluctuating links.).=20 =20 [ME]: There might be similarities between a MANET and a Mesh network, however they are not the same thing. I have to admit we don't conceive sufficiently the special MANET use cases for frequent movement of routing devices without infrastructure. If we agree that a Mesh network covers the essential part of a MANET then I would suggest to focus on a Mesh network instead of trying to cover everything. =20 Is the intention to focus on non-mobile devices? =20 [ME]: There is no intention to exclude non-mobile devices. The draft currently assumes that, from the "network management" pov., both mobile and non-mobile devices have similar characteristics (I think we should describe this somewhere). The draft further assumes that the managing entity is not moving. =20 I might be wrong in this. Please describe which mobility aspects you think should be covered from "network management" pov. Managing the IP mobility itself, e.g. the IP address etc., is not network management per se. =20 Constrained networks are more difficult to define, as there are several aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I think that we need more discussion (but maybe after a BOF has been initiated?) =20 [ME]: We can start such a discussion already today. However, I assume it is mostly following the capabilities and limitations of the wireless technology. What would be your proposal for a classification of constrained networks? =20 - Section 1.5: (Network Topology Options): I think there is a mix between the topology (i.e., the graph that represents routers and communication links), traffic flows (which devices communicate with which other devices), and application layer (proxies and NMS). - Section 1.6: I like that. =20 - Section 1.7: There is mixture of constrained networks (first bullet); I thought that constrained devices only means that they have little CPU power and memory. Can't that device still use cable connectivity (i.e. unconstrained network)? Or is it necessarily linked? I am unclear about the purpose of this whole section. What does it serve for? =20 [ME]: Section 1.7 in general tries to list and discuss the issues a constrained device might have and how these issues influence the management of such a device. As described in section 1.4 and 2. we include non-constrained networks with constrained devices. =20 - Section 2: I think that the problem statement is not quite clear yet. It is hard to identify what the problems are; there are so many useful requirements in section 4, so maybe it could be better matched to these requirements. It would be nice to read section 4, and then say "ah, requirement x indeed logically follows from the problem y that has been described in section 2". =20 [ME]: I agree the problem statement in section 2 (which I didn't have time to update yet) could benefit from a revision aligning it with the new sections 1.7 and section 4. =20 - Section 3: I like the diverse use cases. That can be very useful to identify different requirements and problems. =20 - Section 4: I very much appreciate the enormous effort for gathering the requirements. There will be detailed discussions about them (hopefully), but this is a very good list to start from.=20 We have to define if the security related requirements also fit in this discussion, or better some place else (SOLACE?).=20 =20 [ME]: We see authentication and access control (to the extend it matters) as part of network management. This is probably the part where Coman and Solace can profit from and complement each other. =20 Again, I appreciate the effort of the authors, and hope that we can continue the discussions in Atlanta. I apologize that I only provided this high-level review, but the last weeks were very busy for me. If you need help authoring the documents once they are split up, I could help out. =20 Is there a meeting already planned?=20 =20 [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it once the room is known. Stay tuned. =20 Best regards Ulrich=20 =20 On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: Hi All, we submitted an update for the constrained-mgmt draft on the "Management of Networks with Constrained Devices: Use Cases and Requirements". The draft hopefully addresses most of the issues we discussed in the last meeting. I think it is already time to split the draft into three; e.g. problem statement, use cases and requirements. But this can be done after getting your feedback before and during IETF 85. I would highly appreciate your comments and any kind of discussion on the draft content especially on the requirements section. Thank you. Cheers, Mehmet -----Original Message----- From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, October 15, 2012 9:59 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-02.txt A new version of I-D, draft-ersue-constrained-mgmt-02.txt has been successfully submitted by Mehmet Ersue and posted to the IETF repository. Filename: draft-ersue-constrained-mgmt Revision: 02 Title: Management of Networks with Constrained Devices: Use Cases and Requirements Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 78 URL: http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt Status: http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt Htmlized: http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrained-mgmt-02 Abstract: This document raises the questions on and discusses the use cases and requirements for the management of networks with constrained devices. The IETF Secretariat _______________________________________________ coman mailing list coman@ietf.org https://www.ietf.org/mailman/listinfo/coman =20 ------_=_NextPart_001_01CDB043.BD20BFE6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Ulrich,

=  

= see my comments below.

=  

= Cheers,=
= Mehmet=

=  

From:= = ext Ulrich Herberg [mailto:ulrich@herberg.name] =
Sent: Saturday, October 20, 2012 1:46 AM
To: Ersue, = Mehmet (NSN - DE/Munich)
Cc: coman@ietf.org; opsawg@ietf.org
Subject: = Re: [coman] FW: New Version Notification for = draft-ersue-constrained-mgmt-02.txt

 

Hi = Mehmet,

 

thank you for updating the draft. There is a huge = amount of great work in it, and I think this will provide a great basis = for further discussions. Indeed, splitting up the document would be = required at some point.

 

Some high-level comments:

  - Section 1.2 (Terminology): The definition of = MANET and Intermediate entity (in COAP) come a bit surprising, since = there has been no discussion before. Also, it seems inconsistent to = define MANET, but not all the other use cases, such as = AMI.

 

= [ME]: The terminology section is incomplete and should be extended e.g. = with AMI.

=  

  - = Section 1.3 (Constrained Device Classes): I know that this definition is = taken from Lwig, but I doubt that it is of much use. The absolute values = will change. While now there are still many C0 devices out, in five = years, they will not exist (or rather, the number 10KB would need to be = replaced by a larger number). I think I would prefer a classification = based on the capabilities (e.g. can support full IP stack, or = not)

 

= [ME]: The definition was actually first introduced by Carsten in the = Smart Object workshop before IETF 80 in Prague. This is an important = point. See my other mail.

=  

  - = Section 1.4 (constrained networks): I don't think this is a very = consistent classification of networks. First, CN0 seems to be the least = constrained network, whereas C0 devices are the most constrained. I = would suggest the remain the same ordering (0 the most constrained up to = a positive number).

=  

= [ME]: The “0” in CN0 and C0 don’t relate to each = other. The constrainedness of a network is mostly dependent on the = wireless technology used. I found it more useful to differentiate the = type of the network, where the wireless technology can be = manifold.

=  

More = importantly, there is a mixture with constrained devices in this = definition. Since we talk about the network only, we should only talk = about topology, lossy links, multi-hop, mobility etc. but not = constrained devices. 

=  

= [ME]: I agree, we should talk here on devices = only.

=  

I don't = understand why MANETs are not supported. Several of the use cases, such = as the military use case, community networks and AMI are multi-hop = networks with dynamic topology and lossy links. That is what I call a = MANET.

=  

= [ME]: The agreement in our last f2f meeting was that we want to include = the MANET use case to highlight what it is but exclude from the = requirements discussion. The reason is that MANETs can be based on very = distinct scenarios and have specifics which are unique compared to other = networks. The essential point is that MANETs are infrastructureless = (i.e. without any hierarchy), which seems to be not the case in other = network types the draft describes and makes network management = essentially different.

=  

Even the definition of = CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are = nothing else than MANETs (only difference is that routers are usually = non-mobile; nevertheless, the topology is still dynamic because of = fluctuating links.).

=  

= [ME]: There might be similarities between a MANET and a Mesh network, = however they are not the same thing. I have to admit we don’t = conceive sufficiently the special MANET use cases for frequent movement = of routing devices without infrastructure. If we agree that a Mesh = network covers the essential part of a MANET then I would suggest to = focus on a Mesh network instead of trying to cover = everything.

=  

Is the intention to = focus on non-mobile devices?

=  

= [ME]: There is no intention to exclude non-mobile devices. The draft = currently assumes that, from the “network management” pov., = both mobile and non-mobile devices have similar characteristics (I think = we should describe this somewhere). The draft further assumes that the = managing entity is not moving.

=  

= I might be wrong in this. Please describe which mobility aspects you = think should be covered from “network management” pov. = Managing the IP mobility itself, e.g. the IP address etc., is not = network management per se.

=  

Constrained = networks are more difficult to define, as there are several aspects: = bandwidth, loss rates of the channel, MTU, topology, etc. I think that = we need more discussion (but maybe after a BOF has been = initiated?)

=  

= [ME]: We can start such a discussion already today. However, I assume it = is mostly following the capabilities and limitations of the wireless = technology. What would be your proposal for a classification of = constrained networks?

 

- = Section 1.5: (Network Topology Options): I think there is a mix between = the topology (i.e., the graph that represents routers and communication = links), traffic flows (which devices communicate with which other = devices), and application layer (proxies and = NMS).

- Section 1.6: I = like that.

 

- = Section 1.7: There is mixture of constrained networks (first bullet); I = thought that constrained devices only means that they have little CPU = power and memory. Can't that device still use cable connectivity (i.e. = unconstrained network)? Or is it necessarily = linked?

I am unclear about = the purpose of this whole section. What does it serve = for?

 

= [ME]: Section 1.7 in general tries to list and discuss the issues a = constrained device might have and how these issues influence the = management of such a device. As described in section 1.4 and 2. we = include non-constrained networks with constrained = devices.

=  

- Section 2: = I think that the problem statement is not quite clear yet. It is hard to = identify what the problems are; there are so many useful requirements in = section 4, so maybe it could be better matched to these requirements. It = would be nice to read section 4, and then say "ah, requirement x = indeed logically follows from the problem y that has been described in = section 2".

=  

= [ME]: I agree the problem statement in section 2 (which I didn’t = have time to update yet) could benefit from a revision aligning it with = the new sections 1.7 and section 4.

 

- = Section 3: I like the diverse use cases. That can be very useful to = identify different requirements and = problems.

 

- = Section 4: I very much appreciate the enormous effort for gathering the = requirements. There will be detailed discussions about them (hopefully), = but this is a very good list to start = from. 

We have to = define if the security related requirements also fit in this discussion, = or better some place else (SOLACE?). 

=  

= [ME]: We see authentication and access control (to the extend it = matters) as part of network management. This is probably the part where = Coman and Solace can profit from and complement each = other.

 

Again, I appreciate the effort of the authors, and = hope that we can continue the discussions in Atlanta. I apologize that I = only provided this high-level review, but the last weeks were very busy = for me. If you need help authoring the documents once they are split up, = I could help out.

 

Is there a meeting already = planned? 

 

= [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it = once the room is known. Stay tuned.

=  

Best = regards

Ulrich 

 

On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - = DE/Munich) <mehmet.ersue@nsn.com> wrote:

Hi All,

we submitted an update for the = constrained-mgmt draft on the "Management
of Networks with = Constrained Devices: Use Cases and Requirements". The
draft = hopefully addresses most of the issues we discussed in the = last
meeting.

I think it is already time to split the draft = into three; e.g. problem
statement, use cases and requirements. But = this can be done after
getting your feedback before and during IETF = 85.

I would highly appreciate your comments and any kind of = discussion on
the draft content especially on the requirements = section. Thank you.

Cheers,
Mehmet


-----Original = Message-----
From: ext internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - = DE/Munich)
Cc: dromasca@avaya.com; j.schoenwaelder@jaco= bs-university.de
Subject: New Version Notification = for
draft-ersue-constrained-mgmt-02.txt


A new version of = I-D, draft-ersue-constrained-mgmt-02.txt
has been successfully = submitted by Mehmet Ersue and posted to the
IETF = repository.

Filename:       =  draft-ersue-constrained-mgmt
Revision:       =  02
Title:           Management of = Networks with Constrained Devices: Use
Cases and = Requirements
Creation date:   2012-10-15
WG ID:     =       Individual Submission
Number of pages: = 78
URL:
http://www.ietf.org/internet-drafts/draft-ersue-constra= ined-mgmt-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ersue-constrained= -mgmt
Htmlized:
http://tools.ietf.org/html/draft-ersue-constrained-mgmt= -02
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrai= ned-mgmt-02

Abstract:
   This document raises = the questions on and discusses the use cases and
  =  requirements for the management of networks with constrained = devices.





The IETF = Secretariat


_______________________________________________coman mailing list
coman@ietf.org
https://www.ietf.org/mailman/listinfo/coman

 

------_=_NextPart_001_01CDB043.BD20BFE6-- From mehmet.ersue@nsn.com Mon Oct 22 03:57:55 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 7368421F8A10 for ; Mon, 22 Oct 2012 03:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3OFifdir4Kl for ; Mon, 22 Oct 2012 03:57:54 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5A43421F8612 for ; Mon, 22 Oct 2012 03:57:54 -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 q9MAvpsP002769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Oct 2012 12:57:51 +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 q9MAvkKV019025; Mon, 22 Oct 2012 12:57:51 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 12:57:33 +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, 22 Oct 2012 12:57:32 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64045094C2@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Classification of constrained devices WAS: RE: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt Thread-Index: Ac2ugGduV5E+AM6vRu6ceop9+v8iZQBsSMRg References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> <3921D6F6-57AA-43BA-8B71-D8C7465B7F26@tzi.org> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ulrich Herberg" , "Carsten Bormann" X-OriginalArrivalTime: 22 Oct 2012 10:57:33.0496 (UTC) FILETIME=[09F57B80:01CDB044] 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: 4255 X-purgate-ID: 151667::1350903472-000048BF-A7E2EB96/0-0/0-0 Cc: coman@ietf.org Subject: [coman] Classification of constrained devices WAS: RE: FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt 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, 22 Oct 2012 10:57:55 -0000 Dear Ulrich, I have no idea when the absolute values will change. A more detailed classification might be interesting in the long run.=20 However, Carsten's classification is a good working assumption for now. One point we need to consider is that different people are looking at the capabilites of constrained devices from different angles. If we have x features which are possible to execute on a constrained device this does not mean a constrained device can execute them all at once. We should look on those features as stand-alone features to be executed. E.g. if a C1 device can in general execute the features f1, f2, .., fx. The device vendor or the user might be forced to choose e.g. 3 of them as the device cannot all x features.=20 This actually makes it impossible to judge which features a constrained device can support as a sum. PS: I assume it would be better to reduce the bandwidth on opsawg maillist. So I send this to Coman only. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Ulrich Herberg [mailto:ulrich@herberg.name] > Sent: Saturday, October 20, 2012 7:05 AM > To: Carsten Bormann > Cc: Ersue, Mehmet (NSN - DE/Munich); coman@ietf.org; opsawg@ietf.org > Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt- > 02.txt >=20 > Hi Carsten, >=20 > On Oct 19, 2012, at 21:33, Carsten Bormann wrote: >=20 > > On Oct 20 2012, at 01:45, Ulrich Herberg wrote: > > > >> - Section 1.3 (Constrained Device Classes): I know that this definition is taken > from Lwig, but I doubt that it is of much use. > > > > Well, I can only say that it has been extremely useful in the discussions abou > protocol capabilities so far. >=20 > Let me reformulate what I meant: I don't mean it's not useful. I am just wondering if > using absolute values for memory is the right way to distinguish the different classes. >=20 > > It may have been the single most useful piece of output of the Prague workshop. > > > > This is a discussion we should have in LWIG, but I'm curious: >=20 > Right, it was not the main point of my review, and it's fine for me to have the > argument in lwig, not here. >=20 > > > >> The absolute values will change. > > > > Why? >=20 > Because memory will get much cheaper (Moore's law). >=20 >=20 > > Because we make the protocols more complex all the time so a device that is class 1 > today will be class 0 in five years? > > This madness has to stop. >=20 > Which madness? >=20 > > > >> While now there are still many C0 devices out, in five years, they will not exist (or > rather, the number 10KB would need to be replaced by a larger number). > > > > That is not the feedback I'm getting from industry types. >=20 > Which feedback do you get then? >=20 > > > > Yes, one would hope that class 0 devices are eventually going away, so we can have > full Internet capabilities on all smart object style devices. >=20 > Right. >=20 >=20 > > But that doesn't mean hat the class as an abstract concept is no longer useful (if > only to say, "fortunately, there are no class 0 devices any more"). >=20 > I don't object. Let me clarify what I meant: a device classification is very useful, but I > was only wondering if absolute values for memory is the right approach. An RFC > defining these classes will be around for a long time, but memory will get so much > cheaper in the meantime. What was a lot of memory 10 years ago, is not much today. >=20 >=20 > > (And they are not going away that fast, at all.) >=20 > I am unsure about that. >=20 > > > >> I think I would prefer a classification based on the capabilities (e.g. can support full > IP stack, or not) > > > > The classes have been defined the way they are because they mirror a step function > in capabilities. > > (They also haven been defined on approximate orders of magnitude because you > can't nail these steps down to a kilobyte.) > > > > What do you think is missing? >=20 > Don't get me wrong.. If the Lwig wg group believes that this is the right way to classify > devices, I won't object this. >=20 > Best > Ulrich >=20 >=20 > > > > Gruesse, Carsten > > From mehmet.ersue@nsn.com Mon Oct 22 03:58:14 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 313B721F8A10 for ; Mon, 22 Oct 2012 03:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXTrx+god8+m for ; Mon, 22 Oct 2012 03:58:13 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD8221F8612 for ; Mon, 22 Oct 2012 03:58:13 -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 q9MAw5jZ027744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Oct 2012 12:58:05 +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 q9MAvvxJ020047; Mon, 22 Oct 2012 12:58:05 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 12:58:04 +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, 22 Oct 2012 12:58:02 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64045094C3@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00 Thread-Index: Ac2wRBtNd8ibqR4zTzOUs3EDhJltsQ== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 22 Oct 2012 10:58:04.0201 (UTC) FILETIME=[1C42B190:01CDB044] 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: 488 X-purgate-ID: 151667::1350903486-00006DFC-EDF46B18/0-0/0-0 Cc: ext Benoit Claise Subject: [coman] Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00 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, 22 Oct 2012 10:58:14 -0000 Hi All, we planned a Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00.=20 Topics will -02 draft in general, constrained device classes, class of networks in focus, management of constrainedness and the requirements section, etc. PS: This is just an adhoc discussion. There will be no jabber, no recording. I will provide some minutes. PS2: The room request has been approved but the IETF secretary did not assign a room yet. Cheers,=20 Mehmet=20 From mehmet.ersue@nsn.com Mon Oct 22 07:19:23 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 44A8F21F84F3; Mon, 22 Oct 2012 07:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn1n-qZZp05Q; Mon, 22 Oct 2012 07:19:17 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8FE21F842A; Mon, 22 Oct 2012 07:19:16 -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 q9MEJEvb020412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Oct 2012 16:19:14 +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 q9MEJDOw020311; Mon, 22 Oct 2012 16:19:14 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 16:19:13 +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_01CDB060.36187F76" Date: Mon, 22 Oct 2012 16:19:13 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640455DA5B@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] [coman] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt Thread-Index: Ac2uU9pfo1K6uzZVTMS7jQJxzNvPGAB3OHBgAAvVLcA= References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ulrich Herberg" , "Carsten Bormann" X-OriginalArrivalTime: 22 Oct 2012 14:19:13.0937 (UTC) FILETIME=[36624010:01CDB060] 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: 34188 X-purgate-ID: 151667::1350915554-00006DFC-88711FE1/0-0/0-0 Cc: coman@ietf.org, opsawg@ietf.org Subject: Re: [coman] [OPSAWG] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt 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, 22 Oct 2012 14:19:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDB060.36187F76 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > [ME]: There is no intention to exclude non-mobile devices. =20 s/non-mobile/mobile/ =20 Cheers,=20 Mehmet=20 =20 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) Sent: Monday, October 22, 2012 12:55 PM To: ext Ulrich Herberg; Carsten Bormann Cc: coman@ietf.org; opsawg@ietf.org Subject: Re: [OPSAWG] [coman] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt =20 Hi Ulrich, =20 see my comments below. =20 Cheers,=20 Mehmet=20 =20 From: ext Ulrich Herberg [mailto:ulrich@herberg.name]=20 Sent: Saturday, October 20, 2012 1:46 AM To: Ersue, Mehmet (NSN - DE/Munich) Cc: coman@ietf.org; opsawg@ietf.org Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt =20 Hi Mehmet, =20 thank you for updating the draft. There is a huge amount of great work in it, and I think this will provide a great basis for further discussions. Indeed, splitting up the document would be required at some point. =20 Some high-level comments: - Section 1.2 (Terminology): The definition of MANET and Intermediate entity (in COAP) come a bit surprising, since there has been no discussion before. Also, it seems inconsistent to define MANET, but not all the other use cases, such as AMI. =20 [ME]: The terminology section is incomplete and should be extended e.g. with AMI. =20 - Section 1.3 (Constrained Device Classes): I know that this definition is taken from Lwig, but I doubt that it is of much use. The absolute values will change. While now there are still many C0 devices out, in five years, they will not exist (or rather, the number 10KB would need to be replaced by a larger number). I think I would prefer a classification based on the capabilities (e.g. can support full IP stack, or not) =20 [ME]: The definition was actually first introduced by Carsten in the Smart Object workshop before IETF 80 in Prague. This is an important point. See my other mail. =20 - Section 1.4 (constrained networks): I don't think this is a very consistent classification of networks. First, CN0 seems to be the least constrained network, whereas C0 devices are the most constrained. I would suggest the remain the same ordering (0 the most constrained up to a positive number). =20 [ME]: The "0" in CN0 and C0 don't relate to each other. The constrainedness of a network is mostly dependent on the wireless technology used. I found it more useful to differentiate the type of the network, where the wireless technology can be manifold. =20 More importantly, there is a mixture with constrained devices in this definition. Since we talk about the network only, we should only talk about topology, lossy links, multi-hop, mobility etc. but not constrained devices.=20 =20 [ME]: I agree, we should talk here on devices only. =20 I don't understand why MANETs are not supported. Several of the use cases, such as the military use case, community networks and AMI are multi-hop networks with dynamic topology and lossy links. That is what I call a MANET.=20 =20 [ME]: The agreement in our last f2f meeting was that we want to include the MANET use case to highlight what it is but exclude from the requirements discussion. The reason is that MANETs can be based on very distinct scenarios and have specifics which are unique compared to other networks. The essential point is that MANETs are infrastructureless (i.e. without any hierarchy), which seems to be not the case in other network types the draft describes and makes network management essentially different. =20 Even the definition of CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are nothing else than MANETs (only difference is that routers are usually non-mobile; nevertheless, the topology is still dynamic because of fluctuating links.).=20 =20 [ME]: There might be similarities between a MANET and a Mesh network, however they are not the same thing. I have to admit we don't conceive sufficiently the special MANET use cases for frequent movement of routing devices without infrastructure. If we agree that a Mesh network covers the essential part of a MANET then I would suggest to focus on a Mesh network instead of trying to cover everything. =20 Is the intention to focus on non-mobile devices? =20 [ME]: There is no intention to exclude non-mobile devices. The draft currently assumes that, from the "network management" pov., both mobile and non-mobile devices have similar characteristics (I think we should describe this somewhere). The draft further assumes that the managing entity is not moving. =20 I might be wrong in this. Please describe which mobility aspects you think should be covered from "network management" pov. Managing the IP mobility itself, e.g. the IP address etc., is not network management per se. =20 Constrained networks are more difficult to define, as there are several aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I think that we need more discussion (but maybe after a BOF has been initiated?) =20 [ME]: We can start such a discussion already today. However, I assume it is mostly following the capabilities and limitations of the wireless technology. What would be your proposal for a classification of constrained networks? =20 - Section 1.5: (Network Topology Options): I think there is a mix between the topology (i.e., the graph that represents routers and communication links), traffic flows (which devices communicate with which other devices), and application layer (proxies and NMS). - Section 1.6: I like that. =20 - Section 1.7: There is mixture of constrained networks (first bullet); I thought that constrained devices only means that they have little CPU power and memory. Can't that device still use cable connectivity (i.e. unconstrained network)? Or is it necessarily linked? I am unclear about the purpose of this whole section. What does it serve for? =20 [ME]: Section 1.7 in general tries to list and discuss the issues a constrained device might have and how these issues influence the management of such a device. As described in section 1.4 and 2. we include non-constrained networks with constrained devices. =20 - Section 2: I think that the problem statement is not quite clear yet. It is hard to identify what the problems are; there are so many useful requirements in section 4, so maybe it could be better matched to these requirements. It would be nice to read section 4, and then say "ah, requirement x indeed logically follows from the problem y that has been described in section 2". =20 [ME]: I agree the problem statement in section 2 (which I didn't have time to update yet) could benefit from a revision aligning it with the new sections 1.7 and section 4. =20 - Section 3: I like the diverse use cases. That can be very useful to identify different requirements and problems. =20 - Section 4: I very much appreciate the enormous effort for gathering the requirements. There will be detailed discussions about them (hopefully), but this is a very good list to start from.=20 We have to define if the security related requirements also fit in this discussion, or better some place else (SOLACE?).=20 =20 [ME]: We see authentication and access control (to the extend it matters) as part of network management. This is probably the part where Coman and Solace can profit from and complement each other. =20 Again, I appreciate the effort of the authors, and hope that we can continue the discussions in Atlanta. I apologize that I only provided this high-level review, but the last weeks were very busy for me. If you need help authoring the documents once they are split up, I could help out. =20 Is there a meeting already planned?=20 =20 [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it once the room is known. Stay tuned. =20 Best regards Ulrich=20 =20 On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: Hi All, we submitted an update for the constrained-mgmt draft on the "Management of Networks with Constrained Devices: Use Cases and Requirements". The draft hopefully addresses most of the issues we discussed in the last meeting. I think it is already time to split the draft into three; e.g. problem statement, use cases and requirements. But this can be done after getting your feedback before and during IETF 85. I would highly appreciate your comments and any kind of discussion on the draft content especially on the requirements section. Thank you. Cheers, Mehmet -----Original Message----- From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, October 15, 2012 9:59 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-02.txt A new version of I-D, draft-ersue-constrained-mgmt-02.txt has been successfully submitted by Mehmet Ersue and posted to the IETF repository. Filename: draft-ersue-constrained-mgmt Revision: 02 Title: Management of Networks with Constrained Devices: Use Cases and Requirements Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 78 URL: http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt Status: http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt Htmlized: http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrained-mgmt-02 Abstract: This document raises the questions on and discusses the use cases and requirements for the management of networks with constrained devices. The IETF Secretariat _______________________________________________ coman mailing list coman@ietf.org https://www.ietf.org/mailman/listinfo/coman =20 ------_=_NextPart_001_01CDB060.36187F76 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= > [ME]: There is no intention to exclude non-mobile = devices.=

=  

= s/= non-mobile= /= mobile= /

=  

= Cheers,=
= Mehmet=

=  

From:= = opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of = Ersue, Mehmet (NSN - DE/Munich)
Sent: Monday, October 22, = 2012 12:55 PM
To: ext Ulrich Herberg; Carsten = Bormann
Cc: coman@ietf.org; opsawg@ietf.org
Subject: = Re: [OPSAWG] [coman] FW: New Version Notification = fordraft-ersue-constrained-mgmt-02.txt

<= p class=3DMsoNormal> 

= Hi Ulrich,

=  

= see my comments below.

=  

= Cheers,=
= Mehmet=

=  

From:= = ext Ulrich Herberg [mailto:ulrich@herberg.name] =
Sent: Saturday, October 20, 2012 1:46 AM
To: Ersue, = Mehmet (NSN - DE/Munich)
Cc: coman@ietf.org; opsawg@ietf.org
Subject: = Re: [coman] FW: New Version Notification for = draft-ersue-constrained-mgmt-02.txt

 

Hi = Mehmet,

 

thank you for updating the draft. There is a huge = amount of great work in it, and I think this will provide a great basis = for further discussions. Indeed, splitting up the document would be = required at some point.

 

Some high-level comments:

  - Section 1.2 (Terminology): The definition of = MANET and Intermediate entity (in COAP) come a bit surprising, since = there has been no discussion before. Also, it seems inconsistent to = define MANET, but not all the other use cases, such as = AMI.

 

= [ME]: The terminology section is incomplete and should be extended e.g. = with AMI.

=  

  - = Section 1.3 (Constrained Device Classes): I know that this definition is = taken from Lwig, but I doubt that it is of much use. The absolute values = will change. While now there are still many C0 devices out, in five = years, they will not exist (or rather, the number 10KB would need to be = replaced by a larger number). I think I would prefer a classification = based on the capabilities (e.g. can support full IP stack, or = not)

 

= [ME]: The definition was actually first introduced by Carsten in the = Smart Object workshop before IETF 80 in Prague. This is an important = point. See my other mail.

=  

  - = Section 1.4 (constrained networks): I don't think this is a very = consistent classification of networks. First, CN0 seems to be the least = constrained network, whereas C0 devices are the most constrained. I = would suggest the remain the same ordering (0 the most constrained up to = a positive number).

=  

= [ME]: The “0” in CN0 and C0 don’t relate to each = other. The constrainedness of a network is mostly dependent on the = wireless technology used. I found it more useful to differentiate the = type of the network, where the wireless technology can be = manifold.

=  

More = importantly, there is a mixture with constrained devices in this = definition. Since we talk about the network only, we should only talk = about topology, lossy links, multi-hop, mobility etc. but not = constrained devices. 

=  

= [ME]: I agree, we should talk here on devices = only.

=  

I don't = understand why MANETs are not supported. Several of the use cases, such = as the military use case, community networks and AMI are multi-hop = networks with dynamic topology and lossy links. That is what I call a = MANET.

=  

= [ME]: The agreement in our last f2f meeting was that we want to include = the MANET use case to highlight what it is but exclude from the = requirements discussion. The reason is that MANETs can be based on very = distinct scenarios and have specifics which are unique compared to other = networks. The essential point is that MANETs are infrastructureless = (i.e. without any hierarchy), which seems to be not the case in other = network types the draft describes and makes network management = essentially different.

=  

Even the definition of = CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are = nothing else than MANETs (only difference is that routers are usually = non-mobile; nevertheless, the topology is still dynamic because of = fluctuating links.).

=  

= [ME]: There might be similarities between a MANET and a Mesh network, = however they are not the same thing. I have to admit we don’t = conceive sufficiently the special MANET use cases for frequent movement = of routing devices without infrastructure. If we agree that a Mesh = network covers the essential part of a MANET then I would suggest to = focus on a Mesh network instead of trying to cover = everything.

=  

Is the intention to = focus on non-mobile devices?

=  

= [ME]: There is no intention to exclude non-mobile devices. The draft = currently assumes that, from the “network management” pov., = both mobile and non-mobile devices have similar characteristics (I think = we should describe this somewhere). The draft further assumes that the = managing entity is not moving.

=  

= I might be wrong in this. Please describe which mobility aspects you = think should be covered from “network management” pov. = Managing the IP mobility itself, e.g. the IP address etc., is not = network management per se.

=  

Constrained = networks are more difficult to define, as there are several aspects: = bandwidth, loss rates of the channel, MTU, topology, etc. I think that = we need more discussion (but maybe after a BOF has been = initiated?)

=  

= [ME]: We can start such a discussion already today. However, I assume it = is mostly following the capabilities and limitations of the wireless = technology. What would be your proposal for a classification of = constrained networks?

 

- = Section 1.5: (Network Topology Options): I think there is a mix between = the topology (i.e., the graph that represents routers and communication = links), traffic flows (which devices communicate with which other = devices), and application layer (proxies and = NMS).

- Section 1.6: I = like that.

 

- = Section 1.7: There is mixture of constrained networks (first bullet); I = thought that constrained devices only means that they have little CPU = power and memory. Can't that device still use cable connectivity (i.e. = unconstrained network)? Or is it necessarily = linked?

I am unclear about = the purpose of this whole section. What does it serve = for?

 

= [ME]: Section 1.7 in general tries to list and discuss the issues a = constrained device might have and how these issues influence the = management of such a device. As described in section 1.4 and 2. we = include non-constrained networks with constrained = devices.

=  

- Section 2: = I think that the problem statement is not quite clear yet. It is hard to = identify what the problems are; there are so many useful requirements in = section 4, so maybe it could be better matched to these requirements. It = would be nice to read section 4, and then say "ah, requirement x = indeed logically follows from the problem y that has been described in = section 2".

=  

= [ME]: I agree the problem statement in section 2 (which I didn’t = have time to update yet) could benefit from a revision aligning it with = the new sections 1.7 and section 4.

 

- = Section 3: I like the diverse use cases. That can be very useful to = identify different requirements and = problems.

 

- = Section 4: I very much appreciate the enormous effort for gathering the = requirements. There will be detailed discussions about them (hopefully), = but this is a very good list to start = from. 

We have to = define if the security related requirements also fit in this discussion, = or better some place else (SOLACE?). 

=  

= [ME]: We see authentication and access control (to the extend it = matters) as part of network management. This is probably the part where = Coman and Solace can profit from and complement each = other.

 

Again, I appreciate the effort of the authors, and = hope that we can continue the discussions in Atlanta. I apologize that I = only provided this high-level review, but the last weeks were very busy = for me. If you need help authoring the documents once they are split up, = I could help out.

 

Is there a meeting already = planned? 

 

= [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it = once the room is known. Stay tuned.

=  

Best = regards

Ulrich 

 

On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - = DE/Munich) <mehmet.ersue@nsn.com> wrote:

Hi All,

we submitted an update for the = constrained-mgmt draft on the "Management
of Networks with = Constrained Devices: Use Cases and Requirements". The
draft = hopefully addresses most of the issues we discussed in the = last
meeting.

I think it is already time to split the draft = into three; e.g. problem
statement, use cases and requirements. But = this can be done after
getting your feedback before and during IETF = 85.

I would highly appreciate your comments and any kind of = discussion on
the draft content especially on the requirements = section. Thank you.

Cheers,
Mehmet


-----Original = Message-----
From: ext internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - = DE/Munich)
Cc: dromasca@avaya.com; j.schoenwaelder@jaco= bs-university.de
Subject: New Version Notification = for
draft-ersue-constrained-mgmt-02.txt


A new version of = I-D, draft-ersue-constrained-mgmt-02.txt
has been successfully = submitted by Mehmet Ersue and posted to the
IETF = repository.

Filename:       =  draft-ersue-constrained-mgmt
Revision:       =  02
Title:           Management of = Networks with Constrained Devices: Use
Cases and = Requirements
Creation date:   2012-10-15
WG ID:     =       Individual Submission
Number of pages: = 78
URL:
http://www.ietf.org/internet-drafts/draft-ersue-constra= ined-mgmt-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ersue-constrained= -mgmt
Htmlized:
http://tools.ietf.org/html/draft-ersue-constrained-mgmt= -02
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrai= ned-mgmt-02

Abstract:
   This document raises = the questions on and discusses the use cases and
  =  requirements for the management of networks with constrained = devices.





The IETF = Secretariat


_______________________________________________coman mailing list
coman@ietf.org
https://www.ietf.org/mailman/listinfo/coman

 

------_=_NextPart_001_01CDB060.36187F76-- From ulrich@herberg.name Mon Oct 22 20:46: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 8031321F84C9 for ; Mon, 22 Oct 2012 20:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yggbd0XJeP89 for ; Mon, 22 Oct 2012 20:46:13 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D35321F85D5 for ; Mon, 22 Oct 2012 20:46:13 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2410485pad.31 for ; Mon, 22 Oct 2012 20:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=YJXYGMDJ+6bYIBWJJ88htxGuxh+/WRfNRwcb+UkCJQA=; b=gMz65TrFScfaB07LorxVe0ieAYYeBhygSKpYCrH4ieZSziw4hKBAvvDx0AztaCM6SA Fx6Za/Q+xCbTpgLGZGCMn0WlcwBMEwli23sKOm73wsb4d1NOjwEoOPIJZ3PlLWrhvVOh yhxTbkYv9PH61BQj6dG/wXLzazR4JNoo4J1Yc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=YJXYGMDJ+6bYIBWJJ88htxGuxh+/WRfNRwcb+UkCJQA=; b=mZaJa1UsZHJa3cWacnxGDO31UHVdd4SLWVCKLN9i8AMPaZ44hELhgMaXRZ5GVbAA3r CS5eHV+G6W+to9T7ue2u+OilrLEZzZ3UBSmCoYkTDOeVo9TB0H9m2W10GGPP5414TemW zhStzdTYxhKQDu/bW9VKTqVD93e7nvrax/Sxf7n4mCafFjCJ4jUaTgHyzKkrHM2Wj4/r DXpk5+uvV5GOchYPqN2jB5Aezr/6F2dymZylgX7gpO76Y8pTf3Xh7sFMAXUX71QFat2V QA3BZsUIh+jrbnQnwirZYbn5TuWGok9H3SN8G0v7FCmEPNm+yVZRvmz2U7dtMyeOB+kg QZgA== Received: by 10.68.130.71 with SMTP id oc7mr36519031pbb.116.1350963969666; Mon, 22 Oct 2012 20:46:09 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id vf8sm6970564pbc.27.2012.10.22.20.46.07 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 20:46:08 -0700 (PDT) References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A640455DA5B@DEMUEXC006.nsn-intra.net> Mime-Version: 1.0 (1.0) In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640455DA5B@DEMUEXC006.nsn-intra.net> Content-Type: multipart/alternative; boundary=Apple-Mail-EAEC3B4F-58B3-4440-AC92-BC0ADC73FB5F Content-Transfer-Encoding: 7bit Message-Id: <7044BCBB-99B9-4906-95FB-B1509FED1E56@herberg.name> X-Mailer: iPad Mail (10A403) From: Ulrich Herberg Date: Mon, 22 Oct 2012 20:46:08 -0700 To: "Ersue, Mehmet (NSN - DE/Munich)" X-Gm-Message-State: ALoCoQm0B8vqUfmO1U93WVFIL1RiP1Hw92Oi1fh9mg3e2yCheEchSttzo5I0S9RRfiZ+xa3p2vCc Cc: "" Subject: Re: [coman] [OPSAWG] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt 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, 23 Oct 2012 03:46:15 -0000 --Apple-Mail-EAEC3B4F-58B3-4440-AC92-BC0ADC73FB5F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mehmet, thanks for your reply. See below: On Oct 22, 2012, at 7:19, "Ersue, Mehmet (NSN - DE/Munich)" wrote: > > [ME]: There is no intention to exclude non-mobile devices. > =20 > s/non-mobile/mobile/ > =20 > Cheers,=20 > Mehmet > =20 > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf O= f Ersue, Mehmet (NSN - DE/Munich) > Sent: Monday, October 22, 2012 12:55 PM > To: ext Ulrich Herberg; Carsten Bormann > Cc: coman@ietf.org; opsawg@ietf.org > Subject: Re: [OPSAWG] [coman] FW: New Version Notification fordraft-ersue-= constrained-mgmt-02.txt > =20 > Hi Ulrich, > =20 > see my comments below. > =20 > Cheers,=20 > Mehmet > =20 > From: ext Ulrich Herberg [mailto:ulrich@herberg.name]=20 > Sent: Saturday, October 20, 2012 1:46 AM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: coman@ietf.org; opsawg@ietf.org > Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrai= ned-mgmt-02.txt > =20 > Hi Mehmet, > =20 > thank you for updating the draft. There is a huge amount of great work in i= t, and I think this will provide a great basis for further discussions. Inde= ed, splitting up the document would be required at some point. > =20 > Some high-level comments: > - Section 1.2 (Terminology): The definition of MANET and Intermediate en= tity (in COAP) come a bit surprising, since there has been no discussion bef= ore. Also, it seems inconsistent to define MANET, but not all the other use c= ases, such as AMI. > =20 > [ME]: The terminology section is incomplete and should be extended e.g. wi= th AMI. okay > =20 > - Section 1.3 (Constrained Device Classes): I know that this definition i= s taken from Lwig, but I doubt that it is of much use. The absolute values w= ill change. While now there are still many C0 devices out, in five years, th= ey will not exist (or rather, the number 10KB would need to be replaced by a= larger number). I think I would prefer a classification based on the capabi= lities (e.g. can support full IP stack, or not) > =20 > [ME]: The definition was actually first introduced by Carsten in the Smart= Object workshop before IETF 80 in Prague. This is an important point. See m= y other mail. Right, I understood that. > =20 > - Section 1.4 (constrained networks): I don't think this is a very consi= stent classification of networks. First, CN0 seems to be the least constrain= ed network, whereas C0 devices are the most constrained. I would suggest the= remain the same ordering (0 the most constrained up to a positive number). > =20 > [ME]: The =E2=80=9C0=E2=80=9D in CN0 and C0 don=E2=80=99t relate to each o= ther. The constrainedness of a network is mostly dependent on the wireless t= echnology used. I found it more useful to differentiate the type of the netw= ork, where the wireless technology can be manifold. > =20 > More importantly, there is a mixture with constrained devices in this defi= nition. Since we talk about the network only, we should only talk about topo= logy, lossy links, multi-hop, mobility etc. but not constrained devices.=20 > =20 > [ME]: I agree, we should talk here on devices only. > =20 > I don't understand why MANETs are not supported. Several of the use cases,= such as the military use case, community networks and AMI are multi-hop net= works with dynamic topology and lossy links. That is what I call a MANET. > =20 > [ME]: The agreement in our last f2f meeting was that we want to include th= e MANET use case to highlight what it is but exclude from the requirements d= iscussion. The reason is that MANETs can be based on very distinct scenarios= and have specifics which are unique compared to other networks. The essenti= al point is that MANETs are infrastructureless (i.e. without any hierarchy),= which seems to be not the case in other network types the draft describes a= nd makes network management essentially different. If we exclude MANETs, I'd like to understand why we don't exclude mesh netwo= rks or AMIs. I don't see a major difference in these networks (and I have st= udied them for a while). MANETs may be infrastructureless, yes, but so may b= e mesh networks. In both cases, there may be a gateway to other networks (In= ternet). Same for AMIs. Also, distributed management is mentioned in the dra= ft, so I am still unclear what particularities of MANETs make them so differ= ent. > =20 > Even the definition of CN1 is, IMO, entirely a MANET; you even mention Mes= h networks, which are nothing else than MANETs (only difference is that rout= ers are usually non-mobile; nevertheless, the topology is still dynamic beca= use of fluctuating links.). > =20 > [ME]: There might be similarities between a MANET and a Mesh network, howe= ver they are not the same thing. Then tell me the difference. > I have to admit we don=E2=80=99t conceive sufficiently the special MANET u= se cases for frequent movement of routing devices without infrastructure. > If we agree that a Mesh network covers the essential part of a MANET then I= would suggest to focus on a Mesh network instead of trying to cover everyth= ing. But why? I don't see any major difference (other than mobility) > =20 > Is the intention to focus on non-mobile devices? > =20 > [ME]: There is no intention to exclude non-mobile devices. The draft curre= ntly assumes that, from the =E2=80=9Cnetwork management=E2=80=9D pov., both m= obile and non-mobile devices have similar characteristics (I think we should= describe this somewhere). The draft further assumes that the managing entit= y is not moving. Why does it matter if the managing entity moves? It's all about the dynamic t= opology, so at any time the path between any node and the NMS can break.. An= d if the nodes can move, they can move away from the NMS anyway (so the conn= ection is interrupted) > =20 > I might be wrong in this. Please describe which mobility aspects you think= should be covered from =E2=80=9Cnetwork management=E2=80=9D I think we should cover dynamic topologies where links can frequently go up o= r down, are asymmetric and of low capacity. That can be due to mobility, or d= ue to other factors such as very flaky links. > pov. Managing the IP mobility itself, e.g. the IP address etc., is not net= work management per se. I agree. I'd call that autoconfiguration. > =20 > Constrained networks are more difficult to define, as there are several as= pects: bandwidth, loss rates of the channel, MTU, topology, etc. I think tha= t we need more discussion (but maybe after a BOF has been initiated?) > =20 > [ME]: We can start such a discussion already today. However, I assume it i= s mostly following the capabilities and limitations of the wireless technolo= gy. What would be your proposal for a classification of constrained networks= ? That is a good question... I'll think about it, and we can discuss that in A= tlanta. (I know, it's easy to criticize, but hard to be constructive ;-) > =20 > - Section 1.5: (Network Topology Options): I think there is a mix between t= he topology (i.e., the graph that represents routers and communication links= ), traffic flows (which devices communicate with which other devices), and a= pplication layer (proxies and NMS). > - Section 1.6: I like that. > =20 > - Section 1.7: There is mixture of constrained networks (first bullet); I t= hought that constrained devices only means that they have little CPU power a= nd memory. Can't that device still use cable connectivity (i.e. unconstraine= d network)? Or is it necessarily linked? > I am unclear about the purpose of this whole section. What does it serve f= or? > =20 > [ME]: Section 1.7 in general tries to list and discuss the issues a constr= ained device might have and how these issues influence the management of suc= h a device. As described in section 1.4 and 2. we include non-constrained ne= tworks with constrained devices. > =20 > - Section 2: I think that the problem statement is not quite clear yet. It= is hard to identify what the problems are; there are so many useful require= ments in section 4, so maybe it could be better matched to these requirement= s. It would be nice to read section 4, and then say "ah, requirement x indee= d logically follows from the problem y that has been described in section 2"= . > =20 > [ME]: I agree the problem statement in section 2 (which I didn=E2=80=99t h= ave time to update yet) could benefit from a revision aligning it with the n= ew sections 1.7 and section 4. > =20 > - Section 3: I like the diverse use cases. That can be very useful to iden= tify different requirements and problems. > =20 > - Section 4: I very much appreciate the enormous effort for gathering the r= equirements. There will be detailed discussions about them (hopefully), but t= his is a very good list to start from.=20 > We have to define if the security related requirements also fit in this di= scussion, or better some place else (SOLACE?).=20 > =20 > [ME]: We see authentication and access control (to the extend it matters) a= s part of network management. This is probably the part where Coman and Sola= ce can profit from and complement each other. It also depends where SOLACE is going.=20 > =20 > Again, I appreciate the effort of the authors, and hope that we can contin= ue the discussions in Atlanta. I apologize that I only provided this high-le= vel review, but the last weeks were very busy for me. If you need help autho= ring the documents once they are split up, I could help out. > =20 > Is there a meeting already planned?=20 > =20 > [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it on= ce the room is known. Stay tuned. Thanks. Looking forward to more discussions. Best Ulrich > =20 > Best regards > Ulrich=20 > =20 >=20 > On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, >=20 > we submitted an update for the constrained-mgmt draft on the "Management > of Networks with Constrained Devices: Use Cases and Requirements". The > draft hopefully addresses most of the issues we discussed in the last > meeting. >=20 > I think it is already time to split the draft into three; e.g. problem > statement, use cases and requirements. But this can be done after > getting your feedback before and during IETF 85. >=20 > I would highly appreciate your comments and any kind of discussion on > the draft content especially on the requirements section. Thank you. >=20 > Cheers, > Mehmet >=20 >=20 > -----Original Message----- > From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 15, 2012 9:59 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-02.txt >=20 >=20 > A new version of I-D, draft-ersue-constrained-mgmt-02.txt > has been successfully submitted by Mehmet Ersue and posted to the > IETF repository. >=20 > Filename: draft-ersue-constrained-mgmt > Revision: 02 > Title: Management of Networks with Constrained Devices: Use > Cases and Requirements > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 78 > URL: > http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt > Status: > http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt > Htmlized: > http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrained-mgmt-02 >=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 >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > =20 --Apple-Mail-EAEC3B4F-58B3-4440-AC92-BC0ADC73FB5F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Mehmet,

th= anks for your reply. See below:

On Oct 22, 2012, at 7:19, "Ersue, Meh= met (NSN - DE/Munich)" <mehmet.er= sue@nsn.com> wrote:

> [ME]: There is no intention to exclude n= on-mobile devices.

 

s/non-mo= bile/mobile/

 

Cheers,
Mehmet

 

From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of <= /b>Ersue, Mehmet (NSN - DE/Munich)
Sent: Monday, October 22, 2012 1= 2:55 PM
To: ext Ulrich Herberg; Carsten Bormann
Cc: coman@ietf.org; opsawg@ietf.org
Subject: Re: [OPSAWG] [coman] FW: New= Version Notification fordraft-ersue-constrained-mgmt-02.txt

 

Hi Ulrich,

 

see my comments below.

=

 

Cheers,
Mehmet=

&n= bsp;

From: ext Ulrich Herberg [mailto:ulrich@herberg.name]
Sent: Saturday, Octob= er 20, 2012 1:46 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc:<= /b> coman@ietf.org; opsawg@ietf.org
Subject: Re: [coman] FW: New V= ersion Notification for draft-ersue-constrained-mgmt-02.txt

 

Hi Mehmet,

 

thank you for updating the draft. Th= ere is a huge amount of great work in it, and I think this will provide a gr= eat basis for further discussions. Indeed, splitting up the document would b= e required at some point.

 

Some high-level comment= s:

  - Section 1.2 (Ter= minology): The definition of MANET and Intermediate entity (in COAP) come a b= it surprising, since there has been no discussion before. Also, it seems inc= onsistent to define MANET, but not all the other use cases, such as AMI.

 

[ME]: T= he terminology section is incomplete and should be extended e.g. with AMI.


okay=

<= div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.= 0pt">

 

=

  - Section 1.3 (Constrained Device C= lasses): I know that this definition is taken from Lwig, but I doubt that it= is of much use. The absolute values will change. While now there are still m= any C0 devices out, in five years, they will not exist (or rather, the numbe= r 10KB would need to be replaced by a larger number). I think I would prefer= a classification based on the capabilities (e.g. can support full IP stack,= or not)

 

[ME]: The definition was actually first introduced by Carsten in the S= mart Object workshop before IETF 80 in Prague. This is an important point. S= ee my other mail.

=
Right, I understood that.


 

  - Section 1.4 (constrained networks): I don't think this i= s a very consistent classification of networks. First, CN0 seems to be the l= east constrained network, whereas C0 devices are the most constrained. I wou= ld suggest the remain the same ordering (0 the most constrained up to a posi= tive number).

 

[ME]= : The =E2=80=9C0=E2=80=9D in CN0 and C0 don=E2=80=99t relate to each other. T= he constrainedness of a network is mostly dependent on the wireless technolo= gy used. I found it more useful to differentiate the type of the network, wh= ere the wireless technology can be manifold.

 

More importantly, there is a mixture with constrained d= evices in this definition. Since we talk about the network only, we should o= nly talk about topology, lossy links, multi-hop, mobility etc. but not const= rained devices. 

 

[ME]: I agree, we should talk here on devices only.

 

<= /div>

I don't understand why MANETs are not suppo= rted. Several of the use cases, such as the military use case, community net= works and AMI are multi-hop networks with dynamic topology and lossy links. T= hat is what I call a MANET.

 

<= p class=3D"MsoNormal">[ME]: The agreement in our last= f2f meeting was that we want to include the MANET use case to highlight wha= t it is but exclude from the requirements discussion. The reason is that MAN= ETs can be based on very distinct scenarios and have specifics which are uni= que compared to other networks. The essential point is that MANETs are infra= structureless (i.e. without any hierarchy), which seems to be not the case i= n other network types the draft describes and makes network management essen= tially different.

=
If we exclude MANETs, I'd like to understand why we don't exc= lude mesh networks or AMIs. I don't see a major difference in these networks= (and I have studied them for a while). MANETs may be infrastructureless, ye= s, but so may be mesh networks. In both cases, there may be a gateway to oth= er networks (Internet). Same for AMIs. Also, distributed management is menti= oned in the draft, so I am still unclear what particularities of MANETs make= them so different.


<= div class=3D"WordSection1">

 

Even the definition o= f CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are n= othing else than MANETs (only difference is that routers are usually non-mob= ile; nevertheless, the topology is still dynamic because of fluctuating link= s.).

 

<= span style=3D"font-size:10.0pt;font-family:"Verdana","sans-se= rif";color:blue">[ME]: There might be similarities between a MANET and a= Mesh network, however they are not the same thing.


Then tell me the difference= .

=

I have to admit we= don=E2=80=99t conceive sufficiently the special MANET use cases for frequen= t movement of routing devices without infrastructure.

=

If we agree that a Mesh network covers the essential part of a MANET then I= would suggest to focus on a Mesh network instead of trying to cover everyth= ing.


But why? I don't see any major difference (other than mobility)

<= blockquote type=3D"cite">

 

Is the intention to focus on non-mobile devices?

 

[ME]: There is no intention to exclu= de non-mobile devices. The draft currently assumes that, from the =E2=80=9Cn= etwork management=E2=80=9D pov., both mobile and non-mobile devices have sim= ilar characteristics (I think we should describe this somewhere). The draft f= urther assumes that the managing entity is not moving.


Why does it matter if th= e managing entity moves? It's all about the dynamic topology, so at any time= the path between any node and the NMS can break.. And if the nodes can move= , they can move away from the NMS anyway (so the connection is interrupted)<= /div>

 

<= p class=3D"MsoNormal">I might be wrong in this. Pleas= e describe which mobility aspects you think should be covered from =E2=80=9C= network management=E2=80=9D


I think we should cover dynamic topologies where l= inks can frequently go up or down, are asymmetric and of low capacity. That c= an be due to mobility, or due to other factors such as very flaky links.


pov. Mana= ging the IP mobility itself, e.g. the IP address etc., is not network manage= ment per se.


<= /div>
I agree. I'd call that autoconfiguration.

=  

Constrained networks are more difficult to define, as there are sev= eral aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I th= ink that we need more discussion (but maybe after a BOF has been initiated?)=

 

[ME]: We can star= t such a discussion already today. However, I assume it is mostly following t= he capabilities and limitations of the wireless technology. What would be yo= ur proposal for a classification of constrained networks?


That is a good questi= on... I'll think about it, and we can discuss that in Atlanta. (I know, it's= easy to criticize, but hard to be constructive ;-)


=

 

- Section 1.5: (Network Topology Options): I think there is a mix between= the topology (i.e., the graph that represents routers and communication lin= ks), traffic flows (which devices communicate with which other devices), and= application layer (proxies and NMS).

- Section 1.6: I like that.

 

- Section 1= .7: There is mixture of constrained networks (first bullet); I thought that c= onstrained devices only means that they have little CPU power and memory. Ca= n't that device still use cable connectivity (i.e. unconstrained network)? O= r is it necessarily linked?

= I am unclear about the purpose of this whole section. What does it serve for= ?

 

[= ME]: Section 1.7 in general tries to list and discuss the issues a constrain= ed device might have and how these issues influence the management of such a= device. As described in section 1.4 and 2. we include non-constrained netwo= rks with constrained devices.

 

- Section 2: I think that the problem statement is not quite clear ye= t. It is hard to identify what the problems are; there are so many useful re= quirements in section 4, so maybe it could be better matched to these requir= ements. It would be nice to read section 4, and then say "ah, requirement x i= ndeed logically follows from the problem y that has been described in sectio= n 2".

 = ;

[ME]: I agre= e the problem statement in section 2 (which I didn=E2=80=99t have time to up= date yet) could benefit from a revision aligning it with the new sections 1.= 7 and section 4.

 

- Section 3: I like the d= iverse use cases. That can be very useful to identify different requirements= and problems.

 

- Section 4: I very much appreciat= e the enormous effort for gathering the requirements. There will be detailed= discussions about them (hopefully), but this is a very good list to start f= rom. 

We have to define= if the security related requirements also fit in this discussion, or better= some place else (SOLACE?). 

 

[ME]: We see authentication and access control (to the exten= d it matters) as part of network management. This is probably the part where= Coman and Solace can profit from and complement each other.


It also depends wh= ere SOLACE is going. 

 

Again, I appreciate the effort of t= he authors, and hope that we can continue the discussions in Atlanta. I apol= ogize that I only provided this high-level review, but the last weeks were v= ery busy for me. If you need help authoring the documents once they are spli= t up, I could help out.

 

Is there a meeting already planned? 

=

 

[ME]: Yes, there will be a m= eeting on Thursday. I wanted to announce it once the room is known. Stay tun= ed.


Thanks. Looking forward to more discussions.

Best<= /div>
Ulrich


 

Best regards<= o:p>

Ulrich 

<= /div>

 <= /o:p>

On Wed, Oct 17, 2012 at 1:17 AM, Ersue,= Mehmet (NSN - DE/Munich) <mehmet.ersue@nsn.com> wrote:

Hi All,

we submitted an update for the constrained-mgmt draf= t on the "Management
of Networks with Constrained Devices: Use Cases and R= equirements". The
draft hopefully addresses most of the issues we discuss= ed in the last
meeting.

I think it is already time to split the dr= aft into three; e.g. problem
statement, use cases and requirements. But t= his can be done after
getting your feedback before and during IETF 85.
I would highly appreciate your comments and any kind of discussion onthe draft content especially on the requirements section. Thank you.
Cheers,
Mehmet


-----Original Message-----
From: ext internet-drafts@ietf.org [mailto:= internet-drafts@ietf.org]Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munic= h)
Cc: dromasca@avaya.com; j.schoenwaelder@jacobs-u= niversity.de
Subject: New Version Notification for
draft-ersue-con= strained-mgmt-02.txt


A new version of I-D, draft-ersue-constraine= d-mgmt-02.txt
has been successfully submitted by Mehmet Ersue and posted t= o the
IETF repository.

Filename:        draft-= ersue-constrained-mgmt
Revision:        02
Title: &= nbsp;         Management of Networks with Constrained De= vices: Use
Cases and Requirements
Creation date:   2012-10-15
= WG ID:           Individual Submission
Number of= pages: 78
URL:
http://www.ietf.org/internet= -drafts/draft-ersue-constrained-mgmt-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt
Htmlize= d:
http://tools.ietf.org/html/draft-ersue-constrained-mgmt-0= 2
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddr= aft-ersue-constrained-mgmt-02

Abstract:
   This docu= ment raises the questions on and discusses the use cases and
   = ;requirements for the management of networks with constrained devices.




The IETF Secretariat


__________________________= _____________________
coman mailing list
coman@ietf.org
https://www.ietf.org/mailman/listinfo/coman

 

= --Apple-Mail-EAEC3B4F-58B3-4440-AC92-BC0ADC73FB5F-- From mehmet.ersue@nsn.com Wed Oct 24 09:34:57 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 185BC21F8BCA for ; Wed, 24 Oct 2012 09:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjvRZ97x6seX for ; Wed, 24 Oct 2012 09:34:55 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0129421F8BC9 for ; Wed, 24 Oct 2012 09:34:53 -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 q9OGYlIx028651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Oct 2012 18:34:47 +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 q9OGYloj030602; Wed, 24 Oct 2012 18:34:47 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Oct 2012 18:34:46 +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_01CDB205.7A582528" Date: Wed, 24 Oct 2012 18:34:46 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640455E288@DEMUEXC006.nsn-intra.net> In-Reply-To: <7044BCBB-99B9-4906-95FB-B1509FED1E56@herberg.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] [coman] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt Thread-Index: Ac2w0PoTHOB+0l6rRqq9EW2knw2olAAYH0Dw References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A640455DA5B@DEMUEXC006.nsn-intra.net> <7044BCBB-99B9-4906-95FB-B1509FED1E56@herberg.name> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ulrich Herberg" X-OriginalArrivalTime: 24 Oct 2012 16:34:46.0712 (UTC) FILETIME=[7AB8BB80:01CDB205] 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: 63188 X-purgate-ID: 151667::1351096487-000048BF-B4E26BFC/0-0/0-0 Cc: coman@ietf.org Subject: Re: [coman] [OPSAWG] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt 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, 24 Oct 2012 16:34:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDB205.7A582528 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgVWxyaWNoLA0KDQogDQoNCk8mTSBhcmVhIGd1eXMgdXN1YWxseSBkb27igJl0IGhhdmUgc3Vm ZmljaWVudCBleHBlcnRpc2Ugb24gbWFuYWdpbmcgaGlnaGx5IGR5bmFtaWMgbmV0d29ya3Mgd2l0 aG91dCBhbnkgaGllcmFyY2h5IChwb3NzaWJseSB3aXRob3V0IGFueSBtYW5hZ2luZyBlbnRpdHkp LiBJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0byBmb2N1cyBmb3IgdGhlIHRpbWUgYmVpbmcgb24g bWVzaCBuZXR3b3JrcyB3aGVyZSB3ZSBhc3N1bWUgYSBrbm93biBoaWVyYXJjaHkgYW5kIGluZnJh c3RydWN0dXJlLg0KDQogDQoNClRob3VnaCwgYXMgd2Ugd2VyZSBkaXNjdXNzaW5nIGVhcmxpZXIs IEkgd291bGQgZmluZCBpdCB2ZXJ5IHVzZWZ1bCB0byBoYXZlIGEgZHJhZnQgYWRkcmVzc2luZyBl c3BlY2lhbGx5IHRoZSBtYW5hZ2VtZW50IG9mIE1BTkVULXR5cGUgb2YgbmV0d29ya3MuIElmIHdl IG9uY2UgaGF2ZSB0byBwcmVwYXJlIGEgY2hhcnRlciBwcm9wb3NhbCBzdWNoIGEgZHJhZnQgd291 bGQgYmUgdmVyeSBoZWxwZnVsIHRvIHJvdW5kIGl0IG9mZiBhbmQgd291bGQgcXVpdGUgbGlrZWx5 IGxlYWQgdG8gYSB3b3JrIGl0ZW0uIA0KDQogDQoNCkxldOKAmXMgZGlzY3VzcyB0aGlzIHRvcGlj IGFsc28gYXQgSUVURiAoSSBhbSBnb2luZyB0byBhcnJpdmUgb24gRnJpZGF5KS4NCg0KIA0KDQpD aGVlcnMsIA0KTWVobWV0DQoNCiANCg0KIA0KDQpGcm9tOiBleHQgVWxyaWNoIEhlcmJlcmcgW21h aWx0bzp1bHJpY2hAaGVyYmVyZy5uYW1lXSANClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjMsIDIw MTIgNTo0NiBBTQ0KVG86IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkNCkNjOiA8Y29t YW5AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09QU0FXR10gW2NvbWFuXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvcmRyYWZ0LWVyc3VlLWNvbnN0cmFpbmVkLW1nbXQtMDIudHh0DQoN CiANCg0KSGkgTWVobWV0LA0KDQogDQoNCnRoYW5rcyBmb3IgeW91ciByZXBseS4gU2VlIGJlbG93 Og0KDQpPbiBPY3QgMjIsIDIwMTIsIGF0IDc6MTksICJFcnN1ZSwgTWVobWV0IChOU04gLSBERS9N dW5pY2gpIiA8bWVobWV0LmVyc3VlQG5zbi5jb20+IHdyb3RlOg0KDQoJPiBbTUVdOiBUaGVyZSBp cyBubyBpbnRlbnRpb24gdG8gZXhjbHVkZSBub24tbW9iaWxlIGRldmljZXMuDQoNCgkgDQoNCglz L25vbi1tb2JpbGUvbW9iaWxlLw0KDQoJIA0KDQoJQ2hlZXJzLCANCglNZWhtZXQgDQoNCgkgDQoN CglGcm9tOiBvcHNhd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KCVNl bnQ6IE1vbmRheSwgT2N0b2JlciAyMiwgMjAxMiAxMjo1NSBQTQ0KCVRvOiBleHQgVWxyaWNoIEhl cmJlcmc7IENhcnN0ZW4gQm9ybWFubg0KCUNjOiBjb21hbkBpZXRmLm9yZzsgb3BzYXdnQGlldGYu b3JnDQoJU3ViamVjdDogUmU6IFtPUFNBV0ddIFtjb21hbl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3JkcmFmdC1lcnN1ZS1jb25zdHJhaW5lZC1tZ210LTAyLnR4dA0KDQoJIA0KDQoJ SGkgVWxyaWNoLA0KDQoJIA0KDQoJc2VlIG15IGNvbW1lbnRzIGJlbG93Lg0KDQoJIA0KDQoJQ2hl ZXJzLCANCglNZWhtZXQgDQoNCgkgDQoNCglGcm9tOiBleHQgVWxyaWNoIEhlcmJlcmcgW21haWx0 bzp1bHJpY2hAaGVyYmVyZy5uYW1lXSANCglTZW50OiBTYXR1cmRheSwgT2N0b2JlciAyMCwgMjAx MiAxOjQ2IEFNDQoJVG86IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkNCglDYzogY29t YW5AaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZw0KCVN1YmplY3Q6IFJlOiBbY29tYW5dIEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWVyc3VlLWNvbnN0cmFpbmVkLW1nbXQt MDIudHh0DQoNCgkgDQoNCglIaSBNZWhtZXQsDQoNCgkgDQoNCgl0aGFuayB5b3UgZm9yIHVwZGF0 aW5nIHRoZSBkcmFmdC4gVGhlcmUgaXMgYSBodWdlIGFtb3VudCBvZiBncmVhdCB3b3JrIGluIGl0 LCBhbmQgSSB0aGluayB0aGlzIHdpbGwgcHJvdmlkZSBhIGdyZWF0IGJhc2lzIGZvciBmdXJ0aGVy IGRpc2N1c3Npb25zLiBJbmRlZWQsIHNwbGl0dGluZyB1cCB0aGUgZG9jdW1lbnQgd291bGQgYmUg cmVxdWlyZWQgYXQgc29tZSBwb2ludC4NCg0KCSANCg0KCVNvbWUgaGlnaC1sZXZlbCBjb21tZW50 czoNCg0KCSAgLSBTZWN0aW9uIDEuMiAoVGVybWlub2xvZ3kpOiBUaGUgZGVmaW5pdGlvbiBvZiBN QU5FVCBhbmQgSW50ZXJtZWRpYXRlIGVudGl0eSAoaW4gQ09BUCkgY29tZSBhIGJpdCBzdXJwcmlz aW5nLCBzaW5jZSB0aGVyZSBoYXMgYmVlbiBubyBkaXNjdXNzaW9uIGJlZm9yZS4gQWxzbywgaXQg c2VlbXMgaW5jb25zaXN0ZW50IHRvIGRlZmluZSBNQU5FVCwgYnV0IG5vdCBhbGwgdGhlIG90aGVy IHVzZSBjYXNlcywgc3VjaCBhcyBBTUkuDQoNCgkgDQoNCglbTUVdOiBUaGUgdGVybWlub2xvZ3kg c2VjdGlvbiBpcyBpbmNvbXBsZXRlIGFuZCBzaG91bGQgYmUgZXh0ZW5kZWQgZS5nLiB3aXRoIEFN SS4NCg0KIA0KDQpva2F5DQoNCg0KDQoNCg0KIA0KDQogIC0gU2VjdGlvbiAxLjMgKENvbnN0cmFp bmVkIERldmljZSBDbGFzc2VzKTogSSBrbm93IHRoYXQgdGhpcyBkZWZpbml0aW9uIGlzIHRha2Vu IGZyb20gTHdpZywgYnV0IEkgZG91YnQgdGhhdCBpdCBpcyBvZiBtdWNoIHVzZS4gVGhlIGFic29s dXRlIHZhbHVlcyB3aWxsIGNoYW5nZS4gV2hpbGUgbm93IHRoZXJlIGFyZSBzdGlsbCBtYW55IEMw IGRldmljZXMgb3V0LCBpbiBmaXZlIHllYXJzLCB0aGV5IHdpbGwgbm90IGV4aXN0IChvciByYXRo ZXIsIHRoZSBudW1iZXIgMTBLQiB3b3VsZCBuZWVkIHRvIGJlIHJlcGxhY2VkIGJ5IGEgbGFyZ2Vy IG51bWJlcikuIEkgdGhpbmsgSSB3b3VsZCBwcmVmZXIgYSBjbGFzc2lmaWNhdGlvbiBiYXNlZCBv biB0aGUgY2FwYWJpbGl0aWVzIChlLmcuIGNhbiBzdXBwb3J0IGZ1bGwgSVAgc3RhY2ssIG9yIG5v dCkNCg0KIA0KDQpbTUVdOiBUaGUgZGVmaW5pdGlvbiB3YXMgYWN0dWFsbHkgZmlyc3QgaW50cm9k dWNlZCBieSBDYXJzdGVuIGluIHRoZSBTbWFydCBPYmplY3Qgd29ya3Nob3AgYmVmb3JlIElFVEYg ODAgaW4gUHJhZ3VlLiBUaGlzIGlzIGFuIGltcG9ydGFudCBwb2ludC4gU2VlIG15IG90aGVyIG1h aWwuDQoNCiANCg0KUmlnaHQsIEkgdW5kZXJzdG9vZCB0aGF0Lg0KDQogDQoNCg0KDQoNCg0KIA0K DQogIC0gU2VjdGlvbiAxLjQgKGNvbnN0cmFpbmVkIG5ldHdvcmtzKTogSSBkb24ndCB0aGluayB0 aGlzIGlzIGEgdmVyeSBjb25zaXN0ZW50IGNsYXNzaWZpY2F0aW9uIG9mIG5ldHdvcmtzLiBGaXJz dCwgQ04wIHNlZW1zIHRvIGJlIHRoZSBsZWFzdCBjb25zdHJhaW5lZCBuZXR3b3JrLCB3aGVyZWFz IEMwIGRldmljZXMgYXJlIHRoZSBtb3N0IGNvbnN0cmFpbmVkLiBJIHdvdWxkIHN1Z2dlc3QgdGhl IHJlbWFpbiB0aGUgc2FtZSBvcmRlcmluZyAoMCB0aGUgbW9zdCBjb25zdHJhaW5lZCB1cCB0byBh IHBvc2l0aXZlIG51bWJlcikuDQoNCiANCg0KW01FXTogVGhlIOKAnDDigJ0gaW4gQ04wIGFuZCBD MCBkb27igJl0IHJlbGF0ZSB0byBlYWNoIG90aGVyLiBUaGUgY29uc3RyYWluZWRuZXNzIG9mIGEg bmV0d29yayBpcyBtb3N0bHkgZGVwZW5kZW50IG9uIHRoZSB3aXJlbGVzcyB0ZWNobm9sb2d5IHVz ZWQuIEkgZm91bmQgaXQgbW9yZSB1c2VmdWwgdG8gZGlmZmVyZW50aWF0ZSB0aGUgdHlwZSBvZiB0 aGUgbmV0d29yaywgd2hlcmUgdGhlIHdpcmVsZXNzIHRlY2hub2xvZ3kgY2FuIGJlIG1hbmlmb2xk Lg0KDQogDQoNCk1vcmUgaW1wb3J0YW50bHksIHRoZXJlIGlzIGEgbWl4dHVyZSB3aXRoIGNvbnN0 cmFpbmVkIGRldmljZXMgaW4gdGhpcyBkZWZpbml0aW9uLiBTaW5jZSB3ZSB0YWxrIGFib3V0IHRo ZSBuZXR3b3JrIG9ubHksIHdlIHNob3VsZCBvbmx5IHRhbGsgYWJvdXQgdG9wb2xvZ3ksIGxvc3N5 IGxpbmtzLCBtdWx0aS1ob3AsIG1vYmlsaXR5IGV0Yy4gYnV0IG5vdCBjb25zdHJhaW5lZCBkZXZp Y2VzLiANCg0KIA0KDQpbTUVdOiBJIGFncmVlLCB3ZSBzaG91bGQgdGFsayBoZXJlIG9uIGRldmlj ZXMgb25seS4NCg0KIA0KDQpJIGRvbid0IHVuZGVyc3RhbmQgd2h5IE1BTkVUcyBhcmUgbm90IHN1 cHBvcnRlZC4gU2V2ZXJhbCBvZiB0aGUgdXNlIGNhc2VzLCBzdWNoIGFzIHRoZSBtaWxpdGFyeSB1 c2UgY2FzZSwgY29tbXVuaXR5IG5ldHdvcmtzIGFuZCBBTUkgYXJlIG11bHRpLWhvcCBuZXR3b3Jr cyB3aXRoIGR5bmFtaWMgdG9wb2xvZ3kgYW5kIGxvc3N5IGxpbmtzLiBUaGF0IGlzIHdoYXQgSSBj YWxsIGEgTUFORVQuIA0KDQogDQoNCltNRV06IFRoZSBhZ3JlZW1lbnQgaW4gb3VyIGxhc3QgZjJm IG1lZXRpbmcgd2FzIHRoYXQgd2Ugd2FudCB0byBpbmNsdWRlIHRoZSBNQU5FVCB1c2UgY2FzZSB0 byBoaWdobGlnaHQgd2hhdCBpdCBpcyBidXQgZXhjbHVkZSBmcm9tIHRoZSByZXF1aXJlbWVudHMg ZGlzY3Vzc2lvbi4gVGhlIHJlYXNvbiBpcyB0aGF0IE1BTkVUcyBjYW4gYmUgYmFzZWQgb24gdmVy eSBkaXN0aW5jdCBzY2VuYXJpb3MgYW5kIGhhdmUgc3BlY2lmaWNzIHdoaWNoIGFyZSB1bmlxdWUg Y29tcGFyZWQgdG8gb3RoZXIgbmV0d29ya3MuIFRoZSBlc3NlbnRpYWwgcG9pbnQgaXMgdGhhdCBN QU5FVHMgYXJlIGluZnJhc3RydWN0dXJlbGVzcyAoaS5lLiB3aXRob3V0IGFueSBoaWVyYXJjaHkp LCB3aGljaCBzZWVtcyB0byBiZSBub3QgdGhlIGNhc2UgaW4gb3RoZXIgbmV0d29yayB0eXBlcyB0 aGUgZHJhZnQgZGVzY3JpYmVzIGFuZCBtYWtlcyBuZXR3b3JrIG1hbmFnZW1lbnQgZXNzZW50aWFs bHkgZGlmZmVyZW50Lg0KDQogDQoNCklmIHdlIGV4Y2x1ZGUgTUFORVRzLCBJJ2QgbGlrZSB0byB1 bmRlcnN0YW5kIHdoeSB3ZSBkb24ndCBleGNsdWRlIG1lc2ggbmV0d29ya3Mgb3IgQU1Jcy4gSSBk b24ndCBzZWUgYSBtYWpvciBkaWZmZXJlbmNlIGluIHRoZXNlIG5ldHdvcmtzIChhbmQgSSBoYXZl IHN0dWRpZWQgdGhlbSBmb3IgYSB3aGlsZSkuIE1BTkVUcyBtYXkgYmUgaW5mcmFzdHJ1Y3R1cmVs ZXNzLCB5ZXMsIGJ1dCBzbyBtYXkgYmUgbWVzaCBuZXR3b3Jrcy4gSW4gYm90aCBjYXNlcywgdGhl cmUgbWF5IGJlIGEgZ2F0ZXdheSB0byBvdGhlciBuZXR3b3JrcyAoSW50ZXJuZXQpLiBTYW1lIGZv ciBBTUlzLiBBbHNvLCBkaXN0cmlidXRlZCBtYW5hZ2VtZW50IGlzIG1lbnRpb25lZCBpbiB0aGUg ZHJhZnQsIHNvIEkgYW0gc3RpbGwgdW5jbGVhciB3aGF0IHBhcnRpY3VsYXJpdGllcyBvZiBNQU5F VHMgbWFrZSB0aGVtIHNvIGRpZmZlcmVudC4NCg0KIA0KDQoNCg0KDQoNCiANCg0KRXZlbiB0aGUg ZGVmaW5pdGlvbiBvZiBDTjEgaXMsIElNTywgZW50aXJlbHkgYSBNQU5FVDsgeW91IGV2ZW4gbWVu dGlvbiBNZXNoIG5ldHdvcmtzLCB3aGljaCBhcmUgbm90aGluZyBlbHNlIHRoYW4gTUFORVRzIChv bmx5IGRpZmZlcmVuY2UgaXMgdGhhdCByb3V0ZXJzIGFyZSB1c3VhbGx5IG5vbi1tb2JpbGU7IG5l dmVydGhlbGVzcywgdGhlIHRvcG9sb2d5IGlzIHN0aWxsIGR5bmFtaWMgYmVjYXVzZSBvZiBmbHVj dHVhdGluZyBsaW5rcy4pLiANCg0KIA0KDQpbTUVdOiBUaGVyZSBtaWdodCBiZSBzaW1pbGFyaXRp ZXMgYmV0d2VlbiBhIE1BTkVUIGFuZCBhIE1lc2ggbmV0d29yaywgaG93ZXZlciB0aGV5IGFyZSBu b3QgdGhlIHNhbWUgdGhpbmcuDQoNCiANCg0KVGhlbiB0ZWxsIG1lIHRoZSBkaWZmZXJlbmNlLg0K DQoNCg0KDQoNCkkgaGF2ZSB0byBhZG1pdCB3ZSBkb27igJl0IGNvbmNlaXZlIHN1ZmZpY2llbnRs eSB0aGUgc3BlY2lhbCBNQU5FVCB1c2UgY2FzZXMgZm9yIGZyZXF1ZW50IG1vdmVtZW50IG9mIHJv dXRpbmcgZGV2aWNlcyB3aXRob3V0IGluZnJhc3RydWN0dXJlLg0KDQoJSWYgd2UgYWdyZWUgdGhh dCBhIE1lc2ggbmV0d29yayBjb3ZlcnMgdGhlIGVzc2VudGlhbCBwYXJ0IG9mIGEgTUFORVQgdGhl biBJIHdvdWxkIHN1Z2dlc3QgdG8gZm9jdXMgb24gYSBNZXNoIG5ldHdvcmsgaW5zdGVhZCBvZiB0 cnlpbmcgdG8gY292ZXIgZXZlcnl0aGluZy4NCg0KIA0KDQpCdXQgd2h5PyBJIGRvbid0IHNlZSBh bnkgbWFqb3IgZGlmZmVyZW5jZSAob3RoZXIgdGhhbiBtb2JpbGl0eSkNCg0KDQoNCg0KDQogDQoN CklzIHRoZSBpbnRlbnRpb24gdG8gZm9jdXMgb24gbm9uLW1vYmlsZSBkZXZpY2VzPw0KDQogDQoN CltNRV06IFRoZXJlIGlzIG5vIGludGVudGlvbiB0byBleGNsdWRlIG5vbi1tb2JpbGUgZGV2aWNl cy4gVGhlIGRyYWZ0IGN1cnJlbnRseSBhc3N1bWVzIHRoYXQsIGZyb20gdGhlIOKAnG5ldHdvcmsg bWFuYWdlbWVudOKAnSBwb3YuLCBib3RoIG1vYmlsZSBhbmQgbm9uLW1vYmlsZSBkZXZpY2VzIGhh dmUgc2ltaWxhciBjaGFyYWN0ZXJpc3RpY3MgKEkgdGhpbmsgd2Ugc2hvdWxkIGRlc2NyaWJlIHRo aXMgc29tZXdoZXJlKS4gVGhlIGRyYWZ0IGZ1cnRoZXIgYXNzdW1lcyB0aGF0IHRoZSBtYW5hZ2lu ZyBlbnRpdHkgaXMgbm90IG1vdmluZy4NCg0KIA0KDQpXaHkgZG9lcyBpdCBtYXR0ZXIgaWYgdGhl IG1hbmFnaW5nIGVudGl0eSBtb3Zlcz8gSXQncyBhbGwgYWJvdXQgdGhlIGR5bmFtaWMgdG9wb2xv Z3ksIHNvIGF0IGFueSB0aW1lIHRoZSBwYXRoIGJldHdlZW4gYW55IG5vZGUgYW5kIHRoZSBOTVMg Y2FuIGJyZWFrLi4gQW5kIGlmIHRoZSBub2RlcyBjYW4gbW92ZSwgdGhleSBjYW4gbW92ZSBhd2F5 IGZyb20gdGhlIE5NUyBhbnl3YXkgKHNvIHRoZSBjb25uZWN0aW9uIGlzIGludGVycnVwdGVkKQ0K DQoNCg0KDQoNCiANCg0KSSBtaWdodCBiZSB3cm9uZyBpbiB0aGlzLiBQbGVhc2UgZGVzY3JpYmUg d2hpY2ggbW9iaWxpdHkgYXNwZWN0cyB5b3UgdGhpbmsgc2hvdWxkIGJlIGNvdmVyZWQgZnJvbSDi gJxuZXR3b3JrIG1hbmFnZW1lbnTigJ0gDQoNCiANCg0KSSB0aGluayB3ZSBzaG91bGQgY292ZXIg ZHluYW1pYyB0b3BvbG9naWVzIHdoZXJlIGxpbmtzIGNhbiBmcmVxdWVudGx5IGdvIHVwIG9yIGRv d24sIGFyZSBhc3ltbWV0cmljIGFuZCBvZiBsb3cgY2FwYWNpdHkuIFRoYXQgY2FuIGJlIGR1ZSB0 byBtb2JpbGl0eSwgb3IgZHVlIHRvIG90aGVyIGZhY3RvcnMgc3VjaCBhcyB2ZXJ5IGZsYWt5IGxp bmtzLg0KDQogDQoNCg0KDQoNCg0KcG92LiBNYW5hZ2luZyB0aGUgSVAgbW9iaWxpdHkgaXRzZWxm LCBlLmcuIHRoZSBJUCBhZGRyZXNzIGV0Yy4sIGlzIG5vdCBuZXR3b3JrIG1hbmFnZW1lbnQgcGVy IHNlLg0KDQogDQoNCkkgYWdyZWUuIEknZCBjYWxsIHRoYXQgYXV0b2NvbmZpZ3VyYXRpb24uDQoN Cg0KDQoNCg0KIA0KDQpDb25zdHJhaW5lZCBuZXR3b3JrcyBhcmUgbW9yZSBkaWZmaWN1bHQgdG8g ZGVmaW5lLCBhcyB0aGVyZSBhcmUgc2V2ZXJhbCBhc3BlY3RzOiBiYW5kd2lkdGgsIGxvc3MgcmF0 ZXMgb2YgdGhlIGNoYW5uZWwsIE1UVSwgdG9wb2xvZ3ksIGV0Yy4gSSB0aGluayB0aGF0IHdlIG5l ZWQgbW9yZSBkaXNjdXNzaW9uIChidXQgbWF5YmUgYWZ0ZXIgYSBCT0YgaGFzIGJlZW4gaW5pdGlh dGVkPykNCg0KIA0KDQpbTUVdOiBXZSBjYW4gc3RhcnQgc3VjaCBhIGRpc2N1c3Npb24gYWxyZWFk eSB0b2RheS4gSG93ZXZlciwgSSBhc3N1bWUgaXQgaXMgbW9zdGx5IGZvbGxvd2luZyB0aGUgY2Fw YWJpbGl0aWVzIGFuZCBsaW1pdGF0aW9ucyBvZiB0aGUgd2lyZWxlc3MgdGVjaG5vbG9neS4gV2hh dCB3b3VsZCBiZSB5b3VyIHByb3Bvc2FsIGZvciBhIGNsYXNzaWZpY2F0aW9uIG9mIGNvbnN0cmFp bmVkIG5ldHdvcmtzPw0KDQogDQoNClRoYXQgaXMgYSBnb29kIHF1ZXN0aW9uLi4uIEknbGwgdGhp bmsgYWJvdXQgaXQsIGFuZCB3ZSBjYW4gZGlzY3VzcyB0aGF0IGluIEF0bGFudGEuIChJIGtub3cs IGl0J3MgZWFzeSB0byBjcml0aWNpemUsIGJ1dCBoYXJkIHRvIGJlIGNvbnN0cnVjdGl2ZSA7LSkN Cg0KIA0KDQoNCg0KDQoNCiANCg0KLSBTZWN0aW9uIDEuNTogKE5ldHdvcmsgVG9wb2xvZ3kgT3B0 aW9ucyk6IEkgdGhpbmsgdGhlcmUgaXMgYSBtaXggYmV0d2VlbiB0aGUgdG9wb2xvZ3kgKGkuZS4s IHRoZSBncmFwaCB0aGF0IHJlcHJlc2VudHMgcm91dGVycyBhbmQgY29tbXVuaWNhdGlvbiBsaW5r cyksIHRyYWZmaWMgZmxvd3MgKHdoaWNoIGRldmljZXMgY29tbXVuaWNhdGUgd2l0aCB3aGljaCBv dGhlciBkZXZpY2VzKSwgYW5kIGFwcGxpY2F0aW9uIGxheWVyIChwcm94aWVzIGFuZCBOTVMpLg0K DQotIFNlY3Rpb24gMS42OiBJIGxpa2UgdGhhdC4NCg0KIA0KDQotIFNlY3Rpb24gMS43OiBUaGVy ZSBpcyBtaXh0dXJlIG9mIGNvbnN0cmFpbmVkIG5ldHdvcmtzIChmaXJzdCBidWxsZXQpOyBJIHRo b3VnaHQgdGhhdCBjb25zdHJhaW5lZCBkZXZpY2VzIG9ubHkgbWVhbnMgdGhhdCB0aGV5IGhhdmUg bGl0dGxlIENQVSBwb3dlciBhbmQgbWVtb3J5LiBDYW4ndCB0aGF0IGRldmljZSBzdGlsbCB1c2Ug Y2FibGUgY29ubmVjdGl2aXR5IChpLmUuIHVuY29uc3RyYWluZWQgbmV0d29yayk/IE9yIGlzIGl0 IG5lY2Vzc2FyaWx5IGxpbmtlZD8NCg0KSSBhbSB1bmNsZWFyIGFib3V0IHRoZSBwdXJwb3NlIG9m IHRoaXMgd2hvbGUgc2VjdGlvbi4gV2hhdCBkb2VzIGl0IHNlcnZlIGZvcj8NCg0KIA0KDQpbTUVd OiBTZWN0aW9uIDEuNyBpbiBnZW5lcmFsIHRyaWVzIHRvIGxpc3QgYW5kIGRpc2N1c3MgdGhlIGlz c3VlcyBhIGNvbnN0cmFpbmVkIGRldmljZSBtaWdodCBoYXZlIGFuZCBob3cgdGhlc2UgaXNzdWVz IGluZmx1ZW5jZSB0aGUgbWFuYWdlbWVudCBvZiBzdWNoIGEgZGV2aWNlLiBBcyBkZXNjcmliZWQg aW4gc2VjdGlvbiAxLjQgYW5kIDIuIHdlIGluY2x1ZGUgbm9uLWNvbnN0cmFpbmVkIG5ldHdvcmtz IHdpdGggY29uc3RyYWluZWQgZGV2aWNlcy4NCg0KIA0KDQotIFNlY3Rpb24gMjogSSB0aGluayB0 aGF0IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpcyBub3QgcXVpdGUgY2xlYXIgeWV0LiBJdCBpcyBo YXJkIHRvIGlkZW50aWZ5IHdoYXQgdGhlIHByb2JsZW1zIGFyZTsgdGhlcmUgYXJlIHNvIG1hbnkg dXNlZnVsIHJlcXVpcmVtZW50cyBpbiBzZWN0aW9uIDQsIHNvIG1heWJlIGl0IGNvdWxkIGJlIGJl dHRlciBtYXRjaGVkIHRvIHRoZXNlIHJlcXVpcmVtZW50cy4gSXQgd291bGQgYmUgbmljZSB0byBy ZWFkIHNlY3Rpb24gNCwgYW5kIHRoZW4gc2F5ICJhaCwgcmVxdWlyZW1lbnQgeCBpbmRlZWQgbG9n aWNhbGx5IGZvbGxvd3MgZnJvbSB0aGUgcHJvYmxlbSB5IHRoYXQgaGFzIGJlZW4gZGVzY3JpYmVk IGluIHNlY3Rpb24gMiIuDQoNCiANCg0KW01FXTogSSBhZ3JlZSB0aGUgcHJvYmxlbSBzdGF0ZW1l bnQgaW4gc2VjdGlvbiAyICh3aGljaCBJIGRpZG7igJl0IGhhdmUgdGltZSB0byB1cGRhdGUgeWV0 KSBjb3VsZCBiZW5lZml0IGZyb20gYSByZXZpc2lvbiBhbGlnbmluZyBpdCB3aXRoIHRoZSBuZXcg c2VjdGlvbnMgMS43IGFuZCBzZWN0aW9uIDQuDQoNCiANCg0KLSBTZWN0aW9uIDM6IEkgbGlrZSB0 aGUgZGl2ZXJzZSB1c2UgY2FzZXMuIFRoYXQgY2FuIGJlIHZlcnkgdXNlZnVsIHRvIGlkZW50aWZ5 IGRpZmZlcmVudCByZXF1aXJlbWVudHMgYW5kIHByb2JsZW1zLg0KDQogDQoNCi0gU2VjdGlvbiA0 OiBJIHZlcnkgbXVjaCBhcHByZWNpYXRlIHRoZSBlbm9ybW91cyBlZmZvcnQgZm9yIGdhdGhlcmlu ZyB0aGUgcmVxdWlyZW1lbnRzLiBUaGVyZSB3aWxsIGJlIGRldGFpbGVkIGRpc2N1c3Npb25zIGFi b3V0IHRoZW0gKGhvcGVmdWxseSksIGJ1dCB0aGlzIGlzIGEgdmVyeSBnb29kIGxpc3QgdG8gc3Rh cnQgZnJvbS4gDQoNCldlIGhhdmUgdG8gZGVmaW5lIGlmIHRoZSBzZWN1cml0eSByZWxhdGVkIHJl cXVpcmVtZW50cyBhbHNvIGZpdCBpbiB0aGlzIGRpc2N1c3Npb24sIG9yIGJldHRlciBzb21lIHBs YWNlIGVsc2UgKFNPTEFDRT8pLiANCg0KIA0KDQpbTUVdOiBXZSBzZWUgYXV0aGVudGljYXRpb24g YW5kIGFjY2VzcyBjb250cm9sICh0byB0aGUgZXh0ZW5kIGl0IG1hdHRlcnMpIGFzIHBhcnQgb2Yg bmV0d29yayBtYW5hZ2VtZW50LiBUaGlzIGlzIHByb2JhYmx5IHRoZSBwYXJ0IHdoZXJlIENvbWFu IGFuZCBTb2xhY2UgY2FuIHByb2ZpdCBmcm9tIGFuZCBjb21wbGVtZW50IGVhY2ggb3RoZXIuDQoN CiANCg0KSXQgYWxzbyBkZXBlbmRzIHdoZXJlIFNPTEFDRSBpcyBnb2luZy4gDQoNCg0KDQoNCg0K IA0KDQpBZ2FpbiwgSSBhcHByZWNpYXRlIHRoZSBlZmZvcnQgb2YgdGhlIGF1dGhvcnMsIGFuZCBo b3BlIHRoYXQgd2UgY2FuIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9ucyBpbiBBdGxhbnRhLiBJIGFw b2xvZ2l6ZSB0aGF0IEkgb25seSBwcm92aWRlZCB0aGlzIGhpZ2gtbGV2ZWwgcmV2aWV3LCBidXQg dGhlIGxhc3Qgd2Vla3Mgd2VyZSB2ZXJ5IGJ1c3kgZm9yIG1lLiBJZiB5b3UgbmVlZCBoZWxwIGF1 dGhvcmluZyB0aGUgZG9jdW1lbnRzIG9uY2UgdGhleSBhcmUgc3BsaXQgdXAsIEkgY291bGQgaGVs cCBvdXQuDQoNCiANCg0KSXMgdGhlcmUgYSBtZWV0aW5nIGFscmVhZHkgcGxhbm5lZD8gDQoNCiAN Cg0KW01FXTogWWVzLCB0aGVyZSB3aWxsIGJlIGEgbWVldGluZyBvbiBUaHVyc2RheS4gSSB3YW50 ZWQgdG8gYW5ub3VuY2UgaXQgb25jZSB0aGUgcm9vbSBpcyBrbm93bi4gU3RheSB0dW5lZC4NCg0K IA0KDQpUaGFua3MuIExvb2tpbmcgZm9yd2FyZCB0byBtb3JlIGRpc2N1c3Npb25zLg0KDQogDQoN CkJlc3QNCg0KVWxyaWNoDQoNCiANCg0KDQoNCg0KDQogDQoNCkJlc3QgcmVnYXJkcw0KDQpVbHJp Y2ggDQoNCiANCg0KT24gV2VkLCBPY3QgMTcsIDIwMTIgYXQgMToxNyBBTSwgRXJzdWUsIE1laG1l dCAoTlNOIC0gREUvTXVuaWNoKSA8bWVobWV0LmVyc3VlQG5zbi5jb20+IHdyb3RlOg0KDQpIaSBB bGwsDQoNCndlIHN1Ym1pdHRlZCBhbiB1cGRhdGUgZm9yIHRoZSBjb25zdHJhaW5lZC1tZ210IGRy YWZ0IG9uIHRoZSAiTWFuYWdlbWVudA0Kb2YgTmV0d29ya3Mgd2l0aCBDb25zdHJhaW5lZCBEZXZp Y2VzOiBVc2UgQ2FzZXMgYW5kIFJlcXVpcmVtZW50cyIuIFRoZQ0KZHJhZnQgaG9wZWZ1bGx5IGFk ZHJlc3NlcyBtb3N0IG9mIHRoZSBpc3N1ZXMgd2UgZGlzY3Vzc2VkIGluIHRoZSBsYXN0DQptZWV0 aW5nLg0KDQpJIHRoaW5rIGl0IGlzIGFscmVhZHkgdGltZSB0byBzcGxpdCB0aGUgZHJhZnQgaW50 byB0aHJlZTsgZS5nLiBwcm9ibGVtDQpzdGF0ZW1lbnQsIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1l bnRzLiBCdXQgdGhpcyBjYW4gYmUgZG9uZSBhZnRlcg0KZ2V0dGluZyB5b3VyIGZlZWRiYWNrIGJl Zm9yZSBhbmQgZHVyaW5nIElFVEYgODUuDQoNCkkgd291bGQgaGlnaGx5IGFwcHJlY2lhdGUgeW91 ciBjb21tZW50cyBhbmQgYW55IGtpbmQgb2YgZGlzY3Vzc2lvbiBvbg0KdGhlIGRyYWZ0IGNvbnRl bnQgZXNwZWNpYWxseSBvbiB0aGUgcmVxdWlyZW1lbnRzIHNlY3Rpb24uIFRoYW5rIHlvdS4NCg0K Q2hlZXJzLA0KTWVobWV0DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4 dCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMTUsIDIwMTIgOTo1OSBQTQ0KVG86IEVyc3VlLCBN ZWhtZXQgKE5TTiAtIERFL011bmljaCkNCkNjOiBkcm9tYXNjYUBhdmF5YS5jb207IGouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvcg0KZHJhZnQtZXJzdWUtY29uc3RyYWluZWQtbWdtdC0wMi50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZXJzdWUtY29uc3RyYWluZWQtbWdtdC0wMi50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWVobWV0IEVyc3VlIGFuZCBwb3N0ZWQg dG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtZXJzdWUt Y29uc3RyYWluZWQtbWdtdA0KUmV2aXNpb246ICAgICAgICAwMg0KVGl0bGU6ICAgICAgICAgICBN YW5hZ2VtZW50IG9mIE5ldHdvcmtzIHdpdGggQ29uc3RyYWluZWQgRGV2aWNlczogVXNlDQpDYXNl cyBhbmQgUmVxdWlyZW1lbnRzDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTItMTAtMTUNCldHIElEOiAg ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDc4DQpVUkw6 DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1lcnN1ZS1jb25zdHJh aW5lZC1tZ210LTAyLnR4dA0KU3RhdHVzOg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1lcnN1ZS1jb25zdHJhaW5lZC1tZ210DQpIdG1saXplZDoNCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWVyc3VlLWNvbnN0cmFpbmVkLW1nbXQtMDINCkRpZmY6DQpodHRw Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1lcnN1ZS1jb25zdHJhaW5lZC1tZ210 LTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCByYWlzZXMgdGhlIHF1ZXN0aW9ucyBv biBhbmQgZGlzY3Vzc2VzIHRoZSB1c2UgY2FzZXMgYW5kDQogICByZXF1aXJlbWVudHMgZm9yIHRo ZSBtYW5hZ2VtZW50IG9mIG5ldHdvcmtzIHdpdGggY29uc3RyYWluZWQgZGV2aWNlcy4NCg0KDQoN Cg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpjb21hbiBtYWlsaW5nIGxpc3QNCmNvbWFuQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvbWFuDQoNCiANCg0K ------_=_NextPart_001_01CDB205.7A582528 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymx1ZTt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsdWU7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IlZl cmRhbmEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibHVlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNs YXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5I aSBVbHJpY2gsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJz YW5zLXNlcmlmIjtjb2xvcjpibHVlJz5PJmFtcDtNIGFyZWEgZ3V5cyB1c3VhbGx5IGRvbuKAmXQg aGF2ZSBzdWZmaWNpZW50IGV4cGVydGlzZSBvbiBtYW5hZ2luZyBoaWdobHkgZHluYW1pYyBuZXR3 b3JrcyB3aXRob3V0IGFueSBoaWVyYXJjaHkgKHBvc3NpYmx5IHdpdGhvdXQgYW55IG1hbmFnaW5n IGVudGl0eSkuIEkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRvIGZvY3VzIGZvciB0aGUgdGltZSBi ZWluZyBvbiBtZXNoIG5ldHdvcmtzIHdoZXJlIHdlIGFzc3VtZSBhIGtub3duIGhpZXJhcmNoeSBh bmQgaW5mcmFzdHJ1Y3R1cmUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNh bnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZl cmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5UaG91Z2gsIGFzIHdlIHdlcmUgZGlzY3Vz c2luZyBlYXJsaWVyLCBJIHdvdWxkIGZpbmQgaXQgdmVyeSB1c2VmdWwgdG8gaGF2ZSBhIGRyYWZ0 IGFkZHJlc3NpbmcgZXNwZWNpYWxseSB0aGUgbWFuYWdlbWVudCBvZiBNQU5FVC10eXBlIG9mIG5l dHdvcmtzLiBJZiB3ZSBvbmNlIGhhdmUgdG8gcHJlcGFyZSBhIGNoYXJ0ZXIgcHJvcG9zYWwgc3Vj aCBhIGRyYWZ0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bCB0byByb3VuZCBpdCBvZmYgYW5kIHdvdWxk IHF1aXRlIGxpa2VseSBsZWFkIHRvIGEgd29yayBpdGVtLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkxldOKAmXMg ZGlzY3VzcyB0aGlzIHRvcGljIGFsc28gYXQgSUVURiAoSSBhbSBnb2luZyB0byBhcnJpdmUgb24g RnJpZGF5KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7 Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5h Iiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+Q2hlZXJzLDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs dWUnPiA8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+TWVobWV0PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48 ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gZXh0IFVscmljaCBIZXJiZXJnIFs8YSBocmVmPSJt YWlsdG86dWxyaWNoQGhlcmJlcmcubmFtZSI+bWFpbHRvOnVscmljaEBoZXJiZXJnLm5hbWU8L2E+ XSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMjMsIDIwMTIgNTo0NiBBTTxicj48 Yj5Ubzo8L2I+IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCk8YnI+PGI+Q2M6PC9iPiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmNvbWFuQGlldGYub3JnIj5jb21hbkBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09QU0FXR10gW2NvbWFuXSBGVzogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvcmRyYWZ0LWVyc3VlLWNvbnN0cmFpbmVkLW1nbXQtMDIudHh0PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5IaSBNZWhtZXQsPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz50 aGFua3MgZm9yIHlvdXIgcmVwbHkuIFNlZSBiZWxvdzo8YnI+PGJyPk9uIE9jdCAyMiwgMjAxMiwg YXQgNzoxOSwgJnF1b3Q7RXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKSZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1laG1ldC5lcnN1ZUBuc24uY29tIj5tZWhtZXQuZXJzdWVAbnNuLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwi c2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+Jmd0OyBbTUVdOiBUaGVyZSBpcyBubyBpbnRlbnRpb24g dG8gZXhjbHVkZSBub24tbW9iaWxlIGRldmljZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5zL25vbi1tb2JpbGUv bW9iaWxlLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtj b2xvcjpibHVlJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEi LCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5DaGVlcnMsPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1 ZSc+IDxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5NZWhtZXQ8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibHVlJz4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNh bnMtc2VyaWYiO2NvbG9yOmJsdWUnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1z b05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWls dG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmciPm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnPC9hPiBb PGEgaHJlZj0ibWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b3BzYXdnLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyc3VlLCBNZWhtZXQgKE5T TiAtIERFL011bmljaCk8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAyMiwgMjAxMiAx Mjo1NSBQTTxicj48Yj5Ubzo8L2I+IGV4dCBVbHJpY2ggSGVyYmVyZzsgQ2Fyc3RlbiBCb3JtYW5u PGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmNvbWFuQGlldGYub3JnIj5jb21hbkBpZXRm Lm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5vcmciPm9wc2F3Z0BpZXRmLm9y ZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT1BTQVdHXSBbY29tYW5dIEZXOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yZHJhZnQtZXJzdWUtY29uc3RyYWluZWQtbWdtdC0wMi50eHQ8 L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNw OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkhp IFVscmljaCw8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7 Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNh bnMtc2VyaWYiO2NvbG9yOmJsdWUnPnNlZSBteSBjb21tZW50cyBiZWxvdy48L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUn PkNoZWVycyw8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz4gPGJyPjwvc3Bhbj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsdWUnPk1laG1ldDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiA8L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IGV4dCBVbHJpY2ggSGVyYmVyZyBbPGEgaHJlZj0ibWFpbHRvOnVscmljaEBo ZXJiZXJnLm5hbWUiPm1haWx0bzp1bHJpY2hAaGVyYmVyZy5uYW1lPC9hPl0gPGJyPjxiPlNlbnQ6 PC9iPiBTYXR1cmRheSwgT2N0b2JlciAyMCwgMjAxMiAxOjQ2IEFNPGJyPjxiPlRvOjwvYj4gRXJz dWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKTxicj48Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0 bzpjb21hbkBpZXRmLm9yZyI+Y29tYW5AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86b3Bz YXdnQGlldGYub3JnIj5vcHNhd2dAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTog W2NvbWFuXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1lcnN1ZS1jb25z dHJhaW5lZC1tZ210LTAyLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkhp IE1laG1ldCw8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD50aGFuayB5b3UgZm9yIHVw ZGF0aW5nIHRoZSBkcmFmdC4gVGhlcmUgaXMgYSBodWdlIGFtb3VudCBvZiBncmVhdCB3b3JrIGlu IGl0LCBhbmQgSSB0aGluayB0aGlzIHdpbGwgcHJvdmlkZSBhIGdyZWF0IGJhc2lzIGZvciBmdXJ0 aGVyIGRpc2N1c3Npb25zLiBJbmRlZWQsIHNwbGl0dGluZyB1cCB0aGUgZG9jdW1lbnQgd291bGQg YmUgcmVxdWlyZWQgYXQgc29tZSBwb2ludC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5Tb21lIGhpZ2gtbGV2ZWwgY29tbWVudHM6PG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7IC0gU2VjdGlvbiAxLjIgKFRlcm1pbm9sb2d5KTog VGhlIGRlZmluaXRpb24gb2YgTUFORVQgYW5kIEludGVybWVkaWF0ZSBlbnRpdHkgKGluIENPQVAp IGNvbWUgYSBiaXQgc3VycHJpc2luZywgc2luY2UgdGhlcmUgaGFzIGJlZW4gbm8gZGlzY3Vzc2lv biBiZWZvcmUuIEFsc28sIGl0IHNlZW1zIGluY29uc2lzdGVudCB0byBkZWZpbmUgTUFORVQsIGJ1 dCBub3QgYWxsIHRoZSBvdGhlciB1c2UgY2FzZXMsIHN1Y2ggYXMgQU1JLjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlJz4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29s b3I6Ymx1ZSc+W01FXTogVGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gaXMgaW5jb21wbGV0ZSBhbmQg c2hvdWxkIGJlIGV4dGVuZGVkIGUuZy4gd2l0aCBBTUkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5va2F5 PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48YnI+PG86cD48L286 cD48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7IC0gU2Vj dGlvbiAxLjMgKENvbnN0cmFpbmVkIERldmljZSBDbGFzc2VzKTogSSBrbm93IHRoYXQgdGhpcyBk ZWZpbml0aW9uIGlzIHRha2VuIGZyb20gTHdpZywgYnV0IEkgZG91YnQgdGhhdCBpdCBpcyBvZiBt dWNoIHVzZS4gVGhlIGFic29sdXRlIHZhbHVlcyB3aWxsIGNoYW5nZS4gV2hpbGUgbm93IHRoZXJl IGFyZSBzdGlsbCBtYW55IEMwIGRldmljZXMgb3V0LCBpbiBmaXZlIHllYXJzLCB0aGV5IHdpbGwg bm90IGV4aXN0IChvciByYXRoZXIsIHRoZSBudW1iZXIgMTBLQiB3b3VsZCBuZWVkIHRvIGJlIHJl cGxhY2VkIGJ5IGEgbGFyZ2VyIG51bWJlcikuIEkgdGhpbmsgSSB3b3VsZCBwcmVmZXIgYSBjbGFz c2lmaWNhdGlvbiBiYXNlZCBvbiB0aGUgY2FwYWJpbGl0aWVzIChlLmcuIGNhbiBzdXBwb3J0IGZ1 bGwgSVAgc3RhY2ssIG9yIG5vdCk8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPltNRV06IFRoZSBkZWZp bml0aW9uIHdhcyBhY3R1YWxseSBmaXJzdCBpbnRyb2R1Y2VkIGJ5IENhcnN0ZW4gaW4gdGhlIFNt YXJ0IE9iamVjdCB3b3Jrc2hvcCBiZWZvcmUgSUVURiA4MCBpbiBQcmFndWUuIFRoaXMgaXMgYW4g aW1wb3J0YW50IHBvaW50LiBTZWUgbXkgb3RoZXIgbWFpbC48L3NwYW4+PG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+UmlnaHQsIEkgdW5kZXJz dG9vZCB0aGF0LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGJyPjxvOnA+ PC9vOnA+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyAt IFNlY3Rpb24gMS40IChjb25zdHJhaW5lZCBuZXR3b3Jrcyk6IEkgZG9uJ3QgdGhpbmsgdGhpcyBp cyBhIHZlcnkgY29uc2lzdGVudCBjbGFzc2lmaWNhdGlvbiBvZiBuZXR3b3Jrcy4gRmlyc3QsIENO MCBzZWVtcyB0byBiZSB0aGUgbGVhc3QgY29uc3RyYWluZWQgbmV0d29yaywgd2hlcmVhcyBDMCBk ZXZpY2VzIGFyZSB0aGUgbW9zdCBjb25zdHJhaW5lZC4gSSB3b3VsZCBzdWdnZXN0IHRoZSByZW1h aW4gdGhlIHNhbWUgb3JkZXJpbmcgKDAgdGhlIG1vc3QgY29uc3RyYWluZWQgdXAgdG8gYSBwb3Np dGl2ZSBudW1iZXIpLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsdWUnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5z LXNlcmlmIjtjb2xvcjpibHVlJz5bTUVdOiBUaGUg4oCcMOKAnSBpbiBDTjAgYW5kIEMwIGRvbuKA mXQgcmVsYXRlIHRvIGVhY2ggb3RoZXIuIFRoZSBjb25zdHJhaW5lZG5lc3Mgb2YgYSBuZXR3b3Jr IGlzIG1vc3RseSBkZXBlbmRlbnQgb24gdGhlIHdpcmVsZXNzIHRlY2hub2xvZ3kgdXNlZC4gSSBm b3VuZCBpdCBtb3JlIHVzZWZ1bCB0byBkaWZmZXJlbnRpYXRlIHRoZSB0eXBlIG9mIHRoZSBuZXR3 b3JrLCB3aGVyZSB0aGUgd2lyZWxlc3MgdGVjaG5vbG9neSBjYW4gYmUgbWFuaWZvbGQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5N b3JlIGltcG9ydGFudGx5LCB0aGVyZSBpcyBhIG1peHR1cmUgd2l0aCBjb25zdHJhaW5lZCBkZXZp Y2VzIGluIHRoaXMgZGVmaW5pdGlvbi4gU2luY2Ugd2UgdGFsayBhYm91dCB0aGUgbmV0d29yayBv bmx5LCB3ZSBzaG91bGQgb25seSB0YWxrIGFib3V0IHRvcG9sb2d5LCBsb3NzeSBsaW5rcywgbXVs dGktaG9wLCBtb2JpbGl0eSBldGMuIGJ1dCBub3QgY29uc3RyYWluZWQgZGV2aWNlcy4mbmJzcDs8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6 Ymx1ZSc+W01FXTogSSBhZ3JlZSwgd2Ugc2hvdWxkIHRhbGsgaGVyZSBvbiBkZXZpY2VzIG9ubHku PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs dWUnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5JIGRvbid0IHVuZGVyc3RhbmQgd2h5IE1BTkVUcyBhcmUgbm90IHN1cHBvcnRlZC4gU2V2 ZXJhbCBvZiB0aGUgdXNlIGNhc2VzLCBzdWNoIGFzIHRoZSBtaWxpdGFyeSB1c2UgY2FzZSwgY29t bXVuaXR5IG5ldHdvcmtzIGFuZCBBTUkgYXJlIG11bHRpLWhvcCBuZXR3b3JrcyB3aXRoIGR5bmFt aWMgdG9wb2xvZ3kgYW5kIGxvc3N5IGxpbmtzLiBUaGF0IGlzIHdoYXQgSSBjYWxsIGEgTUFORVQu IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xv cjpibHVlJz5bTUVdOiBUaGUgYWdyZWVtZW50IGluIG91ciBsYXN0IGYyZiBtZWV0aW5nIHdhcyB0 aGF0IHdlIHdhbnQgdG8gaW5jbHVkZSB0aGUgTUFORVQgdXNlIGNhc2UgdG8gaGlnaGxpZ2h0IHdo YXQgaXQgaXMgYnV0IGV4Y2x1ZGUgZnJvbSB0aGUgcmVxdWlyZW1lbnRzIGRpc2N1c3Npb24uIFRo ZSByZWFzb24gaXMgdGhhdCBNQU5FVHMgY2FuIGJlIGJhc2VkIG9uIHZlcnkgZGlzdGluY3Qgc2Nl bmFyaW9zIGFuZCBoYXZlIHNwZWNpZmljcyB3aGljaCBhcmUgdW5pcXVlIGNvbXBhcmVkIHRvIG90 aGVyIG5ldHdvcmtzLiBUaGUgZXNzZW50aWFsIHBvaW50IGlzIHRoYXQgTUFORVRzIGFyZSBpbmZy YXN0cnVjdHVyZWxlc3MgKGkuZS4gd2l0aG91dCBhbnkgaGllcmFyY2h5KSwgd2hpY2ggc2VlbXMg dG8gYmUgbm90IHRoZSBjYXNlIGluIG90aGVyIG5ldHdvcmsgdHlwZXMgdGhlIGRyYWZ0IGRlc2Ny aWJlcyBhbmQgbWFrZXMgbmV0d29yayBtYW5hZ2VtZW50IGVzc2VudGlhbGx5IGRpZmZlcmVudC48 L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+SWYgd2UgZXhjbHVkZSBNQU5FVHMsIEknZCBsaWtlIHRvIHVuZGVyc3RhbmQgd2h5IHdl IGRvbid0IGV4Y2x1ZGUgbWVzaCBuZXR3b3JrcyBvciBBTUlzLiBJIGRvbid0IHNlZSBhIG1ham9y IGRpZmZlcmVuY2UgaW4gdGhlc2UgbmV0d29ya3MgKGFuZCBJIGhhdmUgc3R1ZGllZCB0aGVtIGZv ciBhIHdoaWxlKS4gTUFORVRzIG1heSBiZSBpbmZyYXN0cnVjdHVyZWxlc3MsIHllcywgYnV0IHNv IG1heSBiZSBtZXNoIG5ldHdvcmtzLiBJbiBib3RoIGNhc2VzLCB0aGVyZSBtYXkgYmUgYSBnYXRl d2F5IHRvIG90aGVyIG5ldHdvcmtzIChJbnRlcm5ldCkuIFNhbWUgZm9yIEFNSXMuIEFsc28sIGRp c3RyaWJ1dGVkIG1hbmFnZW1lbnQgaXMgbWVudGlvbmVkIGluIHRoZSBkcmFmdCwgc28gSSBhbSBz dGlsbCB1bmNsZWFyIHdoYXQgcGFydGljdWxhcml0aWVzIG9mIE1BTkVUcyBtYWtlIHRoZW0gc28g ZGlmZmVyZW50LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGJyPjxvOnA+ PC9vOnA+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 MTUuNzVwdCc+RXZlbiB0aGUgZGVmaW5pdGlvbiBvZiBDTjEgaXMsIElNTywgZW50aXJlbHkgYSBN QU5FVDsgeW91IGV2ZW4gbWVudGlvbiBNZXNoIG5ldHdvcmtzLCB3aGljaCBhcmUgbm90aGluZyBl bHNlIHRoYW4gTUFORVRzIChvbmx5IGRpZmZlcmVuY2UgaXMgdGhhdCByb3V0ZXJzIGFyZSB1c3Vh bGx5IG5vbi1tb2JpbGU7IG5ldmVydGhlbGVzcywgdGhlIHRvcG9sb2d5IGlzIHN0aWxsIGR5bmFt aWMgYmVjYXVzZSBvZiBmbHVjdHVhdGluZyBsaW5rcy4pLiA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjE1Ljc1cHQnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1 ZSc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWxlZnQ6MTUuNzVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5bTUVdOiBUaGVyZSBtaWdo dCBiZSBzaW1pbGFyaXRpZXMgYmV0d2VlbiBhIE1BTkVUIGFuZCBhIE1lc2ggbmV0d29yaywgaG93 ZXZlciB0aGV5IGFyZSBub3QgdGhlIHNhbWUgdGhpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDo1LjI1cHQnPlRoZW4gdGVsbCBtZSB0aGUgZGlmZmVyZW5jZS48bzpwPjwvbzpwPjwvcD48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjUuMjVwdCc+PGJyPjxicj48 bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTUuNzVw dCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJz YW5zLXNlcmlmIjtjb2xvcjpibHVlJz5JIGhhdmUgdG8gYWRtaXQgd2UgZG9u4oCZdCBjb25jZWl2 ZSBzdWZmaWNpZW50bHkgdGhlIHNwZWNpYWwgTUFORVQgdXNlIGNhc2VzIGZvciBmcmVxdWVudCBt b3ZlbWVudCBvZiByb3V0aW5nIGRldmljZXMgd2l0aG91dCBpbmZyYXN0cnVjdHVyZS48L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9 J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQnPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MzYuMHB0O21hcmdp bi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6NTEuNzVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5J ZiB3ZSBhZ3JlZSB0aGF0IGEgTWVzaCBuZXR3b3JrIGNvdmVycyB0aGUgZXNzZW50aWFsIHBhcnQg b2YgYSBNQU5FVCB0aGVuIEkgd291bGQgc3VnZ2VzdCB0byBmb2N1cyBvbiBhIE1lc2ggbmV0d29y ayBpbnN0ZWFkIG9mIHRyeWluZyB0byBjb3ZlciBldmVyeXRoaW5nLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0OjUuMjVwdCc+QnV0IHdoeT8gSSBkb24ndCBzZWUgYW55IG1h am9yIGRpZmZlcmVuY2UgKG90aGVyIHRoYW4gbW9iaWxpdHkpPG86cD48L286cD48L3A+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo1LjI1cHQnPjxicj48YnI+PG86 cD48L286cD48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjE1Ljc1cHQn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fu cy1zZXJpZiI7Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTUuNzVwdCc+SXMgdGhlIGludGVudGlvbiB0 byBmb2N1cyBvbiBub24tbW9iaWxlIGRldmljZXM/PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxNS43NXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0OjE1Ljc1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+W01FXTogVGhlcmUgaXMgbm8gaW50 ZW50aW9uIHRvIGV4Y2x1ZGUgbm9uLW1vYmlsZSBkZXZpY2VzLiBUaGUgZHJhZnQgY3VycmVudGx5 IGFzc3VtZXMgdGhhdCwgZnJvbSB0aGUg4oCcbmV0d29yayBtYW5hZ2VtZW504oCdIHBvdi4sIGJv dGggbW9iaWxlIGFuZCBub24tbW9iaWxlIGRldmljZXMgaGF2ZSBzaW1pbGFyIGNoYXJhY3Rlcmlz dGljcyAoSSB0aGluayB3ZSBzaG91bGQgZGVzY3JpYmUgdGhpcyBzb21ld2hlcmUpLiBUaGUgZHJh ZnQgZnVydGhlciBhc3N1bWVzIHRoYXQgdGhlIG1hbmFnaW5nIGVudGl0eSBpcyBub3QgbW92aW5n Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6NS4yNXB0Jz5XaHkgZG9lcyBpdCBtYXR0ZXIgaWYg dGhlIG1hbmFnaW5nIGVudGl0eSBtb3Zlcz8gSXQncyBhbGwgYWJvdXQgdGhlIGR5bmFtaWMgdG9w b2xvZ3ksIHNvIGF0IGFueSB0aW1lIHRoZSBwYXRoIGJldHdlZW4gYW55IG5vZGUgYW5kIHRoZSBO TVMgY2FuIGJyZWFrLi4gQW5kIGlmIHRoZSBub2RlcyBjYW4gbW92ZSwgdGhleSBjYW4gbW92ZSBh d2F5IGZyb20gdGhlIE5NUyBhbnl3YXkgKHNvIHRoZSBjb25uZWN0aW9uIGlzIGludGVycnVwdGVk KTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6NS4yNXB0Jz48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Jz48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDoxNS43NXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjE1Ljc1 cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwi c2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+SSBtaWdodCBiZSB3cm9uZyBpbiB0aGlzLiBQbGVhc2Ug ZGVzY3JpYmUgd2hpY2ggbW9iaWxpdHkgYXNwZWN0cyB5b3UgdGhpbmsgc2hvdWxkIGJlIGNvdmVy ZWQgZnJvbSDigJxuZXR3b3JrIG1hbmFnZW1lbnTigJ0gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDo1LjI1cHQnPkkgdGhpbmsgd2Ugc2hvdWxkIGNvdmVyIGR5bmFtaWMgdG9wb2xvZ2llcyB3aGVy ZSBsaW5rcyBjYW4gZnJlcXVlbnRseSBnbyB1cCBvciBkb3duLCBhcmUgYXN5bW1ldHJpYyBhbmQg b2YgbG93IGNhcGFjaXR5LiBUaGF0IGNhbiBiZSBkdWUgdG8gbW9iaWxpdHksIG9yIGR1ZSB0byBv dGhlciBmYWN0b3JzIHN1Y2ggYXMgdmVyeSBmbGFreSBsaW5rcy48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjUuMjVwdCc+PGJyPjxicj48bzpwPjwv bzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTUuNzVwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNl cmlmIjtjb2xvcjpibHVlJz5wb3YuIE1hbmFnaW5nIHRoZSBJUCBtb2JpbGl0eSBpdHNlbGYsIGUu Zy4gdGhlIElQIGFkZHJlc3MgZXRjLiwgaXMgbm90IG5ldHdvcmsgbWFuYWdlbWVudCBwZXIgc2Uu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo1LjI1cHQnPkkgYWdyZWUuIEknZCBjYWxsIHRoYXQg YXV0b2NvbmZpZ3VyYXRpb24uPG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDo1LjI1cHQnPjxicj48YnI+PG86cD48L286cD48L3A+PGRpdj48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjE1Ljc1cHQnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1 ZSc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxNS43NXB0Jz5Db25zdHJhaW5lZCBuZXR3b3JrcyBhcmUg bW9yZSBkaWZmaWN1bHQgdG8gZGVmaW5lLCBhcyB0aGVyZSBhcmUgc2V2ZXJhbCBhc3BlY3RzOiBi YW5kd2lkdGgsIGxvc3MgcmF0ZXMgb2YgdGhlIGNoYW5uZWwsIE1UVSwgdG9wb2xvZ3ksIGV0Yy4g SSB0aGluayB0aGF0IHdlIG5lZWQgbW9yZSBkaXNjdXNzaW9uIChidXQgbWF5YmUgYWZ0ZXIgYSBC T0YgaGFzIGJlZW4gaW5pdGlhdGVkPyk8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0OjE1Ljc1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 MTUuNzVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRh bmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5bTUVdOiBXZSBjYW4gc3RhcnQgc3VjaCBhIGRp c2N1c3Npb24gYWxyZWFkeSB0b2RheS4gSG93ZXZlciwgSSBhc3N1bWUgaXQgaXMgbW9zdGx5IGZv bGxvd2luZyB0aGUgY2FwYWJpbGl0aWVzIGFuZCBsaW1pdGF0aW9ucyBvZiB0aGUgd2lyZWxlc3Mg dGVjaG5vbG9neS4gV2hhdCB3b3VsZCBiZSB5b3VyIHByb3Bvc2FsIGZvciBhIGNsYXNzaWZpY2F0 aW9uIG9mIGNvbnN0cmFpbmVkIG5ldHdvcmtzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6NS4y NXB0Jz5UaGF0IGlzIGEgZ29vZCBxdWVzdGlvbi4uLiBJJ2xsIHRoaW5rIGFib3V0IGl0LCBhbmQg d2UgY2FuIGRpc2N1c3MgdGhhdCBpbiBBdGxhbnRhLiAoSSBrbm93LCBpdCdzIGVhc3kgdG8gY3Jp dGljaXplLCBidXQgaGFyZCB0byBiZSBjb25zdHJ1Y3RpdmUgOy0pPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo1LjI1cHQnPjxicj48YnI+PG86cD48 L286cD48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjE1Ljc1cHQnPiZu YnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tbGVmdDoxNS43NXB0Jz4tIFNlY3Rpb24gMS41OiAoTmV0d29yayBUb3BvbG9neSBPcHRp b25zKTogSSB0aGluayB0aGVyZSBpcyBhIG1peCBiZXR3ZWVuIHRoZSB0b3BvbG9neSAoaS5lLiwg dGhlIGdyYXBoIHRoYXQgcmVwcmVzZW50cyByb3V0ZXJzIGFuZCBjb21tdW5pY2F0aW9uIGxpbmtz KSwgdHJhZmZpYyBmbG93cyAod2hpY2ggZGV2aWNlcyBjb21tdW5pY2F0ZSB3aXRoIHdoaWNoIG90 aGVyIGRldmljZXMpLCBhbmQgYXBwbGljYXRpb24gbGF5ZXIgKHByb3hpZXMgYW5kIE5NUykuPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0OjE1Ljc1cHQnPi0gU2VjdGlvbiAxLjY6IEkgbGlrZSB0aGF0LjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxNS43NXB0Jz4m bmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWxlZnQ6MTUuNzVwdCc+LSBTZWN0aW9uIDEuNzogVGhlcmUgaXMgbWl4dHVyZSBvZiBj b25zdHJhaW5lZCBuZXR3b3JrcyAoZmlyc3QgYnVsbGV0KTsgSSB0aG91Z2h0IHRoYXQgY29uc3Ry YWluZWQgZGV2aWNlcyBvbmx5IG1lYW5zIHRoYXQgdGhleSBoYXZlIGxpdHRsZSBDUFUgcG93ZXIg YW5kIG1lbW9yeS4gQ2FuJ3QgdGhhdCBkZXZpY2Ugc3RpbGwgdXNlIGNhYmxlIGNvbm5lY3Rpdml0 eSAoaS5lLiB1bmNvbnN0cmFpbmVkIG5ldHdvcmspPyBPciBpcyBpdCBuZWNlc3NhcmlseSBsaW5r ZWQ/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0OjE1Ljc1cHQnPkkgYW0gdW5jbGVhciBhYm91dCB0aGUgcHVycG9zZSBvZiB0aGlz IHdob2xlIHNlY3Rpb24uIFdoYXQgZG9lcyBpdCBzZXJ2ZSBmb3I/PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjE1Ljc1cHQnPjxz cGFuIHN0eWxlPSdjb2xvcjpibHVlJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxNS43NXB0Jz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs dWUnPltNRV06IFNlY3Rpb24gMS43IGluIGdlbmVyYWwgdHJpZXMgdG8gbGlzdCBhbmQgZGlzY3Vz cyB0aGUgaXNzdWVzIGEgY29uc3RyYWluZWQgZGV2aWNlIG1pZ2h0IGhhdmUgYW5kIGhvdyB0aGVz ZSBpc3N1ZXMgaW5mbHVlbmNlIHRoZSBtYW5hZ2VtZW50IG9mIHN1Y2ggYSBkZXZpY2UuIEFzIGRl c2NyaWJlZCBpbiBzZWN0aW9uIDEuNCBhbmQgMi4gd2UgaW5jbHVkZSBub24tY29uc3RyYWluZWQg bmV0d29ya3Mgd2l0aCBjb25zdHJhaW5lZCBkZXZpY2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjE1Ljc1cHQnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29s b3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxNS43NXB0Jz4tIFNlY3Rpb24gMjogSSB0aGlu ayB0aGF0IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpcyBub3QgcXVpdGUgY2xlYXIgeWV0LiBJdCBp cyBoYXJkIHRvIGlkZW50aWZ5IHdoYXQgdGhlIHByb2JsZW1zIGFyZTsgdGhlcmUgYXJlIHNvIG1h bnkgdXNlZnVsIHJlcXVpcmVtZW50cyBpbiBzZWN0aW9uIDQsIHNvIG1heWJlIGl0IGNvdWxkIGJl IGJldHRlciBtYXRjaGVkIHRvIHRoZXNlIHJlcXVpcmVtZW50cy4gSXQgd291bGQgYmUgbmljZSB0 byByZWFkIHNlY3Rpb24gNCwgYW5kIHRoZW4gc2F5ICZxdW90O2FoLCByZXF1aXJlbWVudCB4IGlu ZGVlZCBsb2dpY2FsbHkgZm9sbG93cyBmcm9tIHRoZSBwcm9ibGVtIHkgdGhhdCBoYXMgYmVlbiBk ZXNjcmliZWQgaW4gc2VjdGlvbiAyJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTUuNzVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDoxNS43NXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPltNRV06IEkgYWdyZWUgdGhlIHByb2Js ZW0gc3RhdGVtZW50IGluIHNlY3Rpb24gMiAod2hpY2ggSSBkaWRu4oCZdCBoYXZlIHRpbWUgdG8g dXBkYXRlIHlldCkgY291bGQgYmVuZWZpdCBmcm9tIGEgcmV2aXNpb24gYWxpZ25pbmcgaXQgd2l0 aCB0aGUgbmV3IHNlY3Rpb25zIDEuNyBhbmQgc2VjdGlvbiA0Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTUuNzVw dCc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0OjE1Ljc1cHQnPi0gU2VjdGlvbiAzOiBJIGxpa2UgdGhlIGRpdmVyc2Ug dXNlIGNhc2VzLiBUaGF0IGNhbiBiZSB2ZXJ5IHVzZWZ1bCB0byBpZGVudGlmeSBkaWZmZXJlbnQg cmVxdWlyZW1lbnRzIGFuZCBwcm9ibGVtcy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTUuNzVwdCc+Jm5ic3A7PG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjE1 Ljc1cHQnPi0gU2VjdGlvbiA0OiBJIHZlcnkgbXVjaCBhcHByZWNpYXRlIHRoZSBlbm9ybW91cyBl ZmZvcnQgZm9yIGdhdGhlcmluZyB0aGUgcmVxdWlyZW1lbnRzLiBUaGVyZSB3aWxsIGJlIGRldGFp bGVkIGRpc2N1c3Npb25zIGFib3V0IHRoZW0gKGhvcGVmdWxseSksIGJ1dCB0aGlzIGlzIGEgdmVy eSBnb29kIGxpc3QgdG8gc3RhcnQgZnJvbS4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTUuNzVwdCc+V2UgaGF2ZSB0 byBkZWZpbmUgaWYgdGhlIHNlY3VyaXR5IHJlbGF0ZWQgcmVxdWlyZW1lbnRzIGFsc28gZml0IGlu IHRoaXMgZGlzY3Vzc2lvbiwgb3IgYmV0dGVyIHNvbWUgcGxhY2UgZWxzZSAoU09MQUNFPykuJm5i c3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDox NS43NXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFu YSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjE1Ljc1cHQnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29s b3I6Ymx1ZSc+W01FXTogV2Ugc2VlIGF1dGhlbnRpY2F0aW9uIGFuZCBhY2Nlc3MgY29udHJvbCAo dG8gdGhlIGV4dGVuZCBpdCBtYXR0ZXJzKSBhcyBwYXJ0IG9mIG5ldHdvcmsgbWFuYWdlbWVudC4g VGhpcyBpcyBwcm9iYWJseSB0aGUgcGFydCB3aGVyZSBDb21hbiBhbmQgU29sYWNlIGNhbiBwcm9m aXQgZnJvbSBhbmQgY29tcGxlbWVudCBlYWNoIG90aGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6NS4yNXB0Jz5JdCBhbHNvIGRlcGVuZHMgd2hlcmUgU09MQUNFIGlzIGdvaW5nLiZuYnNwOzxv OnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 NS4yNXB0Jz48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Jz48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tbGVmdDoxNS43NXB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTUuNzVwdCc+QWdhaW4sIEkgYXBwcmVj aWF0ZSB0aGUgZWZmb3J0IG9mIHRoZSBhdXRob3JzLCBhbmQgaG9wZSB0aGF0IHdlIGNhbiBjb250 aW51ZSB0aGUgZGlzY3Vzc2lvbnMgaW4gQXRsYW50YS4gSSBhcG9sb2dpemUgdGhhdCBJIG9ubHkg cHJvdmlkZWQgdGhpcyBoaWdoLWxldmVsIHJldmlldywgYnV0IHRoZSBsYXN0IHdlZWtzIHdlcmUg dmVyeSBidXN5IGZvciBtZS4gSWYgeW91IG5lZWQgaGVscCBhdXRob3JpbmcgdGhlIGRvY3VtZW50 cyBvbmNlIHRoZXkgYXJlIHNwbGl0IHVwLCBJIGNvdWxkIGhlbHAgb3V0LjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxNS43NXB0 Jz48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxNS43NXB0Jz5J cyB0aGVyZSBhIG1lZXRpbmcgYWxyZWFkeSBwbGFubmVkPyZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxNS43NXB0Jz48 c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTUuNzVwdCc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bHVlJz5bTUVdOiBZZXMsIHRoZXJlIHdpbGwgYmUgYSBtZWV0aW5nIG9uIFRodXJzZGF5LiBJIHdh bnRlZCB0byBhbm5vdW5jZSBpdCBvbmNlIHRoZSByb29tIGlzIGtub3duLiBTdGF5IHR1bmVkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6NS4yNXB0Jz5UaGFua3MuIExvb2tpbmcgZm9yd2FyZCB0 byBtb3JlIGRpc2N1c3Npb25zLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDo1LjI1cHQnPkJlc3Q8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6NS4yNXB0Jz5VbHJpY2g8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjUuMjVwdCc+ PGJyPjxicj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6MTUuNzVwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZl cmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjE1Ljc1 cHQnPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoxNS43NXB0Jz5VbHJpY2gmbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjE1 Ljc1cHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDoxNS43NXB0Jz5PbiBXZWQsIE9jdCAxNywgMjAxMiBhdCAxOjE3IEFNLCBF cnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpICZsdDs8YSBocmVmPSJtYWlsdG86bWVobWV0 LmVyc3VlQG5zbi5jb20iIHRhcmdldD0iX2JsYW5rIj5tZWhtZXQuZXJzdWVAbnNuLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6MTUuNzVwdCc+SGkgQWxsLDxicj48YnI+d2Ugc3VibWl0dGVkIGFuIHVwZGF0ZSBmb3Ig dGhlIGNvbnN0cmFpbmVkLW1nbXQgZHJhZnQgb24gdGhlICZxdW90O01hbmFnZW1lbnQ8YnI+b2Yg TmV0d29ya3Mgd2l0aCBDb25zdHJhaW5lZCBEZXZpY2VzOiBVc2UgQ2FzZXMgYW5kIFJlcXVpcmVt ZW50cyZxdW90Oy4gVGhlPGJyPmRyYWZ0IGhvcGVmdWxseSBhZGRyZXNzZXMgbW9zdCBvZiB0aGUg aXNzdWVzIHdlIGRpc2N1c3NlZCBpbiB0aGUgbGFzdDxicj5tZWV0aW5nLjxicj48YnI+SSB0aGlu ayBpdCBpcyBhbHJlYWR5IHRpbWUgdG8gc3BsaXQgdGhlIGRyYWZ0IGludG8gdGhyZWU7IGUuZy4g cHJvYmxlbTxicj5zdGF0ZW1lbnQsIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzLiBCdXQgdGhp cyBjYW4gYmUgZG9uZSBhZnRlcjxicj5nZXR0aW5nIHlvdXIgZmVlZGJhY2sgYmVmb3JlIGFuZCBk dXJpbmcgSUVURiA4NS48YnI+PGJyPkkgd291bGQgaGlnaGx5IGFwcHJlY2lhdGUgeW91ciBjb21t ZW50cyBhbmQgYW55IGtpbmQgb2YgZGlzY3Vzc2lvbiBvbjxicj50aGUgZHJhZnQgY29udGVudCBl c3BlY2lhbGx5IG9uIHRoZSByZXF1aXJlbWVudHMgc2VjdGlvbi4gVGhhbmsgeW91Ljxicj48YnI+ Q2hlZXJzLDxicj5NZWhtZXQ8YnI+PGJyPjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj5Gcm9tOiBleHQgPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dPGJyPlNlbnQ6 IE1vbmRheSwgT2N0b2JlciAxNSwgMjAxMiA5OjU5IFBNPGJyPlRvOiBFcnN1ZSwgTWVobWV0IChO U04gLSBERS9NdW5pY2gpPGJyPkNjOiA8YSBocmVmPSJtYWlsdG86ZHJvbWFzY2FAYXZheWEuY29t Ij5kcm9tYXNjYUBhdmF5YS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlIj5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU8L2E+PGJyPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I8YnI+ZHJhZnQt ZXJzdWUtY29uc3RyYWluZWQtbWdtdC0wMi50eHQ8YnI+PGJyPjxicj5BIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtZXJzdWUtY29uc3RyYWluZWQtbWdtdC0wMi50eHQ8YnI+aGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNZWhtZXQgRXJzdWUgYW5kIHBvc3RlZCB0byB0aGU8YnI+ SUVURiByZXBvc2l0b3J5Ljxicj48YnI+RmlsZW5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2RyYWZ0LWVyc3VlLWNvbnN0cmFpbmVkLW1nbXQ8YnI+UmV2aXNpb246ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzAyPGJyPlRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IE1hbmFnZW1lbnQgb2YgTmV0d29ya3Mgd2l0aCBDb25zdHJhaW5lZCBEZXZpY2VzOiBV c2U8YnI+Q2FzZXMgYW5kIFJlcXVpcmVtZW50czxicj5DcmVhdGlvbiBkYXRlOiAmbmJzcDsgMjAx Mi0xMC0xNTxicj5XRyBJRDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRp dmlkdWFsIFN1Ym1pc3Npb248YnI+TnVtYmVyIG9mIHBhZ2VzOiA3ODxicj5VUkw6PGJyPjxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWVyc3VlLWNvbnN0 cmFpbmVkLW1nbXQtMDIudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtZXJzdWUtY29uc3RyYWluZWQtbWdtdC0wMi50eHQ8L2E+PGJy PlN0YXR1czo8YnI+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1lcnN1ZS1jb25zdHJhaW5lZC1tZ210IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1lcnN1ZS1jb25zdHJhaW5lZC1tZ210PC9hPjxicj5IdG1s aXplZDo8YnI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZXJzdWUt Y29uc3RyYWluZWQtbWdtdC0wMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWVyc3VlLWNvbnN0cmFpbmVkLW1nbXQtMDI8L2E+PGJyPkRpZmY6PGJyPjxh IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWVyc3VlLWNvbnN0 cmFpbmVkLW1nbXQtMDIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1lcnN1ZS1jb25zdHJhaW5lZC1tZ210LTAyPC9hPjxicj48YnI+QWJzdHJh Y3Q6PGJyPiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IHJhaXNlcyB0aGUgcXVlc3Rpb25zIG9u IGFuZCBkaXNjdXNzZXMgdGhlIHVzZSBjYXNlcyBhbmQ8YnI+Jm5ic3A7ICZuYnNwO3JlcXVpcmVt ZW50cyBmb3IgdGhlIG1hbmFnZW1lbnQgb2YgbmV0d29ya3Mgd2l0aCBjb25zdHJhaW5lZCBkZXZp Y2VzLjxicj48YnI+PGJyPjxicj48YnI+PGJyPlRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPjxicj48 YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Y29t YW4gbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpjb21hbkBpZXRmLm9yZyI+Y29tYW5A aWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY29tYW4iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NvbWFuPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTUuNzVwdCc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_001_01CDB205.7A582528-- From ulrich@herberg.name Wed Oct 24 09:42:29 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 7EED521F8C81 for ; Wed, 24 Oct 2012 09:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W9CvAv1KcRR for ; Wed, 24 Oct 2012 09:42:22 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA9BB21F8C55 for ; Wed, 24 Oct 2012 09:42:21 -0700 (PDT) Received: by mail-gg0-f172.google.com with SMTP id i4so140866ggn.31 for ; Wed, 24 Oct 2012 09:42:21 -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=niUzFR5a69RlZfMGTGMbZKGIsdIzqs2cnqoUqdGSUsM=; b=cHo7uhP5wxT7N4DR5ESaMdisJnjAX7VzBiM5tbAND50txXs7fsjYx++58Np+WmqN1c VORsdmfKxuEKc2ECk1QMod/X7QnNCHfjMG+9PfuVmFtlFNkXvNrBLUtnFp62IQ6d648m ibuu+3cmPr41oDSknVOAf8gXxDubk94RnN2RE= 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=niUzFR5a69RlZfMGTGMbZKGIsdIzqs2cnqoUqdGSUsM=; b=I4pzl3ELaeXVGAo9pwbe+bAOzXa1RZ5A4bA0X76me5rS21qvSONgqJ+arl9b6faIB4 sK4AMGtKagTPn2S4qXtXvkVEncL4TEsM64Igb8KnBtMouGQudHW67a21p033ye7YyxlJ anf1IAyAlS4NP1HinLWCqKdGoFB3M2Cg/NVN/FSKnyxLTLsBSmKOqoBvGKX+xv96yx2a SEN5iiemDXQUYa5TEaQ3GHBQ/BtYg0HX+EIGavb8qSdNJqekkUzcRKYK8i/Zh0K54NRx yVqnAaVCRaCCY2qAY0gSLMiDU0WQ/qGd2/riW9qOABeRNYQ3MJtwcL4a1ssTCkPkn8LH JKKg== MIME-Version: 1.0 Received: by 10.58.249.201 with SMTP id yw9mr30359229vec.10.1351096941194; Wed, 24 Oct 2012 09:42:21 -0700 (PDT) Received: by 10.58.94.103 with HTTP; Wed, 24 Oct 2012 09:42:21 -0700 (PDT) In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640455E288@DEMUEXC006.nsn-intra.net> References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A640455DA5B@DEMUEXC006.nsn-intra.net> <7044BCBB-99B9-4906-95FB-B1509FED1E56@herberg.name> <80A0822C5E9A4440A5117C2F4CD36A640455E288@DEMUEXC006.nsn-intra.net> Date: Wed, 24 Oct 2012 09:42:21 -0700 Message-ID: From: Ulrich Herberg To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=047d7bacc07e3cae5104ccd0c594 X-Gm-Message-State: ALoCoQmy+4/H0MXMzYfVPQA0XbcHnClnD9yQlBThIwsVht6R2GNBJ+hfwRTfiGDnfGumHDXzQd78 Cc: coman@ietf.org Subject: Re: [coman] [OPSAWG] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt 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, 24 Oct 2012 16:42:29 -0000 --047d7bacc07e3cae5104ccd0c594 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mehmet On Wed, Oct 24, 2012 at 9:34 AM, Ersue, Mehmet (NSN - DE/Munich) < mehmet.ersue@nsn.com> wrote: > Hi Ulrich,**** > > ** ** > > O&M area guys usually don=92t have sufficient expertise on managing highl= y > dynamic networks without any hierarchy (possibly without any managing > entity). I would like to suggest to focus for the time being on mesh > networks where we assume a known hierarchy and infrastructure. > In that case, I suggest to clarify the text on the constrained networks. Since I was confused by the difference of what you meant by MANET vs mesh-network in the draft, other people may also be confused. What you wrote in this email makes that clearer. I will try to come up with a text in the section of constrained networks; but I won't come up with something before this IETF. > **** > > ** ** > > Though, as we were discussing earlier, I would find it very useful to hav= e > a draft addressing especially the management of MANET-type of networks. I= f > we once have to prepare a charter proposal such a draft would be very > helpful to round it off and would quite likely lead to a work item. > Agreed. > **** > > ** ** > > Let=92s discuss this topic also at IETF (I am going to arrive on Friday). > Great, I'll arrive on Saturday evening. See you there! Ulrich > **** > > ** ** > > Cheers, > Mehmet**** > > ** ** > > ** ** > > *From:* ext Ulrich Herberg [mailto:ulrich@herberg.name] > > *Sent:* Tuesday, October 23, 2012 5:46 AM > > *To:* Ersue, Mehmet (NSN - DE/Munich) > *Cc:* > *Subject:* Re: [OPSAWG] [coman] FW: New Version Notification > fordraft-ersue-constrained-mgmt-02.txt**** > > ** ** > > Hi Mehmet,**** > > ** ** > > thanks for your reply. See below: > > On Oct 22, 2012, at 7:19, "Ersue, Mehmet (NSN - DE/Munich)" < > mehmet.ersue@nsn.com> wrote:**** > > > [ME]: There is no intention to exclude non-mobile devices.**** > > **** > > s/non-mobile/mobile/**** > > **** > > Cheers, > Mehmet **** > > **** > > *From:* opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] > *On Behalf Of *Ersue, Mehmet (NSN - DE/Munich) > *Sent:* Monday, October 22, 2012 12:55 PM > *To:* ext Ulrich Herberg; Carsten Bormann > *Cc:* coman@ietf.org; opsawg@ietf.org > *Subject:* Re: [OPSAWG] [coman] FW: New Version Notification > fordraft-ersue-constrained-mgmt-02.txt**** > > **** > > Hi Ulrich,**** > > **** > > see my comments below.**** > > **** > > Cheers, > Mehmet **** > > **** > > *From:* ext Ulrich Herberg [mailto:ulrich@herberg.name] > > *Sent:* Saturday, October 20, 2012 1:46 AM > *To:* Ersue, Mehmet (NSN - DE/Munich) > *Cc:* coman@ietf.org; opsawg@ietf.org > *Subject:* Re: [coman] FW: New Version Notification for > draft-ersue-constrained-mgmt-02.txt**** > > **** > > Hi Mehmet,**** > > **** > > thank you for updating the draft. There is a huge amount of great work in > it, and I think this will provide a great basis for further discussions. > Indeed, splitting up the document would be required at some point.**** > > **** > > Some high-level comments:**** > > - Section 1.2 (Terminology): The definition of MANET and Intermediate > entity (in COAP) come a bit surprising, since there has been no discussio= n > before. Also, it seems inconsistent to define MANET, but not all the othe= r > use cases, such as AMI.**** > > **** > > [ME]: The terminology section is incomplete and should be extended e.g. > with AMI.**** > > ** ** > > okay**** > > > > **** > > **** > > - Section 1.3 (Constrained Device Classes): I know that this definition > is taken from Lwig, but I doubt that it is of much use. The absolute valu= es > will change. While now there are still many C0 devices out, in five years= , > they will not exist (or rather, the number 10KB would need to be replaced > by a larger number). I think I would prefer a classification based on the > capabilities (e.g. can support full IP stack, or not)**** > > **** > > [ME]: The definition was actually first introduced by Carsten in the Smar= t > Object workshop before IETF 80 in Prague. This is an important point. See > my other mail.**** > > ** ** > > Right, I understood that.**** > > ** ** > > > > **** > > **** > > - Section 1.4 (constrained networks): I don't think this is a very > consistent classification of networks. First, CN0 seems to be the least > constrained network, whereas C0 devices are the most constrained. I would > suggest the remain the same ordering (0 the most constrained up to a > positive number).**** > > **** > > [ME]: The =930=94 in CN0 and C0 don=92t relate to each other. The > constrainedness of a network is mostly dependent on the wireless technolo= gy > used. I found it more useful to differentiate the type of the network, > where the wireless technology can be manifold.**** > > **** > > More importantly, there is a mixture with constrained devices in this > definition. Since we talk about the network only, we should only talk abo= ut > topology, lossy links, multi-hop, mobility etc. but not constrained > devices. **** > > **** > > [ME]: I agree, we should talk here on devices only.**** > > **** > > I don't understand why MANETs are not supported. Several of the use cases= , > such as the military use case, community networks and AMI are multi-hop > networks with dynamic topology and lossy links. That is what I call a > MANET. **** > > **** > > [ME]: The agreement in our last f2f meeting was that we want to include > the MANET use case to highlight what it is but exclude from the > requirements discussion. The reason is that MANETs can be based on very > distinct scenarios and have specifics which are unique compared to other > networks. The essential point is that MANETs are infrastructureless (i.e. > without any hierarchy), which seems to be not the case in other network > types the draft describes and makes network management essentially > different.**** > > ** ** > > If we exclude MANETs, I'd like to understand why we don't exclude mesh > networks or AMIs. I don't see a major difference in these networks (and I > have studied them for a while). MANETs may be infrastructureless, yes, bu= t > so may be mesh networks. In both cases, there may be a gateway to other > networks (Internet). Same for AMIs. Also, distributed management is > mentioned in the draft, so I am still unclear what particularities of > MANETs make them so different.**** > > ** ** > > > > **** > > **** > > Even the definition of CN1 is, IMO, entirely a MANET; you even mention > Mesh networks, which are nothing else than MANETs (only difference is tha= t > routers are usually non-mobile; nevertheless, the topology is still dynam= ic > because of fluctuating links.). **** > > **** > > [ME]: There might be similarities between a MANET and a Mesh network, > however they are not the same thing.**** > > ** ** > > Then tell me the difference.**** > > > > **** > > I have to admit we don=92t conceive sufficiently the special MANET use ca= ses > for frequent movement of routing devices without infrastructure.**** > > If we agree that a Mesh network covers the essential part of a MANET then > I would suggest to focus on a Mesh network instead of trying to cover > everything.**** > > ** ** > > But why? I don't see any major difference (other than mobility)**** > > > > **** > > **** > > Is the intention to focus on non-mobile devices?**** > > **** > > [ME]: There is no intention to exclude non-mobile devices. The draft > currently assumes that, from the =93network management=94 pov., both mobi= le and > non-mobile devices have similar characteristics (I think we should descri= be > this somewhere). The draft further assumes that the managing entity is no= t > moving.**** > > ** ** > > Why does it matter if the managing entity moves? It's all about the > dynamic topology, so at any time the path between any node and the NMS ca= n > break.. And if the nodes can move, they can move away from the NMS anyway > (so the connection is interrupted)**** > > > > **** > > **** > > I might be wrong in this. Please describe which mobility aspects you thin= k > should be covered from =93network management=94 **** > > ** ** > > I think we should cover dynamic topologies where links can frequently go > up or down, are asymmetric and of low capacity. That can be due to > mobility, or due to other factors such as very flaky links.**** > > ** ** > > > > **** > > pov. Managing the IP mobility itself, e.g. the IP address etc., is not > network management per se.**** > > ** ** > > I agree. I'd call that autoconfiguration.**** > > > > **** > > **** > > Constrained networks are more difficult to define, as there are several > aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I thin= k > that we need more discussion (but maybe after a BOF has been initiated?)*= * > ** > > **** > > [ME]: We can start such a discussion already today. However, I assume it > is mostly following the capabilities and limitations of the wireless > technology. What would be your proposal for a classification of constrain= ed > networks?**** > > ** ** > > That is a good question... I'll think about it, and we can discuss that i= n > Atlanta. (I know, it's easy to criticize, but hard to be constructive ;-)= * > *** > > ** ** > > > > **** > > **** > > - Section 1.5: (Network Topology Options): I think there is a mix between > the topology (i.e., the graph that represents routers and communication > links), traffic flows (which devices communicate with which other devices= ), > and application layer (proxies and NMS).**** > > - Section 1.6: I like that.**** > > **** > > - Section 1.7: There is mixture of constrained networks (first bullet); I > thought that constrained devices only means that they have little CPU pow= er > and memory. Can't that device still use cable connectivity (i.e. > unconstrained network)? Or is it necessarily linked?**** > > I am unclear about the purpose of this whole section. What does it serve > for?**** > > **** > > [ME]: Section 1.7 in general tries to list and discuss the issues a > constrained device might have and how these issues influence the manageme= nt > of such a device. As described in section 1.4 and 2. we include > non-constrained networks with constrained devices.**** > > **** > > - Section 2: I think that the problem statement is not quite clear yet. I= t > is hard to identify what the problems are; there are so many useful > requirements in section 4, so maybe it could be better matched to these > requirements. It would be nice to read section 4, and then say "ah, > requirement x indeed logically follows from the problem y that has been > described in section 2".**** > > **** > > [ME]: I agree the problem statement in section 2 (which I didn=92t have t= ime > to update yet) could benefit from a revision aligning it with the new > sections 1.7 and section 4.**** > > **** > > - Section 3: I like the diverse use cases. That can be very useful to > identify different requirements and problems.**** > > **** > > - Section 4: I very much appreciate the enormous effort for gathering the > requirements. There will be detailed discussions about them (hopefully), > but this is a very good list to start from. **** > > We have to define if the security related requirements also fit in this > discussion, or better some place else (SOLACE?). **** > > **** > > [ME]: We see authentication and access control (to the extend it matters) > as part of network management. This is probably the part where Coman and > Solace can profit from and complement each other.**** > > ** ** > > It also depends where SOLACE is going. **** > > > > **** > > **** > > Again, I appreciate the effort of the authors, and hope that we can > continue the discussions in Atlanta. I apologize that I only provided thi= s > high-level review, but the last weeks were very busy for me. If you need > help authoring the documents once they are split up, I could help out.***= * > > **** > > Is there a meeting already planned? **** > > **** > > [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it > once the room is known. Stay tuned.**** > > ** ** > > Thanks. Looking forward to more discussions.**** > > ** ** > > Best**** > > Ulrich**** > > ** ** > > > > **** > > **** > > Best regards**** > > Ulrich **** > > **** > > On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) < > mehmet.ersue@nsn.com> wrote:**** > > Hi All, > > we submitted an update for the constrained-mgmt draft on the "Management > of Networks with Constrained Devices: Use Cases and Requirements". The > draft hopefully addresses most of the issues we discussed in the last > meeting. > > I think it is already time to split the draft into three; e.g. problem > statement, use cases and requirements. But this can be done after > getting your feedback before and during IETF 85. > > I would highly appreciate your comments and any kind of discussion on > the draft content especially on the requirements section. Thank you. > > Cheers, > Mehmet > > > -----Original Message----- > From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 15, 2012 9:59 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-02.txt > > > A new version of I-D, draft-ersue-constrained-mgmt-02.txt > has been successfully submitted by Mehmet Ersue and posted to the > IETF repository. > > Filename: draft-ersue-constrained-mgmt > Revision: 02 > Title: Management of Networks with Constrained Devices: Use > Cases and Requirements > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 78 > URL: > http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt > Status: > http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt > Htmlized: > http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrained-mgmt-02 > > Abstract: > This document raises the questions on and discusses the use cases and > requirements for the management of networks with constrained devices. > > > > > > The IETF Secretariat > > > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman**** > > **** > --047d7bacc07e3cae5104ccd0c594 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mehmet

On Wed, Oct 24, 2012 at 9:34 AM= , Ersue, Mehmet (NSN - DE/Munich) <mehmet.ersue@nsn.com> = wrote:

Hi Ulrich,

=A0

=

O&M area guys usually do= n=92t have sufficient expertise on managing highly dynamic networks without= any hierarchy (possibly without any managing entity). I would like to sugg= est to focus for the time being on mesh networks where we assume a known hi= erarchy and infrastructure.


In that case, I suggest to cla= rify the text on the constrained networks. Since I was confused by the diff= erence of what you meant by MANET vs mesh-network in the draft, other peopl= e may also be confused. What you wrote in this email makes that clearer. I = will try to come up with a text in the section of constrained networks; but= I won't come up with something before this IETF.
=A0

=A0

=

Though, as we were discussin= g earlier, I would find it very useful to have a draft addressing especiall= y the management of MANET-type of networks. If we once have to prepare a ch= arter proposal such a draft would be very helpful to round it off and would= quite likely lead to a work item.


Agreed.
=A0

=A0

Let=92s discuss this topic a= lso at IETF (I am going to arrive on Friday).


Great, I'll arrive on Saturday evening.=A0

See you there!
Ulrich
=A0

=A0

Cheers,
Mehmet

=A0

=A0

From: ext Ulrich Herberg [mailto:ulrich@herberg.name]
Sent: Tuesday, October 23, 2012 5:46 AM

=
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: <coman@ietf.org>
<= div>
Subject: Re: [OPSAWG] [coman] FW: New Version Noti= fication fordraft-ersue-constrained-mgmt-02.txt

=A0

Hi Mehmet,

=A0

thanks for your reply. See below:

On Oct 2= 2, 2012, at 7:19, "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com= > wrote:

> [ME]: There is no intention = to exclude non-mobile devices.

=A0

=

s/non-mobile/mobile/<= u>

=A0

=

Cheers,
Mehmet

=A0

From: opsawg-b= ounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Ersue, Mehme= t (NSN - DE/Munich)
Sent: Monday, October 22, 2012 12:55 PM
To: ext Ulrich Her= berg; Carsten Bormann
Cc: coman@ietf.org; opsawg@ietf.org
Subject: Re: [OPSAWG] [coman] FW: New Version Notification fordraft-= ersue-constrained-mgmt-02.txt

=A0

Hi Ulrich,

=A0

=

see my comments below.

=A0

=

Cheers,
Mehmet

=A0

=

From: ext Ulrich Herberg [mailto:ulrich@herberg.name]
Sent: Saturday, October 20, 2012 1:46 AM
To: Ersue, Mehmet= (NSN - DE/Munich)
Cc: coman@ietf.org; opsawg@ietf.org
Subject: Re: [coman] FW: New Version Notification for draft-ersue-co= nstrained-mgmt-02.txt

=A0

Hi Mehmet,<= /p>

=A0

thank you for updating the draft. There is a huge amount of great w= ork in it, and I think this will provide a great basis for further discussi= ons. Indeed, splitting up the document would be required at some point.<= /u>

=A0

Some high-level comments:

=A0 - Section 1.2 (Terminology): The definition of MANET a= nd Intermediate entity (in COAP) come a bit surprising, since there has bee= n no discussion before. Also, it seems inconsistent to define MANET, but no= t all the other use cases, such as AMI.

=A0<= /u>

[ME]: The term= inology section is incomplete and should be extended e.g. with AMI.<= u>

=A0=

okay



=A0

=A0 - Section 1.3 (Constrained Device Cla= sses): I know that this definition is taken from Lwig, but I doubt that it = is of much use. The absolute values will change. While now there are still = many C0 devices out, in five years, they will not exist (or rather, the num= ber 10KB would need to be replaced by a larger number). I think I would pre= fer a classification based on the capabilities (e.g. can support full IP st= ack, or not)

=A0<= /u>

[ME]: The defi= nition was actually first introduced by Carsten in the Smart Object worksho= p before IETF 80 in Prague. This is an important point. See my other mail.<= /span>

=A0

Right, I understood that.

=

=A0



=A0

=A0 - Section 1.4 (constrained networks):= I don't think this is a very consistent classification of networks. Fi= rst, CN0 seems to be the least constrained network, whereas C0 devices are = the most constrained. I would suggest the remain the same ordering (0 the m= ost constrained up to a positive number).

=A0

=

[ME]: The =930=94 in CN0 and= C0 don=92t relate to each other. The constrainedness of a network is mostl= y dependent on the wireless technology used. I found it more useful to diff= erentiate the type of the network, where the wireless technology can be man= ifold.

=A0

=

More importantly, there is a mixture with= constrained devices in this definition. Since we talk about the network on= ly, we should only talk about topology, lossy links, multi-hop, mobility et= c. but not constrained devices.=A0

=A0

=

[ME]: I agree, we should tal= k here on devices only.

=A0

=

I don't understand why MANETs are not= supported. Several of the use cases, such as the military use case, commun= ity networks and AMI are multi-hop networks with dynamic topology and lossy= links. That is what I call a MANET.

=A0

=

[ME]: The agreement in our l= ast f2f meeting was that we want to include the MANET use case to highlight= what it is but exclude from the requirements discussion. The reason is tha= t MANETs can be based on very distinct scenarios and have specifics which a= re unique compared to other networks. The essential point is that MANETs ar= e infrastructureless (i.e. without any hierarchy), which seems to be not th= e case in other network types the draft describes and makes network managem= ent essentially different.

=A0

If we exclude MANETs, I'd like to under= stand why we don't exclude mesh networks or AMIs. I don't see a maj= or difference in these networks (and I have studied them for a while). MANE= Ts may be infrastructureless, yes, but so may be mesh networks. In both cas= es, there may be a gateway to other networks (Internet). Same for AMIs. Als= o, distributed management is mentioned in the draft, so I am still unclear = what particularities of MANETs make them so different.

=A0



=A0

Even the definiti= on of CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which = are nothing else than MANETs (only difference is that routers are usually n= on-mobile; nevertheless, the topology is still dynamic because of fluctuati= ng links.).

[ME]: There might be similarities between a MANET a= nd a Mesh network, however they are not the same thing.

=A0

Then tell me t= he difference.



I have to admit we don=92t conceive sufficiently th= e special MANET use cases for frequent movement of routing devices without = infrastructure.

If we agree that a Mesh netw= ork covers the essential part of a MANET then I would suggest to focus on a= Mesh network instead of trying to cover everything.

=A0=

B= ut why? I don't see any major difference (other than mobility)



=A0

Is the intention to focus on non-mobile devices?

=A0

=A0

Why does it ma= tter if the managing entity moves? It's all about the dynamic topology,= so at any time the path between any node and the NMS can break.. And if th= e nodes can move, they can move away from the NMS anyway (so the connection= is interrupted)



=A0

I might be wrong in this. Please describe which mob= ility aspects you think should be covered from =93network management=94

=A0

I think we sho= uld cover dynamic topologies where links can frequently go up or down, are = asymmetric and of low capacity. That can be due to mobility, or due to othe= r factors such as very flaky links.

=A0



pov. Managing the IP mobility itself, e.g. the IP address etc., is n= ot network management per se.

=A0

I agree. I'= ;d call that autoconfiguration.



=A0

Constrained networks are more diff= icult to define, as there are several aspects: bandwidth, loss rates of the= channel, MTU, topology, etc. I think that we need more discussion (but may= be after a BOF has been initiated?)

[ME]: We can start such a discussion already today.= However, I assume it is mostly following the capabilities and limitations = of the wireless technology. What would be your proposal for a classificatio= n of constrained networks?

=A0

That is a good= question... I'll think about it, and we can discuss that in Atlanta. (= I know, it's easy to criticize, but hard to be constructive ;-)<= u>

=A0



=A0=

- Secti= on 1.5: (Network Topology Options): I think there is a mix between the topo= logy (i.e., the graph that represents routers and communication links), tra= ffic flows (which devices communicate with which other devices), and applic= ation layer (proxies and NMS).

- Section 1= .6: I like that.

=A0

- Section 1.7: There is mixture of constrained networks (first bullet); I t= hought that constrained devices only means that they have little CPU power = and memory. Can't that device still use cable connectivity (i.e. uncons= trained network)? Or is it necessarily linked?

I am unclea= r about the purpose of this whole section. What does it serve for?

=A0

- Section 2: I think that the problem statement is not quite clear yet. It = is hard to identify what the problems are; there are so many useful require= ments in section 4, so maybe it could be better matched to these requiremen= ts. It would be nice to read section 4, and then say "ah, requirement = x indeed logically follows from the problem y that has been described in se= ction 2".

[ME]: I agree the problem statement in section 2 (w= hich I didn=92t have time to update yet) could benefit from a revision alig= ning it with the new sections 1.7 and section 4.

=A0<= u>

-= Section 3: I like the diverse use cases. That can be very useful to identi= fy different requirements and problems.

=A0<= u>

-= Section 4: I very much appreciate the enormous effort for gathering the re= quirements. There will be detailed discussions about them (hopefully), but = this is a very good list to start from.=A0

We have to = define if the security related requirements also fit in this discussion, or= better some place else (SOLACE?).=A0

=A0

[ME]: We see authenti= cation and access control (to the extend it matters) as part of network man= agement. This is probably the part where Coman and Solace can profit from a= nd complement each other.

=A0

It also depend= s where SOLACE is going.=A0



=A0

Again, I appreciate the effort of the authors, and hope that we c= an continue the discussions in Atlanta. I apologize that I only provided th= is high-level review, but the last weeks were very busy for me. If you need= help authoring the documents once they are split up, I could help out.<= /u>

=A0

Is there a meeting already planned?=A0<= /u>

=A0

[ME]: Yes, there will be a me= eting on Thursday. I wanted to announce it once the room is known. Stay tun= ed.

=A0

Thanks. Lookin= g forward to more discussions.

=A0

Best

Ulrich

=A0



=A0

Best regards

Ulrich=A0

= =A0

On Wed, Oct 17, 2= 012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) <mehmet.ersue@nsn.com> wrote:

Hi All,

we subm= itted an update for the constrained-mgmt draft on the "Management
o= f Networks with Constrained Devices: Use Cases and Requirements". The<= br> draft hopefully addresses most of the issues we discussed in the last
me= eting.

I think it is already time to split the draft into three; e.g= . problem
statement, use cases and requirements. But this can be done af= ter
getting your feedback before and during IETF 85.

I would highly appr= eciate your comments and any kind of discussion on
the draft content esp= ecially on the requirements section. Thank you.

Cheers,
Mehmet

-----Original Message-----
From: ext internet-drafts@ietf.org [mailto:internet-drafts@= ietf.org]
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munic= h)
Cc: dromasca@= avaya.com; j.schoenwaelder@jacobs-university.de
Subject: New Version Notification for
draft-ersue-constrained-mgmt-02.tx= t


A new version of I-D, draft-ersue-constrained-mgmt-02.txt
h= as been successfully submitted by Mehmet Ersue and posted to the
IETF re= pository.

Filename: =A0 =A0 =A0 =A0draft-ersue-constrained-mgmt
Revision: =A0 = =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Management of Networks with Con= strained Devices: Use
Cases and Requirements
Creation date: =A0 2012-= 10-15
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 78
URL:
http://www.ietf.o= rg/internet-drafts/draft-ersue-constrained-mgmt-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt<= /a>
Htmlized:
http://tools.ietf.org/html/draft-ersue-constrain= ed-mgmt-02
Diff:
http://www.ietf.org/rfcdif= f?url2=3Ddraft-ersue-constrained-mgmt-02

Abstract:
=A0 =A0This document raises the questions on and discusses= the use cases and
=A0 =A0requirements for the management of networks wi= th constrained devices.





The IETF Secretariat

=
_______________________________________________
coman mailing list
coman@ietf.org
http= s://www.ietf.org/mailman/listinfo/coman

=A0


--047d7bacc07e3cae5104ccd0c594-- From mehmet.ersue@nsn.com Thu Oct 25 11:39:03 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 D299221F8984 for ; Thu, 25 Oct 2012 11:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opOKbTjIjBgB for ; Thu, 25 Oct 2012 11:39: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 0838921F8952 for ; Thu, 25 Oct 2012 11:39:02 -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 q9PIcxu1012498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Oct 2012 20:38:59 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9PIcsub009147; Thu, 25 Oct 2012 20:38:59 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Oct 2012 20:38:54 +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: Thu, 25 Oct 2012 20:38:53 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640455E620@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64045094C3@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The Room is 211 WAS:RE: [coman] Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00 Thread-Index: Ac2wRBtNd8ibqR4zTzOUs3EDhJltsQCmro4w References: <80A0822C5E9A4440A5117C2F4CD36A64045094C3@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 25 Oct 2012 18:38:54.0462 (UTC) FILETIME=[FC56F1E0:01CDB2DF] 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: 1328 X-purgate-ID: 151667::1351190339-00006DFC-3FF5A7B8/0-0/0-0 Cc: ext Benoit Claise Subject: [coman] The Room is 211 WAS:RE: Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00 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: Thu, 25 Oct 2012 18:39:03 -0000 Hi All, the Coman discussion will be on November 8th, 2012 Thursday betw. 11:30 - 13:00 in Room 211=20 (for your orientation pls see the floor plan at http://www.ietf.org/meeting/85/floor-plans.pdf). PS: We will wait a few minutes on those who try to get something portable to eat for lunch. Cheers,=20 Mehmet=20 > -----Original Message----- > From: coman-bounces@ietf.org [mailto:coman-bounces@ietf.org] On Behalf Of Ersue, > Mehmet (NSN - DE/Munich) > Sent: Monday, October 22, 2012 12:58 PM > To: coman@ietf.org > Cc: ext Benoit Claise > Subject: [coman] Coman side discussion on November 8th,2012 Thursday 11:30 - > 13:00 >=20 > Hi All, >=20 > we planned a Coman side discussion on November 8th, 2012 Thursday 11:30 > - 13:00. >=20 > Topics will -02 draft in general, constrained device classes, class of > networks in focus, management of constrainedness and the requirements > section, etc. >=20 > PS: This is just an adhoc discussion. There will be no jabber, no > recording. I will provide some minutes. > PS2: The room request has been approved but the IETF secretary did not > assign a room yet. >=20 > Cheers, > Mehmet >=20 >=20 > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman From cabo@tzi.org Thu Oct 25 11:44:48 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 CDFA821F86DC for ; Thu, 25 Oct 2012 11:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.226 X-Spam-Level: X-Spam-Status: No, score=-106.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEiNInG7K4bP for ; Thu, 25 Oct 2012 11:44:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F325721F86CB for ; Thu, 25 Oct 2012 11:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q9PIibwl025748; Thu, 25 Oct 2012 20:44:37 +0200 (CEST) Received: from [192.168.217.105] (p54892C1E.dip.t-dialin.net [84.137.44.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A1763289; Thu, 25 Oct 2012 20:44:36 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640455E620@DEMUEXC006.nsn-intra.net> Date: Thu, 25 Oct 2012 20:44:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <80A0822C5E9A4440A5117C2F4CD36A64045094C3@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A640455E620@DEMUEXC006.nsn-intra.net> To: "Ersue, Mehmet (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1499) Cc: coman@ietf.org, ext Benoit Claise Subject: Re: [coman] The Room is 211 WAS:RE: Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00 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: Thu, 25 Oct 2012 18:44:49 -0000 On Oct 25, 2012, at 20:38, "Ersue, Mehmet (NSN - DE/Munich)" = wrote: > the Coman discussion will be on November 8th, 2012 Thursday betw. = 11:30 > - 13:00 in Room 211=20 Oh. I only just noticed that this conflicts with the apparea lunch = (which has moved to Thursday). Even if I personally decide to be a bad apparea citizen, this will = reduce apparea minded participation. Oh well. Gr=FC=DFe, Carsten From mehmet.ersue@nsn.com Fri Oct 26 01:25:12 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 6384821F8468 for ; Fri, 26 Oct 2012 01:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddPufP1dYcwS for ; Fri, 26 Oct 2012 01:25:11 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 31A1E21F845E for ; Fri, 26 Oct 2012 01:25:11 -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 q9Q8P60M018850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Oct 2012 10:25:06 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9Q8P4qP024541; Fri, 26 Oct 2012 10:25:06 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Oct 2012 10:25:00 +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: Fri, 26 Oct 2012 10:24:59 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640455E6C7@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [coman] The Room is 211 WAS:RE: Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00 Thread-Index: Ac2y4M/HaCa3BAVvTo2KQ+3aVfZmYQAcg1qg References: <80A0822C5E9A4440A5117C2F4CD36A64045094C3@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A640455E620@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Carsten Bormann" X-OriginalArrivalTime: 26 Oct 2012 08:25:00.0457 (UTC) FILETIME=[63F99190:01CDB353] 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: 932 X-purgate-ID: 151667::1351239907-000048BF-525CA240/0-0/0-0 Cc: coman@ietf.org, ext Benoit Claise Subject: Re: [coman] The Room is 211 WAS:RE: Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00 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, 26 Oct 2012 08:25:12 -0000 Mea culpa. It was a trade-off to enable people going to sessions on = Thursday morning. Gr=FC=DFe,=20 Mehmet=20 > -----Original Message----- > From: ext Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, October 25, 2012 8:45 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: coman@ietf.org; ext Benoit Claise > Subject: Re: [coman] The Room is 211 WAS:RE: Coman side discussion on = November > 8th, 2012 Thursday 11:30 - 13:00 >=20 > On Oct 25, 2012, at 20:38, "Ersue, Mehmet (NSN - DE/Munich)" > wrote: >=20 > > the Coman discussion will be on November 8th, 2012 Thursday betw. = 11:30 > > - 13:00 in Room 211 >=20 > Oh. I only just noticed that this conflicts with the apparea lunch = (which has moved to > Thursday). > Even if I personally decide to be a bad apparea citizen, this will = reduce apparea minded > participation. > Oh well. >=20 > Gr=FC=DFe, Carsten