From nobody Sun May 1 02:55:52 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EC712B00A for ; Sun, 1 May 2016 02:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxm9K3PD0t54 for ; Sun, 1 May 2016 02:55:47 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B3F12D1DB for ; Sun, 1 May 2016 02:55:47 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id n63so62879658qkf.0 for ; Sun, 01 May 2016 02:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Y5Lp1SBJh58yx6LMPhuuu0s4zC+PK3ENqdVjF6fzS1g=; b=OaCA4ISuNGBqgll11JsGIxng+Fcjn/LmnzEM6SqyBY5sQb2B3WOiMaavFaQXH56U2P 7YAWBkaEBbpONCHINiXlcOotbQakQROdZ7LTBMGkC6u1pdcv4iikIhbz/F6JsUV8t/18 jO84XkSqvTbOr0jaN/NaCdpowsLgbvsxyf20iFizsoI2cgGgjfWGd+k7hWCjlh2sdi11 yjSYlYG17IBRjxgOgcIotQyiW2xkD2m/nTqy+b4xHFRGdcfr1P5nF+7JqI8h/j/MAcph GZsv42wIjcc5hD3HfEs2uHaugOFIApgoa5MYStNCG/0pxN6u1UMQf6nOKPJZlivab1pb PxNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Y5Lp1SBJh58yx6LMPhuuu0s4zC+PK3ENqdVjF6fzS1g=; b=kyy0fb1AK6729FrHVT4T69NlWitWKXlhZfgy4KnXuLBGsi3yMce6yk2kGrcB9G2YJ+ YPassJDMV7YYfL8+3hh3S2kcFngGE3Ww19QD3yg/tISbVSYKsqAtdWhTm3RUFt7uO6VG vKvjaIRvZRfEOAmC+fPDeM+NP4ddd+L/ABRYBL8P/376xcC5pX1/huyNxIwrVGEgnkKN 1uc/ENSew5kakD1e3lMY0Laf2K9Wy0UvUJw8VW9oLt8V2BlKrLLjbxo6QfwTvKDpcXMN paiMaDabZiVZaGP8Vk6baY34xaDGQfCmrwUL/calNJJZ9lLy5J1PU8EiSjpL/yqDP6y9 tDQA== X-Gm-Message-State: AOPr4FWNRU82NVNn/BOIi/7klgAB9QrWrOd3e6OqmfqYxGoMIl706DJyrRHZxvjV1a30IvgiRD396F9z8piNSg== MIME-Version: 1.0 X-Received: by 10.55.104.197 with SMTP id d188mr26222722qkc.93.1462096546806; Sun, 01 May 2016 02:55:46 -0700 (PDT) Received: by 10.140.43.52 with HTTP; Sun, 1 May 2016 02:55:46 -0700 (PDT) In-Reply-To: References: Date: Sun, 1 May 2016 11:55:46 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=94eb2c087f0e4ccf1e0531c4e1ee Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] draft-ietf-manet-rfc5444-usage X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 09:55:50 -0000 --94eb2c087f0e4ccf1e0531c4e1ee Content-Type: text/plain; charset=UTF-8 Hi Chris, and WG, IMO, this draft needs to clarify the usage for both reactive and proactive routings, but it seems like it is for hybrid protocols only. I suggest that we get more input from the AODVv2 experts/authors to comment on this work. In our discussions before we seen MANET participants saying what 5444 experts think but I think that the packet-format experts cannot guide our protocol experts (i.e. this draft is guiding protocol design). Usually the protocol is the master of the packet not the packet is mastering the protocol, however, It appears that our MANET WG has done the format-usage to guide the general protocol, am I wrong?, I think it was good to do the RFC5444 as general and let the protocol expert find what is the best rule to use. It is better for routing security that proactive routing uses 5444 differently than reactive, am I wrong? The best for this 5444 usage draft to be for general-routing, and needs to include with section titles: How best to use 5444 for Proactive Routing Protocol (including multiplexer roles), 2- How best to use 5444 for Reactive Routing Protocol (including multiplexer roles). The hybrid routing usage of 5444 can be done when we recharter. Furthermore, this draft should be for only unicast routing protocols because we still did not do the multicast routing (so this needs to be clear in the draft). Also we should not ignore that our AODVv2 draft needs to be completed, and is not done yet so we need to firstly complete it before submitting this usage of packet-format. IMO this idea of 5444 and its RFC was the reason of delaying the WG effort of AODVv2, therefore, I suggest that we don't make this standard until completing AODVv2 (i.e. it will help the discussions for both drafts). I am expecting that my suggestion will be refused, but I think my reasons can be understood. AB Humans designed the general ball, so it is good to let different people to play-with/use it with different rules. Different players/experts use different balls with different rules. Why do we limit the general design so that all players use the ball the same way? On Fri, Apr 29, 2016 at 6:04 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > WGLC having finished, I've been through everyone's comments. And by my > reckoning this is what we (the authors) should do (agreed changes, and in > at least one case I had an "aha" that's what I think is being asked for, in > which case we can do that). > > - Section 4.2 is titled Packets and Messages, but is about Multiplexer. > Take under advisement, can see both sides of that. Hope when we've done > everything else what's best will be clear. > > - Section 4.4 "An unmodified extension to NHDP would ignore such > addresses" Be clear that ignoring if just present. Don't ignore if address > has TLVs router is using. Also be clearer up front in this paragraph that > discussing case in final sentence. > > - Section 4.5. Some words up front as to why this material is here. > > - Read through document to check if clear where advice is for protocol > designer, and where is for protocol implementer. The former is our main > emphasis, though comments about parsing are the latter. > > - Words up front to be clear that, as well as multiplexer (and how RFC > 5498 mandates that),RFC 5444 only specifies formats; parsing (and its > opposite - forming?) is done by protocol. An implementer may simply do this > in a protocol, but a natural design is a separate parser used by multiple > protocols (e.g. NHDP and OLSRv2). Some comments are about if you choose to > do latter, especially Section 6.4 but don't leave first mention to there. > But a separate parser is not a requirement. > > - Section 6.1 to be clear, addresses always have a head a mid and a tail. > Gain compression advantage when head and/or tail are not empty. > > - Section 6.1 " Putting addresses into a message efficiently also has to > include" s/include/consider/ > > - Section 6.2 Be clear that analysis of NHDP and OLSRv2 shows ordering > possible, but the details are beyond the scope of this document. > > - Section 6.3 Be clear that UNSPECIFIED is for TLVs with discrete values > (usually specified in a registry). There is an equivalent in at least one > other case (OLSRv2 metrics). > > - Section 4.2 first bullet, or elsewhere cross-referenced. Be clear > (reference to 5444 appendix) that the recommended approach is messages > unchanged except for hop count/limit, because it enables E2E > authentication, in particular using RFC 7182 message TLVs. > > - Section 4.2 bullet 3, add comment that protocol should not produce > message that (with additional headers) would exceed MTU if sent on its own > in a packet. (If it does, as the multiplexer can't fragment, IP will have > to, and that's undesirable.) > > - Multiplexer adding packet sequence number, MUST be consistent (add to > all packets or none - for each interface and destination as it already > says). > > - Probably (if there's a suitable place to say it) note that the > multiplexer has a relationship (message transfer) with protocols that own > messages. The interaction between a protocol and any extensions is up to > them, not the multiplexer. > > - Change uses of extended type to full type. Add full type to Terminology, > matching to symbolic name in RFC 5444. Check if extended type is used in > other RFCs, if it is, add comment that sometimes so referred to. > > Somewhere be clear that routers in a MANET need to have a common > understanding of RFC 7182 usage, including whether by multiplexer (always > for packets) or protocol. > > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > __________________________________________________________________________ > > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --94eb2c087f0e4ccf1e0531c4e1ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chris, and WG,

IMO, th= is draft needs to clarify the usage for both reactive and proactive routing= s, but it seems like it is for hybrid protocols only. I suggest that we get= more input from the AODVv2 experts/authors to comment on this work. In our= discussions before we seen MANET participants saying what 5444 experts thi= nk but I think that the packet-format experts cannot guide our protocol exp= erts (i.e. this draft is guiding protocol design). Usually the protocol is = the master of the packet not the packet is mastering the protocol, however,= It appears that our MANET WG has done the format-usage to guide the genera= l protocol, am I wrong?, I think it was good to do the RFC5444 as general a= nd let the protocol expert find what is the best rule to use. It is better = for routing security that proactive routing uses 5444 differently than reac= tive, am I wrong?

The best for this 5444 usage draft to be for gene= ral-routing, and needs to include with section titles: How best to use 5444= for Proactive Routing Protocol (including multiplexer roles), 2- How best = to use 5444 for Reactive Routing Protocol (including multiplexer roles). Th= e hybrid routing usage of 5444 can be done when we recharter. Furthermore, = this draft should be for only unicast routing protocols because we still di= d not do the multicast routing (so this needs to be clear in the draft). Al= so we should not ignore that our AODVv2 draft needs to be completed, and is= not done yet so we need to firstly complete it before submitting this usag= e of packet-format. IMO this idea of 5444 and its RFC was the reason of del= aying the WG effort of AODVv2, therefore, I suggest that we don't make = this standard until completing AODVv2 (i.e. it will help the discussions fo= r both drafts).

I am expecting that my suggestion will be refu= sed, but I think my reasons can be understood.

AB

Humans designed the general ball, so it is good to let different people to= play-with/use it with different rules. Different players/experts use diffe= rent balls with different rules. Why do we limit the general design so that= all players use the ball the same way?

On Fri, Apr 29, 2016 at 6:04 PM, Dearlove, = Christopher (UK) <chris.dearlove@baesystems.com>= wrote:
WGLC having finished, I've be= en through everyone's comments. And by my reckoning this is what we (th= e authors) should do (agreed changes, and in at least one case I had an &qu= ot;aha" that's what I think is being asked for, in which case we c= an do that).

- Section 4.2 is titled Packets and Messages, but is about Multiplexer. Tak= e under advisement, can see both sides of that. Hope when we've done ev= erything else what's best will be clear.

- Section 4.4 "An unmodified extension to NHDP would ignore such addre= sses" Be clear that ignoring if just present. Don't ignore if addr= ess has TLVs router is using. Also be clearer up front in this paragraph th= at discussing case in final sentence.

- Section 4.5. Some words up front as to why this material is here.

- Read through document to check if clear where advice is for protocol desi= gner, and where is for protocol implementer. The former is our main emphasi= s, though comments about parsing are the latter.

- Words up front to be clear that, as well as multiplexer (and how RFC 5498= mandates that),RFC=C2=A0 5444 only specifies formats; parsing (and its opp= osite - forming?) is done by protocol. An implementer may simply do this in= a protocol, but a natural design is a separate parser used by multiple pro= tocols (e.g. NHDP and OLSRv2). Some comments are about if you choose to do = latter, especially Section 6.4 but don't leave first mention to there. = But a separate parser is not a requirement.

- Section 6.1 to be clear, addresses always have a head a mid and a tail. G= ain compression advantage when head and/or tail are not empty.

- Section 6.1 " Putting addresses into a message efficiently also has = to include" s/include/consider/

- Section 6.2 Be clear that analysis of NHDP and OLSRv2 shows ordering poss= ible, but the details are beyond the scope of this document.

- Section 6.3 Be clear that UNSPECIFIED is for TLVs with discrete values (u= sually specified in a registry). There is an equivalent in at least one oth= er case (OLSRv2 metrics).

- Section 4.2 first bullet, or elsewhere cross-referenced. Be clear (refere= nce to 5444 appendix) that the recommended approach is messages unchanged e= xcept for hop count/limit, because it enables E2E authentication, in partic= ular using RFC 7182 message TLVs.

- Section 4.2 bullet 3, add comment that protocol should not produce messag= e that (with additional headers) would exceed MTU if sent on its own in a p= acket. (If it does, as the multiplexer can't fragment, IP will have to,= and that's undesirable.)

- Multiplexer adding packet sequence number, MUST be consistent (add to all= packets or none - for each interface and destination as it already says).<= br>
- Probably (if there's a suitable place to say it) note that the multip= lexer has a relationship (message transfer) with protocols that own message= s. The interaction between a protocol and any extensions is up to them, not= the multiplexer.

- Change uses of extended type to full type. Add full type to Terminology, = matching to symbolic name in RFC 5444. Check if extended type is used in ot= her RFCs, if it is, add comment that sometimes so referred to.

Somewhere be clear that routers in a MANET need to have a common understand= ing of RFC 7182 usage, including whether by multiplexer (always for packets= ) or protocol.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________<= br>
T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--94eb2c087f0e4ccf1e0531c4e1ee-- From nobody Sun May 1 04:07:08 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2456012B061 for ; Sun, 1 May 2016 04:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rcWDAKNsazn for ; Sun, 1 May 2016 04:07:05 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E60212B046 for ; Sun, 1 May 2016 04:07:04 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id a17so101741340wme.0 for ; Sun, 01 May 2016 04:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:message-id :content-transfer-encoding:from:subject:date:to; bh=QH7Lo8FdvraSuVHi9TMNyIyNrppuk9Oa6DF/TT4VCo0=; b=OqvaWu39JtFOYu/PbOuEvMsKPPhAHSUXUQq1NxykG2sTfeow26G7q8i6yrD9fOdSvX sxJMZva7/ZhS0kyFeS64oVFtol3IZZ7gqM+1s5Ex7xIwuph3TKs7TYXHMx+YEJiWavZp jtng9nh0uGDC9CCAR5zqOiCIGnrMk83v+qiNlP0rSS2PhXRzUf/4ZAUCVI6GnsNAf+Gt kMW7yzbvfuOkLlm9XZCcK0dx0WY/uO69IC+v7mQUmepW1ksSHJpAq1t8ycTSnxJmW6j7 TnNhpgsi3GpsfK1QGV1SgP0DgnyEdchLC4rgEEdFrIswAjwdx8OVEaAGY2Bo8o/C0pIB 4kyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:message-id :content-transfer-encoding:from:subject:date:to; bh=QH7Lo8FdvraSuVHi9TMNyIyNrppuk9Oa6DF/TT4VCo0=; b=iwM5Ebsq6BysTwYpYLnSbiP5YfPQw/DsDqo4CADonGremQVp37Y+T60GRE3hNLiexC aGkt1JmzNHL3YRsY3liQpllpomci9eOK745ke/yBbGCHkpwlLonIkG03NENVxSLq6ksh 4zHrWL0Eqgl8BeQYOAp92qkacRe3omcbAbtYV2u7JtXC/VtCuLYIFtrr27/+3bllZdrb rlvtmOzCateSgpXNCI21YWICzSfKrbztlx1jeosCDetG/WVmCKgGRr6pYsWf0TAAGbDO KY6qgHIRVWkCAN0Em7PYvAfjtOt9q0Tt3dvdFUJ/TGYtcu+IagudJKjUccWpuq0fWN1v hxYg== X-Gm-Message-State: AOPr4FUV9VaPeyHQGTsh0YVOTsMK5UvESlj3eJlzIznFXb0TAVYwJAMmokVgyBNrorw0jA== X-Received: by 10.194.140.17 with SMTP id rc17mr35471535wjb.175.1462100823037; Sun, 01 May 2016 04:07:03 -0700 (PDT) Received: from [10.2.171.195] (82-132-226-207.dab.02.net. [82.132.226.207]) by smtp.gmail.com with ESMTPSA id gr4sm24324925wjd.23.2016.05.01.04.07.01 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 04:07:02 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-A8010161-D4F5-4BD8-8D6A-5D8E54560752 Received: from [10.2.171.195] (82-132-226-207.dab.02.net. [82.132.226.207]) by smtp.gmail.com with ESMTPSA id ck9sm24375372wjc.22.2016.05.01.03.59.42 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 03:59:43 -0700 (PDT) Message-Id: <2BB0B6BD-3CBE-4471-9F5A-271B8F746455@gmail.com> Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (13E238) From: Christopher Dearlove Date: Sun, 1 May 2016 12:06:58 +0100 To: Abdussalam Baryun , manet@ietf.org Archived-At: Subject: Re: [manet] draft-ietf-manet-rfc5444-usage X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 11:07:07 -0000 --Apple-Mail-A8010161-D4F5-4BD8-8D6A-5D8E54560752 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable There's nothing in the draft exclusive to proactive protocols. The examples a= re mostly of NHDP and OLSRv2, because those exist as Proposed Standards. But= if you look closely they aren't about them being proactive or reactive, the= y are about that they illustrate protocol multiplexing and extensions. We've had comments from members of the AODVv2 author team. I'm not sure what= proportion of the changes to make are due to their comments, but it might b= e a majority. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 1 May 2016, at 10:55, Abdussalam Baryun wr= ote: >=20 > Hi Chris, and WG, >=20 > IMO, this draft needs to clarify the usage for both reactive and proactive= routings, but it seems like it is for hybrid protocols only. I suggest that= we get more input from the AODVv2 experts/authors to comment on this work. I= n our discussions before we seen MANET participants saying what 5444 experts= think but I think that the packet-format experts cannot guide our protocol e= xperts (i.e. this draft is guiding protocol design). Usually the protocol is= the master of the packet not the packet is mastering the protocol, however,= It appears that our MANET WG has done the format-usage to guide the general= protocol, am I wrong?, I think it was good to do the RFC5444 as general and= let the protocol expert find what is the best rule to use. It is better for= routing security that proactive routing uses 5444 differently than reactive= , am I wrong?=20 >=20 > The best for this 5444 usage draft to be for general-routing, and needs to= include with section titles: How best to use 5444 for Proactive Routing Pro= tocol (including multiplexer roles), 2- How best to use 5444 for Reactive Ro= uting Protocol (including multiplexer roles). The hybrid routing usage of 54= 44 can be done when we recharter. Furthermore, this draft should be for only= unicast routing protocols because we still did not do the multicast routing= (so this needs to be clear in the draft). Also we should not ignore that ou= r AODVv2 draft needs to be completed, and is not done yet so we need to firs= tly complete it before submitting this usage of packet-format. IMO this idea= of 5444 and its RFC was the reason of delaying the WG effort of AODVv2, the= refore, I suggest that we don't make this standard until completing AODVv2 (= i.e. it will help the discussions for both drafts). >=20 > I am expecting that my suggestion will be refused, but I think my reasons c= an be understood. >=20 > AB >=20 > Humans designed the general ball, so it is good to let different people to= play-with/use it with different rules. Different players/experts use differ= ent balls with different rules. Why do we limit the general design so that a= ll players use the ball the same way? >=20 >> On Fri, Apr 29, 2016 at 6:04 PM, Dearlove, Christopher (UK) wrote: >> WGLC having finished, I've been through everyone's comments. And by my re= ckoning this is what we (the authors) should do (agreed changes, and in at l= east one case I had an "aha" that's what I think is being asked for, in whic= h case we can do that). >>=20 >> - Section 4.2 is titled Packets and Messages, but is about Multiplexer. T= ake under advisement, can see both sides of that. Hope when we've done every= thing else what's best will be clear. >>=20 >> - Section 4.4 "An unmodified extension to NHDP would ignore such addresse= s" Be clear that ignoring if just present. Don't ignore if address has TLVs r= outer is using. Also be clearer up front in this paragraph that discussing c= ase in final sentence. >>=20 >> - Section 4.5. Some words up front as to why this material is here. >>=20 >> - Read through document to check if clear where advice is for protocol de= signer, and where is for protocol implementer. The former is our main emphas= is, though comments about parsing are the latter. >>=20 >> - Words up front to be clear that, as well as multiplexer (and how RFC 54= 98 mandates that),RFC 5444 only specifies formats; parsing (and its opposit= e - forming?) is done by protocol. An implementer may simply do this in a pr= otocol, but a natural design is a separate parser used by multiple protocols= (e.g. NHDP and OLSRv2). Some comments are about if you choose to do latter,= especially Section 6.4 but don't leave first mention to there. But a separa= te parser is not a requirement. >>=20 >> - Section 6.1 to be clear, addresses always have a head a mid and a tail.= Gain compression advantage when head and/or tail are not empty. >>=20 >> - Section 6.1 " Putting addresses into a message efficiently also has to i= nclude" s/include/consider/ >>=20 >> - Section 6.2 Be clear that analysis of NHDP and OLSRv2 shows ordering po= ssible, but the details are beyond the scope of this document. >>=20 >> - Section 6.3 Be clear that UNSPECIFIED is for TLVs with discrete values (= usually specified in a registry). There is an equivalent in at least one oth= er case (OLSRv2 metrics). >>=20 >> - Section 4.2 first bullet, or elsewhere cross-referenced. Be clear (refe= rence to 5444 appendix) that the recommended approach is messages unchanged e= xcept for hop count/limit, because it enables E2E authentication, in particu= lar using RFC 7182 message TLVs. >>=20 >> - Section 4.2 bullet 3, add comment that protocol should not produce mess= age that (with additional headers) would exceed MTU if sent on its own in a p= acket. (If it does, as the multiplexer can't fragment, IP will have to, and t= hat's undesirable.) >>=20 >> - Multiplexer adding packet sequence number, MUST be consistent (add to a= ll packets or none - for each interface and destination as it already says).= >>=20 >> - Probably (if there's a suitable place to say it) note that the multiple= xer has a relationship (message transfer) with protocols that own messages. T= he interaction between a protocol and any extensions is up to them, not the m= ultiplexer. >>=20 >> - Change uses of extended type to full type. Add full type to Terminology= , matching to symbolic name in RFC 5444. Check if extended type is used in o= ther RFCs, if it is, add comment that sometimes so referred to. >>=20 >> Somewhere be clear that routers in a MANET need to have a common understa= nding of RFC 7182 usage, including whether by multiplexer (always for packet= s) or protocol. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> _________________________________________________________________________= _ >>=20 >> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>=20 >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddo= w, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-A8010161-D4F5-4BD8-8D6A-5D8E54560752 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There's noth= ing in the draft exclusive to proactive protocols. The examples are mostly o= f NHDP and OLSRv2, because those exist as Proposed Standards. But if you loo= k closely they aren't about them being proactive or reactive, they are about= that they illustrate protocol multiplexing and extensions.

We've had comments from members of the AODVv2 author team. I'm not s= ure what proportion of the changes to make are due to their comments, but it= might be a majority.

--  
Christopher Dearlove<= /div>

On= 1 May 2016, at 10:55, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Chris, and WG,=

IMO, this draft needs to clarify the usage for both reactive a= nd proactive routings, but it seems like it is for hybrid protocols only. I s= uggest that we get more input from the AODVv2 experts/authors to comment on t= his work. In our discussions before we seen MANET participants saying what 5= 444 experts think but I think that the packet-format experts cannot guide ou= r protocol experts (i.e. this draft is guiding protocol design). Usually the= protocol is the master of the packet not the packet is mastering the protoc= ol, however, It appears that our MANET WG has done the format-usage to guide= the general protocol, am I wrong?, I think it was good to do the RFC5444 as= general and let the protocol expert find what is the best rule to use. It i= s better for routing security that proactive routing uses 5444 differently t= han reactive, am I wrong?

The best for this 5444 usage draft to be f= or general-routing, and needs to include with section titles: How best to us= e 5444 for Proactive Routing Protocol (including multiplexer roles), 2- How b= est to use 5444 for Reactive Routing Protocol (including multiplexer roles).= The hybrid routing usage of 5444 can be done when we recharter. Furthermore= , this draft should be for only unicast routing protocols because we still d= id not do the multicast routing (so this needs to be clear in the draft). Al= so we should not ignore that our AODVv2 draft needs to be completed, and is n= ot done yet so we need to firstly complete it before submitting this usage o= f packet-format. IMO this idea of 5444 and its RFC was the reason of delayin= g the WG effort of AODVv2, therefore, I suggest that we don't make this stan= dard until completing AODVv2 (i.e. it will help the discussions for both dra= fts).

I am expecting that my suggestion will be refused, but I t= hink my reasons can be understood.

AB

Humans desig= ned the general ball, so it is good to let different people to play-with/use= it with different rules. Different players/experts use different balls with= different rules. Why do we limit the general design so that all players use= the ball the same way?

On Fri, Apr 29, 2016 at 6:04 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
WGLC having finished, I've been through everyone's comments= . And by my reckoning this is what we (the authors) should do (agreed change= s, and in at least one case I had an "aha" that's what I think is being aske= d for, in which case we can do that).

- Section 4.2 is titled Packets and Messages, but is about Multiplexer. Take= under advisement, can see both sides of that. Hope when we've done everythi= ng else what's best will be clear.

- Section 4.4 "An unmodified extension to NHDP would ignore such addresses" B= e clear that ignoring if just present. Don't ignore if address has TLVs rout= er is using. Also be clearer up front in this paragraph that discussing case= in final sentence.

- Section 4.5. Some words up front as to why this material is here.

- Read through document to check if clear where advice is for protocol desig= ner, and where is for protocol implementer. The former is our main emphasis,= though comments about parsing are the latter.

- Words up front to be clear that, as well as multiplexer (and how RFC 5498 m= andates that),RFC  5444 only specifies formats; parsing (and its opposi= te - forming?) is done by protocol. An implementer may simply do this in a p= rotocol, but a natural design is a separate parser used by multiple protocol= s (e.g. NHDP and OLSRv2). Some comments are about if you choose to do latter= , especially Section 6.4 but don't leave first mention to there. But a separ= ate parser is not a requirement.

- Section 6.1 to be clear, addresses always have a head a mid and a tail. Ga= in compression advantage when head and/or tail are not empty.

- Section 6.1 " Putting addresses into a message efficiently also has to inc= lude" s/include/consider/

- Section 6.2 Be clear that analysis of NHDP and OLSRv2 shows ordering possi= ble, but the details are beyond the scope of this document.

- Section 6.3 Be clear that UNSPECIFIED is for TLVs with discrete values (us= ually specified in a registry). There is an equivalent in at least one other= case (OLSRv2 metrics).

- Section 4.2 first bullet, or elsewhere cross-referenced. Be clear (referen= ce to 5444 appendix) that the recommended approach is messages unchanged exc= ept for hop count/limit, because it enables E2E authentication, in particula= r using RFC 7182 message TLVs.

- Section 4.2 bullet 3, add comment that protocol should not produce message= that (with additional headers) would exceed MTU if sent on its own in a pac= ket. (If it does, as the multiplexer can't fragment, IP will have to, and th= at's undesirable.)

- Multiplexer adding packet sequence number, MUST be consistent (add to all p= ackets or none - for each interface and destination as it already says).
=
- Probably (if there's a suitable place to say it) note that the multiplexer= has a relationship (message transfer) with protocols that own messages. The= interaction between a protocol and any extensions is up to them, not the mu= ltiplexer.

- Change uses of extended type to full type. Add full type to Terminology, m= atching to symbolic name in RFC 5444. Check if extended type is used in othe= r RFCs, if it is, add comment that sometimes so referred to.

Somewhere be clear that routers in a MANET need to have a common understandi= ng of RFC 7182 usage, including whether by multiplexer (always for packets) o= r protocol.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
T:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, C= helmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-A8010161-D4F5-4BD8-8D6A-5D8E54560752-- From nobody Sun May 1 07:26:57 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1B712D0F5 for ; Sun, 1 May 2016 07:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAZKGSkS5Cnd for ; Sun, 1 May 2016 07:26:54 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF3512D0E5 for ; Sun, 1 May 2016 07:26:53 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id e201so79686962wme.0 for ; Sun, 01 May 2016 07:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=UFzPMMHWmTO174mVivZx704c76u7m+lomPHbhHUAg8M=; b=mRDLw3N4kOL5OJR6qFwALuPqhRanA+vueN4Jum3JY2QM4aeKzZOUQL470w6y6tjNMi sHP98RGKwNGae6CwOHpBGDbXjOWIR4tVaKjEFly/Pneqm/h5TuBKnF/8RYh7nt05V+GK Mrb3YgwkYVgdk/JmQQQhQjdGUWNBzNMMzqJKhQZfxqgqLZ4gbOoQa9C0sqPF/0D+CSJo xng66EFpLo12CxTfgUHms7O5n5Z7s57r4fBj/TazwyPpdXmKvy61rSXrzpq3+LiN8ZMo SJjDgYQNurJjkbJYhDuc5sGYDVeQxR4TkspOTN4JIFJKTpovLuqCbALQZN5k4LSVvyqO 9hxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=UFzPMMHWmTO174mVivZx704c76u7m+lomPHbhHUAg8M=; b=iBB2sLkYaKJHckYYp6QVeoIiSgLwUTCofeZA3R+Wc1v9MyGr7FChvLvyVEj5F1eRhQ hf47Pqj+uFnsPQCZc6pFwmOADztEUuHJ3YGVrNqaPBkmYkAjYyDTntck4sB4ZEIbXP3S 5EA4/Rgj59lfUH5myaJR1iSRyWQ46mZhrlNgPKVbW7yu2EBHS12s8hhHGYkul2ofaWcQ QZdzpnsyCiEHHRPlq9/e2KrI9Idp5X8FOBtsJ6JRkyoddSTRRydy7g5ig8KAizJ8YMYZ XVqGxMsOerxabAhz/5LoF6qPA5J0zA/K5AYgnLZwcsc9AfK1DGR8dJBG4PYqHfgD/Itv mGQw== X-Gm-Message-State: AOPr4FVIxxACr4D+PCalqIGz4mDsyXS3fXJ3iyHc8JuKdL4bgAQskUuLXTtue32BQIObwg== X-Received: by 10.194.134.73 with SMTP id pi9mr30785973wjb.156.1462112812411; Sun, 01 May 2016 07:26:52 -0700 (PDT) Received: from [10.235.238.72] ([213.205.252.136]) by smtp.gmail.com with ESMTPSA id y3sm25107703wji.40.2016.05.01.07.26.50 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 07:26:51 -0700 (PDT) References: <2BB0B6BD-3CBE-4471-9F5A-271B8F746455@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2BB0B6BD-3CBE-4471-9F5A-271B8F746455@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-FED94519-FDD8-464E-B57E-8DA92C1BC6A9 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (13E238) From: John Dowdell Date: Sun, 1 May 2016 15:26:46 +0100 To: Christopher Dearlove Archived-At: Cc: manet@ietf.org Subject: Re: [manet] draft-ietf-manet-rfc5444-usage X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 14:26:57 -0000 --Apple-Mail-FED94519-FDD8-464E-B57E-8DA92C1BC6A9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'd just like to be clear that the AODVv2 team asked for this document, and I= think all of the author team have commented on one aspect or another. John Sent from my iPhone > On 1 May 2016, at 12:06, Christopher Dearlove wrote: >=20 > There's nothing in the draft exclusive to proactive protocols. The example= s are mostly of NHDP and OLSRv2, because those exist as Proposed Standards. B= ut if you look closely they aren't about them being proactive or reactive, t= hey are about that they illustrate protocol multiplexing and extensions. >=20 > We've had comments from members of the AODVv2 author team. I'm not sure wh= at proportion of the changes to make are due to their comments, but it might= be a majority. >=20 > -- =20 > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) >=20 >> On 1 May 2016, at 10:55, Abdussalam Baryun w= rote: >>=20 >> Hi Chris, and WG, >>=20 >> IMO, this draft needs to clarify the usage for both reactive and proactiv= e routings, but it seems like it is for hybrid protocols only. I suggest tha= t we get more input from the AODVv2 experts/authors to comment on this work.= In our discussions before we seen MANET participants saying what 5444 exper= ts think but I think that the packet-format experts cannot guide our protoco= l experts (i.e. this draft is guiding protocol design). Usually the protocol= is the master of the packet not the packet is mastering the protocol, howev= er, It appears that our MANET WG has done the format-usage to guide the gene= ral protocol, am I wrong?, I think it was good to do the RFC5444 as general a= nd let the protocol expert find what is the best rule to use. It is better f= or routing security that proactive routing uses 5444 differently than reacti= ve, am I wrong?=20 >>=20 >> The best for this 5444 usage draft to be for general-routing, and needs t= o include with section titles: How best to use 5444 for Proactive Routing Pr= otocol (including multiplexer roles), 2- How best to use 5444 for Reactive R= outing Protocol (including multiplexer roles). The hybrid routing usage of 5= 444 can be done when we recharter. Furthermore, this draft should be for onl= y unicast routing protocols because we still did not do the multicast routin= g (so this needs to be clear in the draft). Also we should not ignore that o= ur AODVv2 draft needs to be completed, and is not done yet so we need to fir= stly complete it before submitting this usage of packet-format. IMO this ide= a of 5444 and its RFC was the reason of delaying the WG effort of AODVv2, th= erefore, I suggest that we don't make this standard until completing AODVv2 (= i.e. it will help the discussions for both drafts). >>=20 >> I am expecting that my suggestion will be refused, but I think my reasons= can be understood. >>=20 >> AB >>=20 >> Humans designed the general ball, so it is good to let different people t= o play-with/use it with different rules. Different players/experts use diffe= rent balls with different rules. Why do we limit the general design so that a= ll players use the ball the same way? >>=20 >>> On Fri, Apr 29, 2016 at 6:04 PM, Dearlove, Christopher (UK) wrote: >>> WGLC having finished, I've been through everyone's comments. And by my r= eckoning this is what we (the authors) should do (agreed changes, and in at l= east one case I had an "aha" that's what I think is being asked for, in whic= h case we can do that). >>>=20 >>> - Section 4.2 is titled Packets and Messages, but is about Multiplexer. T= ake under advisement, can see both sides of that. Hope when we've done every= thing else what's best will be clear. >>>=20 >>> - Section 4.4 "An unmodified extension to NHDP would ignore such address= es" Be clear that ignoring if just present. Don't ignore if address has TLVs= router is using. Also be clearer up front in this paragraph that discussing= case in final sentence. >>>=20 >>> - Section 4.5. Some words up front as to why this material is here. >>>=20 >>> - Read through document to check if clear where advice is for protocol d= esigner, and where is for protocol implementer. The former is our main empha= sis, though comments about parsing are the latter. >>>=20 >>> - Words up front to be clear that, as well as multiplexer (and how RFC 5= 498 mandates that),RFC 5444 only specifies formats; parsing (and its opposi= te - forming?) is done by protocol. An implementer may simply do this in a p= rotocol, but a natural design is a separate parser used by multiple protocol= s (e.g. NHDP and OLSRv2). Some comments are about if you choose to do latter= , especially Section 6.4 but don't leave first mention to there. But a separ= ate parser is not a requirement. >>>=20 >>> - Section 6.1 to be clear, addresses always have a head a mid and a tail= . Gain compression advantage when head and/or tail are not empty. >>>=20 >>> - Section 6.1 " Putting addresses into a message efficiently also has to= include" s/include/consider/ >>>=20 >>> - Section 6.2 Be clear that analysis of NHDP and OLSRv2 shows ordering p= ossible, but the details are beyond the scope of this document. >>>=20 >>> - Section 6.3 Be clear that UNSPECIFIED is for TLVs with discrete values= (usually specified in a registry). There is an equivalent in at least one o= ther case (OLSRv2 metrics). >>>=20 >>> - Section 4.2 first bullet, or elsewhere cross-referenced. Be clear (ref= erence to 5444 appendix) that the recommended approach is messages unchanged= except for hop count/limit, because it enables E2E authentication, in parti= cular using RFC 7182 message TLVs. >>>=20 >>> - Section 4.2 bullet 3, add comment that protocol should not produce mes= sage that (with additional headers) would exceed MTU if sent on its own in a= packet. (If it does, as the multiplexer can't fragment, IP will have to, an= d that's undesirable.) >>>=20 >>> - Multiplexer adding packet sequence number, MUST be consistent (add to a= ll packets or none - for each interface and destination as it already says).= >>>=20 >>> - Probably (if there's a suitable place to say it) note that the multipl= exer has a relationship (message transfer) with protocols that own messages.= The interaction between a protocol and any extensions is up to them, not th= e multiplexer. >>>=20 >>> - Change uses of extended type to full type. Add full type to Terminolog= y, matching to symbolic name in RFC 5444. Check if extended type is used in o= ther RFCs, if it is, add comment that sometimes so referred to. >>>=20 >>> Somewhere be clear that routers in a MANET need to have a common underst= anding of RFC 7182 usage, including whether by multiplexer (always for packe= ts) or protocol. >>>=20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer >>> BAE Systems Applied Intelligence Laboratories >>> ________________________________________________________________________= __ >>>=20 >>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>=20 >>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Badd= ow, Chelmsford, Essex CM2 8HN. >>> www.baesystems.com/ai >>> BAE Systems Applied Intelligence Limited >>> Registered in England & Wales No: 01337451 >>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>=20 >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-FED94519-FDD8-464E-B57E-8DA92C1BC6A9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'd just like to be clear that the AOD= Vv2 team asked for this document, and I think all of the author team have co= mmented on one aspect or another.

John

Sent from my iPhone

On 1 May 2016, at 12:06, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
There= 's nothing in the draft exclusive to proactive protocols. The examples are m= ostly of NHDP and OLSRv2, because those exist as Proposed Standards. But if y= ou look closely they aren't about them being proactive or reactive, they are= about that they illustrate protocol multiplexing and extensions.
=
We've had comments from members of the AODVv2 author team. I'= m not sure what proportion of the changes to make are due to their comments,= but it might be a majority.

--  
Christopher De= arlove

On 1 May 2016, at 10:55, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Chris, a= nd WG,

IMO, this draft needs to clarify the usage for both reac= tive and proactive routings, but it seems like it is for hybrid protocols on= ly. I suggest that we get more input from the AODVv2 experts/authors to comm= ent on this work. In our discussions before we seen MANET participants sayin= g what 5444 experts think but I think that the packet-format experts cannot g= uide our protocol experts (i.e. this draft is guiding protocol design). Usua= lly the protocol is the master of the packet not the packet is mastering the= protocol, however, It appears that our MANET WG has done the format-usage t= o guide the general protocol, am I wrong?, I think it was good to do the RFC= 5444 as general and let the protocol expert find what is the best rule to us= e. It is better for routing security that proactive routing uses 5444 differ= ently than reactive, am I wrong?

The best for this 5444 usage draft t= o be for general-routing, and needs to include with section titles: How best= to use 5444 for Proactive Routing Protocol (including multiplexer roles), 2= - How best to use 5444 for Reactive Routing Protocol (including multiplexer r= oles). The hybrid routing usage of 5444 can be done when we recharter. Furth= ermore, this draft should be for only unicast routing protocols because we s= till did not do the multicast routing (so this needs to be clear in the draf= t). Also we should not ignore that our AODVv2 draft needs to be completed, a= nd is not done yet so we need to firstly complete it before submitting this u= sage of packet-format. IMO this idea of 5444 and its RFC was the reason of d= elaying the WG effort of AODVv2, therefore, I suggest that we don't make thi= s standard until completing AODVv2 (i.e. it will help the discussions for bo= th drafts).

I am expecting that my suggestion will be refused, b= ut I think my reasons can be understood.

AB

Humans= designed the general ball, so it is good to let different people to play-wi= th/use it with different rules. Different players/experts use different ball= s with different rules. Why do we limit the general design so that all playe= rs use the ball the same way?

On Fri, Apr 29, 2016 at 6:04 PM, Dearlove, Christopher (= UK) <chris.dearlove@baesystems.com> wrote:
WGLC having finished, I've been through everyone's= comments. And by my reckoning this is what we (the authors) should do (agre= ed changes, and in at least one case I had an "aha" that's what I think is b= eing asked for, in which case we can do that).

- Section 4.2 is titled Packets and Messages, but is about Multiplexer. Take= under advisement, can see both sides of that. Hope when we've done everythi= ng else what's best will be clear.

- Section 4.4 "An unmodified extension to NHDP would ignore such addresses" B= e clear that ignoring if just present. Don't ignore if address has TLVs rout= er is using. Also be clearer up front in this paragraph that discussing case= in final sentence.

- Section 4.5. Some words up front as to why this material is here.

- Read through document to check if clear where advice is for protocol desig= ner, and where is for protocol implementer. The former is our main emphasis,= though comments about parsing are the latter.

- Words up front to be clear that, as well as multiplexer (and how RFC 5498 m= andates that),RFC  5444 only specifies formats; parsing (and its opposi= te - forming?) is done by protocol. An implementer may simply do this in a p= rotocol, but a natural design is a separate parser used by multiple protocol= s (e.g. NHDP and OLSRv2). Some comments are about if you choose to do latter= , especially Section 6.4 but don't leave first mention to there. But a separ= ate parser is not a requirement.

- Section 6.1 to be clear, addresses always have a head a mid and a tail. Ga= in compression advantage when head and/or tail are not empty.

- Section 6.1 " Putting addresses into a message efficiently also has to inc= lude" s/include/consider/

- Section 6.2 Be clear that analysis of NHDP and OLSRv2 shows ordering possi= ble, but the details are beyond the scope of this document.

- Section 6.3 Be clear that UNSPECIFIED is for TLVs with discrete values (us= ually specified in a registry). There is an equivalent in at least one other= case (OLSRv2 metrics).

- Section 4.2 first bullet, or elsewhere cross-referenced. Be clear (referen= ce to 5444 appendix) that the recommended approach is messages unchanged exc= ept for hop count/limit, because it enables E2E authentication, in particula= r using RFC 7182 message TLVs.

- Section 4.2 bullet 3, add comment that protocol should not produce message= that (with additional headers) would exceed MTU if sent on its own in a pac= ket. (If it does, as the multiplexer can't fragment, IP will have to, and th= at's undesirable.)

- Multiplexer adding packet sequence number, MUST be consistent (add to all p= ackets or none - for each interface and destination as it already says).
=
- Probably (if there's a suitable place to say it) note that the multiplexer= has a relationship (message transfer) with protocols that own messages. The= interaction between a protocol and any extensions is up to them, not the mu= ltiplexer.

- Change uses of extended type to full type. Add full type to Terminology, m= atching to symbolic name in RFC 5444. Check if extended type is used in othe= r RFCs, if it is, add comment that sometimes so referred to.

Somewhere be clear that routers in a MANET need to have a common understandi= ng of RFC 7182 usage, including whether by multiplexer (always for packets) o= r protocol.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
T:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, C= helmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
_____________________________________= __________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/man= et
= --Apple-Mail-FED94519-FDD8-464E-B57E-8DA92C1BC6A9-- From nobody Sun May 1 19:41:38 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008AB12D0CB for ; Sun, 1 May 2016 19:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhsP48SepN9B for ; Sun, 1 May 2016 19:41:34 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1221C12D0A8 for ; Sun, 1 May 2016 19:41:34 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id j74so227682906ywg.1 for ; Sun, 01 May 2016 19:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YPn0fFQFPUOILbogc5h4KjKbbzvaaSrpoOEWeB3iUno=; b=g+M9vntMZXAT1GkgB626IiyBa0hUCMnqgrLTTMVu1U/DqwylmQBakVf2m3uNb0dalQ zy1mOWVPsLIGvW/y86NbOeHAnG086RQewq5TL8YFB3kk80KfmQZOapzYFL3FBIQX/7zW h8K4t56MUwMYwavON1/Y6y1DA27SPhd890nd2kBtWtbiFnzDHZaS+x5I16pUHMCatA11 2avnMl8DNNEaGR65jTCNbx1+4VpPOa47FzvZ5a2TM/P19TbxPU0h45JwHIgZt1Op7P43 GrXbxPbbzrtTjUHPHXVbo/NjkqxRXbEf3apFvXjdFKjQicg/4xX5E14RVsAQYRW1zaTN 8cwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YPn0fFQFPUOILbogc5h4KjKbbzvaaSrpoOEWeB3iUno=; b=mEcAzX361cTr/OXa6Hyg4pulBHBYOPk7+SF5ZPMP45ukx9qJFBj5dCJRM5WmQBiP0D mrSYaVUsOgl/Pb1I6tHczj3BST+WSVoZ6eOoJ6mkI0C5gfCgKngBPKI+TA6HEXVFOYiP NPru7Au9sQZe6BqyR2HfuHR+NT+bISLWehvUUWKg9IgisPHzXCbEqmV40wIkHXnYIbly KwxNUSr8q4qbTyEGIqJmvyuttCf51raU3q3GWeY59luHdCo1O37ojMst/HVNLg2AN6m9 IgJoR58lwY4qxGuL3D0/p9sJoj3lsOb9AZyfabAwhPZ77AUCXc23wwoK32hGpAOmzdUf zU7g== X-Gm-Message-State: AOPr4FXMgszx2h4DrU+LGxLgiajSfrnSmFcOi0srH2A19woiaJhKshLJIZABb3H/dGonvYi6Wjg6zfynCTrUsw== MIME-Version: 1.0 X-Received: by 10.159.40.133 with SMTP id d5mr18431603uad.13.1462156893232; Sun, 01 May 2016 19:41:33 -0700 (PDT) Received: by 10.176.65.40 with HTTP; Sun, 1 May 2016 19:41:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 May 2016 03:41:33 +0100 Message-ID: From: Victoria Mercieca To: Ulrich Herberg Content-Type: multipart/alternative; boundary=94eb2c1228d03a26890531d2ee22 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Symmetric link metrics (was: Re: Message integrity and message mutability) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 02:41:37 -0000 --94eb2c1228d03a26890531d2ee22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ulrich, Thank you for your review. I noticed you mentioned metrics again, so I had a further think about this. Since we are requesting a route from OrigAddr to TargAddr, we want the metric to be optimised in that direction, so we are currently adding incoming link costs at each hop of the RREQ's path, so that RREP_Gen will learn a route to OrigPrefx that represents the best path in the direction from OrigAddr to TargAddr, and will forward the RREP back along the reverse of that best path. However, this does mean that the metric learned at RREP_Gen for the route to OrigPrefix is for the wrong direction - it's the cost we actually want to install at RREQ_Gen on the route to TargPrefix. I think we may need to accumulate metrics for both directions in the RREQ, updating at each hop. This allows two things: - RREP_Gen can choose to install the best route back to OrigAddr based on the outgoing metrics backwards along the route of the RREQ - RREP_Gen can send the RREP backwards via the routers which had the best incoming cost in the RREQ (this info would be in the Multicast Route Message Table), rather than along the installed route to OrigPrefix, which could be different. Then in the RREP, we still need to include the incrementing metric value to add up the metrics of each hop looking back toward TargPrefix. So RREQ_Gen and all intermediate routers learn the cost in the direction OrigAddr->TargAddr. Should we include a metric value OrigMetric associated with OrigPrefix to indicate the real cost of the path backwards to OrigPrefix, and another metric TargMetric associated with TargAddr to indicate the accumulated cost in the direction from OrigAddr towards TargAddr? At RREP_Gen, install a route to OrigPrefix with OrigMetric. Then, since TargMetric represents the cost of the path from Orig->Targ, use the Multicast Route Message Table (which will store the RREQ with the lowest TargMetric), and decide to send the RREP via the neighbor which advertised the lowest TargMetric? Kind regards, Victoria. On Tue, Apr 26, 2016 at 3:39 AM, Ulrich Herberg wrote= : > Yes, something along that line. But I'd have to review the precise > updates required to the draft. > > Best regards > Ulrich > > On Mon, Apr 25, 2016 at 10:21 AM, Victoria Mercieca > wrote: > > Hi Ulrich, > > > > Do we just need to add up link costs looking backwards to where the > message > > came from? Back toward OrigAddr in a RREQ, back toward TargAddr in a > RREP? > > Each intermediate hop adds the cost of the link from itself back to the > last > > router which forwarded the message. > > > > At RREP_Gen we would end up with the route cost looking in the correct > > direction from RREP_Gen back to OrigAddr, along the reverse of the rout= e > the > > RREQ took (although that's not necessarily the optimal route to > OrigAddr), > > and at RREQ_Gen we would get the route cost along the optimal route whi= ch > > the RREQ travelled on, from RREQ_Gen to TargAddr. > > > > Kind regards, > > Victoria. > > > > On Mon, Apr 25, 2016 at 4:51 PM, Ulrich Herberg > wrote: > >> > >> Hi, > >> > >> I am in the process of reviewing the AODVv2 draft, and like Thomas, I > >> was surprised about your conclusion to move "asymmetric links" out of > >> scope of AODVv2. Most (if not all) wireless networks that I have seen > >> include asymmetric links. I don't think it's a good idea moving this > >> out of the protocol. > >> > >> Best regards > >> Ulrich > >> > >> On Mon, Apr 25, 2016 at 7:18 AM, wrote: > >> >[...] > >> > Since we=E2=80=99re discussing bi-directionality of links here, and = the > >> > necessity of > >> > a mechanism for handling these, I want to call attention to a relate= d > >> > issue, > >> > as I hinted previously. > >> > > >> > The abstract states that the protocol: > >> > > >> > ...is intended for use by mobile routers in wireless, multihop > >> > networks. > >> > > >> > > >> > Section 5 paragraph 4 of the document, however, reads: > >> > > >> > Assuming link metrics are symmetric, the cost of the routes > installed > >> > in the Local Route Set at each router will be correct. While thi= s > >> > assumption is not always correct, calculating incoming/outgoing > >> > metric data is outside of scope of this document. > >> > > >> > > >> > I do not know of any wireless systems, where the assumption that =E2= =80=9Clink > >> > metrics are symmetric=E2=80=9D actually holds. Consequently, the con= clusion in > >> > the > >> > quoted paragraph: > >> > > >> > > >> > calculating incoming/outgoing > >> > metric data is outside of scope of this document. > >> > > >> > > >> > Is not an acceptable design choice. > >> > > >> > While this protocol may not want to =E2=80=9Ccalculate if for this l= ink the > >> > metrics > >> > is 4 or 5=E2=80=9D, the protocol must be able to convey and distingu= ish that > >> > =E2=80=9Cthe > >> > metric from A to B is 4, and the metric from B to A is 19=E2=80=9D. > >> > > >> > This is a =E2=80=9Crelated issue=E2=80=9D since the solution may (as= with the > >> > bi-directionality check) be in the triggered neighbour detection > >> > mechanism: > >> > that exchange could, if designed carefully, be used to probe for and > >> > convey > >> > metrics information, also. > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > > --94eb2c1228d03a26890531d2ee22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ulrich,=C2=A0

Thank you for your rev= iew. I noticed you mentioned metrics again, so I had a further think about = this.

Since we are requesting a route from OrigAddr to T= argAddr, we want the metric to be optimised in that direction, so we are cu= rrently adding incoming link costs at each hop of the RREQ's path, so t= hat RREP_Gen will learn a route to OrigPrefx that represents the best path = in the direction from OrigAddr to TargAddr, and will forward the RREP back = along the reverse of that best path. However, this does mean that the metri= c learned at RREP_Gen for the route to OrigPrefix is for the wrong directio= n - it's the cost we actually want to install at RREQ_Gen on the route = to TargPrefix. =C2=A0

I think we may need to accum= ulate metrics for both directions in the RREQ, updating at each hop. This a= llows two things:
- RREP_Gen can choose to install the best route= back to OrigAddr based on the outgoing metrics backwards along the route o= f the RREQ
- RREP_Gen can send the RREP backwards via the routers= which had the best incoming cost in the RREQ (this info would be in the Mu= lticast Route Message Table), rather than along the installed route to Orig= Prefix, which could be different.=C2=A0

Then in th= e RREP, we still need to include the incrementing metric value to add up th= e metrics of each hop looking back toward TargPrefix. So RREQ_Gen and all i= ntermediate routers learn the cost in the direction OrigAddr->TargAddr.<= /div>

Should we include a metric value OrigMetric associ= ated with OrigPrefix to indicate the real cost of the path backwards to Ori= gPrefix, and another metric TargMetric associated with TargAddr to indicate= the accumulated cost in the direction from OrigAddr towards TargAddr? At R= REP_Gen, install a route to OrigPrefix with OrigMetric. Then, since TargMet= ric represents the cost of the path from Orig->Targ, use the Multicast R= oute Message Table (which will store the RREQ with the lowest TargMetric), = and decide to send the RREP via the neighbor which advertised the lowest Ta= rgMetric?

Kind regards,
Victoria.
<= div>

On Tue, Apr 26, 2016 at 3:39 AM, Ulrich Herberg = <ulrich@herberg= .name> wrote:
Yes, somethin= g along that line. But I'd have to review the precise
updates required to the draft.

Best regards
Ulrich

On Mon, Apr 25, 2016 at 10:21 AM, Victoria Mercieca
<vmercieca0@gmail.com> wr= ote:
> Hi Ulrich,
>
> Do we just need to add up link costs looking backwards to where the me= ssage
> came from? Back toward OrigAddr in a RREQ, back toward TargAddr in a R= REP?
> Each intermediate hop adds the cost of the link from itself back to th= e last
> router which forwarded the message.
>
> At RREP_Gen we would end up with the route cost looking in the correct=
> direction from RREP_Gen back to OrigAddr, along the reverse of the rou= te the
> RREQ took (although that's not necessarily the optimal route to Or= igAddr),
> and at RREQ_Gen we would get the route cost along the optimal route wh= ich
> the RREQ travelled on, from RREQ_Gen to TargAddr.
>
> Kind regards,
> Victoria.
>
> On Mon, Apr 25, 2016 at 4:51 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
>>
>> Hi,
>>
>> I am in the process of reviewing the AODVv2 draft, and like Thomas= , I
>> was surprised about your conclusion to move "asymmetric links= " out of
>> scope of AODVv2. Most (if not all) wireless networks that I have s= een
>> include asymmetric links. I don't think it's a good idea m= oving this
>> out of the protocol.
>>
>> Best regards
>> Ulrich
>>
>> On Mon, Apr 25, 2016 at 7:18 AM,=C2=A0 <ietf@thomasclausen.org> wrote:
>> >[...]
>> > Since we=E2=80=99re discussing bi-directionality of links her= e, and the
>> > necessity of
>> > a mechanism for handling these, I want to call attention to a= related
>> > issue,
>> > as I hinted previously.
>> >
>> > The abstract states that the protocol:
>> >
>> >=C2=A0 =C2=A0 ...is intended for use by mobile routers in wire= less, multihop
>> >=C2=A0 =C2=A0 networks.
>> >
>> >
>> > Section 5 paragraph 4=C2=A0 of the document, however, reads:<= br> >> >
>> >=C2=A0 =C2=A0 Assuming link metrics are symmetric, the cost of= the routes installed
>> >=C2=A0 =C2=A0 in the Local Route Set at each router will be co= rrect.=C2=A0 While this
>> >=C2=A0 =C2=A0 assumption is not always correct, calculating in= coming/outgoing
>> >=C2=A0 =C2=A0 metric data is outside of scope of this document= .
>> >
>> >
>> > I do not know of any wireless systems, where the assumption t= hat =E2=80=9Clink
>> > metrics are symmetric=E2=80=9D actually holds. Consequently, = the conclusion in
>> > the
>> > quoted paragraph:
>> >
>> >
>> >=C2=A0 =C2=A0 calculating incoming/outgoing
>> >=C2=A0 =C2=A0 metric data is outside of scope of this document= .
>> >
>> >
>> > Is not an acceptable design choice.
>> >
>> > While this protocol may not want to =E2=80=9Ccalculate if for= this link the
>> > metrics
>> > is 4 or 5=E2=80=9D, the protocol must be able to convey and d= istinguish that
>> > =E2=80=9Cthe
>> > metric from A to B is 4, and the metric from B to A is 19=E2= =80=9D.
>> >
>> > This is a =E2=80=9Crelated issue=E2=80=9D since the solution = may (as with the
>> > bi-directionality check) be in the triggered neighbour detect= ion
>> > mechanism:
>> > that exchange could, if designed carefully, be used to probe = for and
>> > convey
>> > metrics information, also.
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet<= br> >
>

--94eb2c1228d03a26890531d2ee22-- From nobody Mon May 2 08:44:28 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB0612D57C for ; Mon, 2 May 2016 08:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fapl94WyERZ for ; Mon, 2 May 2016 08:44:24 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40D612B038 for ; Mon, 2 May 2016 08:44:23 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id g133so258206010ywb.2 for ; Mon, 02 May 2016 08:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Yj9vFuWEzlxAAaXvojaTJmjooN45i0QetIv4PGoOXk4=; b=cZKIibCpc2g5HRLwI9MbvIieq803IAgbvc4FGxq1xpMqyRE3TojT/BQITeMNvrj45F WxIjb5Yr+uoeHA4l9FHqZr+4ERh4anOmLeZ3wGKS/KVTcEsB1DlGqwujamLdkojpvYvg z4u/RJH7yfKDQe1MHv9GVaeAEoWETDNqdqrEYLgND3WLkKYw4Aa5gyBiqfXBH2+p+7on qjGWVFul0cRLax6UvVHkl+5rtrcy63AIJIl82KfOlRdefKewZXex68UUiWNhKrlCRst3 lfkh5rBSzxpt9GMPWUtAOrsg18DkKxzMvbO4DEOgUPHRgarrspqDW8BGtRzjr73t/whB b84Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Yj9vFuWEzlxAAaXvojaTJmjooN45i0QetIv4PGoOXk4=; b=Glo40YXPa8QjRZO1J0to0MFHTeiQ2w5oI+rcoev/rXbIjotR1Ky4qxXkcDjOt23kJK zIYjEgdlW2Q53lshwVYlhn9wT4oTl7K5zPj/W4VOlN9NaiRJpummzy0MngPz7QMn4xli vrbPXICzhWnKxjxK1T3L23YoRq6lR4uXq8aI73pzrn/EuIDc/gONTOLEuJdlTgVY1Z0O p+JTjLZcL97L2m7PDx1kaRJVHMFdkMTd2pwjZAyRcVALyc5d72qkTvA+S6OSV+93i+M+ j8HkEFMlWrqwn0MfMyvcwJeUwu5wnVILiceTg6Oy/RjYYWCEOWoNc1erBXN1IdTX9tw/ o6iw== X-Gm-Message-State: AOPr4FUujYdBZTdRCX5reAgON2rq76159toHlPxHgdqQHokUxW09l0s+/wqNd4PJ9BjeZtM2OAtdacWUp4rACg== MIME-Version: 1.0 X-Received: by 10.176.1.45 with SMTP id 42mr20083937uak.65.1462203863068; Mon, 02 May 2016 08:44:23 -0700 (PDT) Received: by 10.31.92.134 with HTTP; Mon, 2 May 2016 08:44:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 May 2016 11:44:23 -0400 Message-ID: From: Justin Dean To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=001a11351d9ed8fb0e0531dddde2 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] draft-ietf-manet-smf-sec-threats -- could someone nudge the process a bit? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 15:44:26 -0000 --001a11351d9ed8fb0e0531dddde2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable An oversite that the writeup was completed. Confirming with Stan that this is his understanding as well. Will likely move it out today. Justin On Sat, Apr 30, 2016 at 10:42 AM, wrote: > Hi, > > WGLC completed, and the shepherd submitted his document writeup for this > document on *April 14, 2016*. > > I believe that a publication request by the chairs would be next =E2=80= =94 any > chance that that could happen shortly? If not, what=E2=80=99s the hold-up= ? > > Thanks, > > Thomas > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11351d9ed8fb0e0531dddde2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
An oversite that the writeup was completed.=C2=A0 Confirmi= ng with Stan that this is his understanding as well.=C2=A0 Will likely move= it out today.

Justin

On Sat, Apr 30, 2016 at 10:42 AM, <<= a href=3D"mailto:ietf@thomasclausen.org" target=3D"_blank">ietf@thomasclaus= en.org> wrote:
Hi,

WGLC completed, and the sh= epherd submitted his document writeup for this document on April 14, = 2016.

I believe that a publication request= by the chairs would be next =E2=80=94 any chance that that could happen sh= ortly? If not, what=E2=80=99s the hold-up?

Thanks,=

Thomas


____________= ___________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a11351d9ed8fb0e0531dddde2-- From nobody Mon May 2 09:01:11 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9FD12D161 for ; Mon, 2 May 2016 09:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE_TAucc9jF2 for ; Mon, 2 May 2016 09:01:08 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D1F12D098 for ; Mon, 2 May 2016 09:01:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9FB20480151; Mon, 2 May 2016 09:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1462204868; bh=+83JysAqdm+zu9vaoX1rTwCkjeZdZZptDdktPMUTKOQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Ya+bIZe3rC8AejPNsv5qlVnKFEKjd5NLKYgkGIG/qqrCYMSPjjW/LcEL0TJ348X9U /6eHDQekxpK4pnYWC/WDSFsOkq9U1Q20eKzn+JclxWQElxAqdWEfjx4s4AXHB4huHW kIjtZ12EDcT63vBanBnx7J5s0dwb+GHUc9532Hkw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.246] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 42BBD48013F; Mon, 2 May 2016 09:01:08 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C853DFAD-6A59-4E68-B7FF-2346FCA606FA Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (13F51a) In-Reply-To: Date: Mon, 2 May 2016 18:01:05 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3D8BD624-1B46-4855-85C0-518D613391B8@thomasclausen.org> References: To: Justin Dean Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] draft-ietf-manet-smf-sec-threats -- could someone nudge the process a bit? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 16:01:10 -0000 --Apple-Mail-C853DFAD-6A59-4E68-B7FF-2346FCA606FA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Sent from my iPad > On 02 May 2016, at 17:44, Justin Dean wrote: >=20 > An oversite that the writeup was completed. Confirming with Stan that thi= s is his understanding as well. Will likely move it out today. >=20 > Justin >=20 >> On Sat, Apr 30, 2016 at 10:42 AM, wrote: >> Hi, >>=20 >> WGLC completed, and the shepherd submitted his document writeup for this d= ocument on April 14, 2016. >>=20 >> I believe that a publication request by the chairs would be next =E2=80=94= any chance that that could happen shortly? If not, what=E2=80=99s the hold-= up? >>=20 >> Thanks, >>=20 >> Thomas >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail-C853DFAD-6A59-4E68-B7FF-2346FCA606FA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thank you

Sent from my iPad

On 02 May 2016, at 17:44, Justin Dean <bebemaster@gmail.com> wrote:

An oversite that the writeup was compl= eted.  Confirming with Stan that this is his understanding as well.&nbs= p; Will likely move it out today.

Justin

On Sat, Apr 30, 2016 at 10:42 AM, <i= etf@thomasclausen.org> wrote:
Hi,

WGLC completed, a= nd the shepherd submitted his document writeup for this document on Ap= ril 14, 2016.

I believe that a publication r= equest by the chairs would be next =E2=80=94 any chance that that could happ= en shortly? If not, what=E2=80=99s the hold-up?

Tha= nks,

Thomas


_________= ______________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


= --Apple-Mail-C853DFAD-6A59-4E68-B7FF-2346FCA606FA-- From nobody Mon May 2 10:08:13 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AE512D5A7; Mon, 2 May 2016 10:08:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160502170812.15728.59693.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 10:08:12 -0700 Archived-At: Cc: manet-chairs@ietf.org, manet@ietf.org, draft-ietf-manet-rfc6779bis@ietf.org, chris.dearlove@baesystems.com Subject: [manet] Last Call: (Definition of Managed Objects for the Neighborhood Discovery Protocol) to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 17:08:12 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Definition of Managed Objects for the Neighborhood Discovery Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-05-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document revises, extends, and replaces RFC 6779. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6779bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6779bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon May 2 22:17:14 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9283A12D1BC for ; Mon, 2 May 2016 22:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lpDgdugCYU2 for ; Mon, 2 May 2016 22:17:09 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4A912D537 for ; Mon, 2 May 2016 22:17:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RicsWkcf/P5n3LjP4Lu+Z+yREuCqzbh4rg8Vo9OG3EYj2V9bA7FTXm/2/BtaggRr; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.67]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1axShZ-0002OQ-EY; Tue, 03 May 2016 01:16:53 -0400 To: Jiazi YI , manet References: From: Charlie Perkins Message-ID: <0e7fb67e-2711-9912-7e97-e2a54d0bf8ed@earthlink.net> Date: Mon, 2 May 2016 22:16:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------72C9FF9D8A674F28E42F3841" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac78d64d86839a2839e3c0eaa9ce74ae272350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [manet] draft-ietf-manet-aodvv2-15 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 05:17:12 -0000 This is a multi-part message in MIME format. --------------72C9FF9D8A674F28E42F3841 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello Jiazi, A bit of follow-up below... On 4/28/2016 7:53 AM, Jiazi YI wrote: > Hi, > > Here is my preliminary review on aodvv2-15. There are still some > points that I'm not sure that I have fully understood -- I will get > back to them if I had time. > > A summary of my review: > > 1. The specification lacks of a "big picture" of the protocol > functioning. People prefer to have a general idea of the whole > protocol at the very beginning. This is particularly important for > readers who are not familiar with reactive protocol in general. > Some of the sections can be reorganized a bit to improve the > readability. For example, with the current structure, the readers need > to reach section 6.6 (Route discovery) before they can really touch > the core function of the protocol. As with many documents, there is a need to establish definitions and data structures before specifying the details of the control protocol interactions. > > 2. As an experimental protocol, the part related to experiments needs > to be improved. IMO, at least the following information must be provided: > - The motivation of this experimental document > - The experiments to be conducted > - What kind of feedback is expected to reported. We will provide some indication for useful experiments. > > > 3. There are some redundant processing procedures in the draft. On the > other hand, some connections between the sections seem to be missing. > Sometimes it's hard to build connection between the message processing > and related information bases. If you could be more specific, that would help. I know that there has been a lot of effort to provide exactly this kind of continuity, so I don't know what is missing. > > 4. The specification uses lots of multicast messages. While multicast > RREQ is inevitable, the necessity of multicast RREP/RERR is not clear. > It bring issues related to control message overhead and security. Multicast RERR is useful when many precursors need to receive the message ASAP. The justification for multicast RREP is more detailed, but I think on this point there is definitely room for discussion. Even for multicast RERR, serial unicast is preferable whenever the number of precursors is small. > > 5. The interaction with RIB: The route state maintenance requires > "/LocalRoute.State MUST be checked before IP packet forwarding and > before any operation based on LocalRoute.State./". Having such check > for each data packet might be heavy load for the system if the routing > daemon runs in userspace (because of context switch). While > interaction with RIB is inevitable, we want to reduce it as much as > possible -- per data packet operation is too much. This is an implementation detail. Systems can be built with RIB and FIB co-located, which would be my preference. > > 6. There are too many "MAY" and "SHOULD" in the document without > elaboration. Some of which might cause interoperability issues or even > loops. Do you suggest an elaboration after every single RFC 2119 term? > Please check the details inline: > > *section 1, overview* > > The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol > enables dynamic,*self-starting*, multihop routing > > > The term "self-starting" is very vague. It makes people think of > auto-configuration. And I didn't see such kind of feature is > supported. I would avoid using it. The protocol is indeed self-starting, and previous commenters never suggested confusion with auto-configuration. I can't think of another term that denotes that the routing table is built dynamically without necessarily requiring any preconfigured route table entries. Can you suggest a better term? > > AODVv2 is an Experimental protocol. > ... > > I think much more information is required here: > > 1) Because RFC 3561 has already been experimented for 13 years, as its > version 2, AODVv2 should summarize what kind of experiences have been > obtained in the past 13 years, and justify the design choices made in > the current draft (like use of RFC5444, removing some of the features, > etc) I never heard of a rule like this - that if a protocol is going to Experimental, we need to describe the experiments that have already been done. However, the use of RFC 5444 was not justified by any experiment, but instead mandated by RFC 5498. I am surprised that you request justification for removing the features, since you were among the people who requested removing them. This was done to satisfy that request. > > 2) The motivation and experiments to be conducted need to be > elaborated. It's even necessary to have a separate section/subsection > for it. Some experiment points that come to my mind without much > thinking: support of multiple interfaces, support of gateways, use of > different metrics, the security model, etc.. These are reasonable experiments and should be mentioned in a section for that purpose. > > The basic operations of the AODVv2 protocol are route discovery and > route maintenance... > > > It's necessary to give an overview of the basic functioning of the > protocol, rather than simply saying "use RREQ/RREP to carry > information and build routes". Because after this, the draft jumps > directly into the protocol details. > It's extremely important for the readers who are not familiar with > reactive protocol. Which aspects of reactive protocol operation do you think should be mentioned? Perhaps the longer the description gets, the less likely it is that people will read and digest it. > > *section 2, Terminology* > > Please pay attention to the style of the terms. Most of the time, > style like AckReq is used, but sometimes RERR_Gen is used. > Good to be consistent. > > Unreachable Address > An address reported in a Route Error message, as described in > Section 7.4.1. > > > need to explain what's the address for exactly, rather than giving a > pointer to a big section. It seems difficult to imagine that someone would see the term "Unreachable Address" and be unable to determine that the address would be used in the Route Error message to notify other AODVv2 nodes that the address is unreachable. That is exactly what the address is used for, and seems intuitive to me. Do you have any suggestion about how to remedy the lack? > > *section 3, applicability statement* > * > * > > AODVv2 handles a wide variety of mobility and traffic patterns by > determining routes on-demand... > > > It necessary to explicitly call out what kind of traffic patterns that > reactive protocols are not suitable for, such as lots of routers send > data packets to instantaneous and multiple destinations. If that > happens, what's the consequence (broadcasting storm, etc). We can mention that AODVv2 supports traffic patterns for there are a lot of source/destination pairs that do not need routes to each other. Sending data to multiple destinations at the same time sounds like multicast, which is out of scope. I don't know about instantaneous destinations...? > The routing algorithm in AODVv2 MAY be operated at layers other > than > the network layer, using layer-appropriate addresses. > > > Considering the deep coupling between AODVv2 and IP, I don't see how > it can work. This should be removed. Well, it's been done at layer 2. It was used for 802.11s. It's been done for Bluetooth. Of course in those situations you wouldn't use the IP address, but that's a pretty simple translation to make. > > > 4.2 router client set > > RouterClient.Cost > The cost associated with reaching this address or address range. > > > Both "metric" and "cost" are used in the draft. If they are the same, > please pick a term and use it consistently. They are not the same. Some people have been using metrics that measure benefit, not cost. I don't like those metrics, myself. Both terms are needed. > > The AODVv2 router adding the Router Client MUST wait for > any existing routing information about this Router Client to be > purged from the network, i.e., at least MAX_SEQNUM_LIFETIME > since the > last SeqNum update on the router which is removing this Router > Client. > > > I'm not sure that I parsed this sentence correctly, but the > adding/removing of router client seems to be more an external > operation and out of the control of routing protocol itself. It's just the routing information about the client in other places of the network, not anything related to an external operation. Is there something specific that is confusing here? > > 4.3 neighbor set > > > Neighbor.State ... There are three possible states: Confirmed, > Unknown, and > Blacklisted. Unknown is the initial state. > > > I think the "Unknown" is a bit confusing here. It's actually something > we already know -- a state that "we heard from that node, but > bi-directionality is not confirmed". > I think "Heard" is a more appropriate term to be used here. That's O.K. with me - perhaps other people have some feedback here...? > > 4.4 sequence numbers > > I think the comparison in wrap-around cases should be specified here. Doesn't it work just to describe how subtraction works? If the wrap-around cases are not exceptions, do they really need to be specified? To me that sounds like a long and uninformative rathole. > > 4.5 Local route set > > > Alternatively, implementations > MAY choose to modify the Routing Information Base directly. > > > This should be either more precise (in which condition, how we can > modify the RIB?), or be removed. I think this is an attempt to point out that there are a lot of implementation strategies. > > Multiple valid routes for the same address and prefix length > but for > different metric types may exist in the Local Route Set, but the > decision of which of these routes to install in the Routing > Information Base to use for forwarding is outside the scope of > AODVv2. > > > It's OK, but maybe some rules must be specified and followed. For > example, the metric used must be the same: if a packet is forwarded > using metric A at router X, and then metric B at router Y, it's a > obvious source of loops. I don't think this is possible for monotonically increasing metrics. > > 4.6. Multicast Route Message Set > > Since this set is mainly for duplicate packet detection, I think some > of the fields are kind of redundant. For example, an RREQ/RREP message > can be identified by its originator's address and sequence number, why > 6 fields (OrigAddr, OrigFprefixLen, OrigSeqNum, TargAddr, > TargPrefixLen, TargSeqNum) are necessary here. Because the originator can have two route discovery operations happening at the same time. > > *section 5 Metrics* > * > * > > In Route Request messages, the metric describes the cost of the > route > from OrigAddr (and any other addresses included in the prefix > length > of RREQ_Gen's Router Client entry for OrigAddr) to the router > sending > the Route Request. > > > So the metric carried in the RREQ is the metric from Router Client to > the RREQ_Gen plus the metric from RREQ_Gen to the intermediate router. > In the Router Client Set, we have only one field for > RouterClient.Cost. On the other hand, "AODVv2 supports different > metrics". > > routerClient.cost AODVv2 metric > client-----------------------RREQ_gen--------------- > > What if those two metrics are of different types? This is quite > possible because the two links might use different medium. We should indeed allow for multiple metric types for any particular Router Client. The quoted passage does not specifically prevent that, but I agree it should be made clearer. > > > > section 6.2 (Next hop monitoring) and section 6.3 (Neighbor set > update) are very related. One is about the function, and one is about > the corresponding operation. The following sections don't follow this > pattern -- why not making them to one? This is worthwhile to explore, but I am not sure it could be done and finished this week. Anyway, different people might like different organizations and the one in the draft is not wrong. Could we put this as a second priority and look at it a little later? > > section 6.7.1 (Evaluating route information) and section 6.8 > (Suppressing redundant messages using Multicast Route message set) > seem to have some overlapped operations. They all need to check the > uniqueness of the messages, compare the metrics and stop processing > when duplication is detected. Although they are applied to different > information bases, they are doing the same thing. There is a certain amount of overlap because there aren't all that many data elements to start with. However, trying to structure an algorithm to use the minimum number of lines of code can start to make spaghetti code which is even harder to understand. The purposes are different enough that I don't agree they are doing the same thing. If this is not clear, then I can try to make an example but that would take another hour that I don't have until later this week. > > section 6.9 (suppressing redundant RERR messages using the Route Error > set) should obviously a part of section 6.10.2 (reporting invalid > routes), but it's a separate section with higher hierarchy. > > more details inline: > > If such an entry does not exist, a new entry is created as > described > in Section 6.3. *While the value of Neighbor.State is Unknown, > acknowledgement of RREP messages sent to that neighbor MUST be > requested*. ... > > > I think we need to precise this is one for the case of RREP transmission. Sounds reasonable, thanks! > > section 6.5. Message Transmission > > > To implement the congestion control, a queue length is set. If the > queue is full, in order to queue a new message, a message of lower > priority must be removed from the queue. If this is not possible, > the new message MUST be discarded. The queue should be sorted in > order of message priority. > > > I think it's more implementation details rather than specification. We were requested to specify this. I agree it is implementation detail and that should be made clear. > section 6.7.1 > > 4. Compare route costs > * If AdvRte is better than all matching LocalRoutes, it SHOULD > be used to update the Local Route Set because it offers > improvement. *If it is not used to update the Local > Route Set, > the existing non-optimal LocalRoute will continue to be > used, > causing data traffic to use a non-optimal route.* > > > If some routers made the update, and some routers choose not updating, > I'm afraid there will be loops in the network. A route that was previously loop free does not suddenly become a looping route in this situation. I'll try to respond to the rest of your comments tomorrow. Thanks for the careful review. Regards, Charlie P. --------------72C9FF9D8A674F28E42F3841 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hello Jiazi,

A bit of follow-up below...


On 4/28/2016 7:53 AM, Jiazi YI wrote:
Hi, 

Here is my preliminary review on aodvv2-15. There are still some points that I'm not sure that I have fully understood -- I will get back to them if I had time. 

A summary of my review:

1. The specification lacks of a "big picture" of the protocol functioning. People prefer to have a general idea of the whole protocol at the very beginning. This is particularly important for readers who are not familiar with reactive protocol in general. 
Some of the sections can be reorganized a bit to improve the readability. For example, with the current structure, the readers need to reach section 6.6 (Route discovery) before they can really touch the core function of the protocol.

As with many documents, there is a need to establish definitions and data structures before specifying the details of the control protocol interactions.


2. As an experimental protocol, the part related to experiments needs to be improved. IMO, at least the following information must be provided:
       - The motivation of this experimental document 
       - The experiments to be conducted 
       - What kind of feedback is expected to reported.

We will provide some indication for useful experiments.



3. There are some redundant processing procedures in the draft. On the other hand, some connections between the sections seem to be missing. Sometimes it's hard to build connection between the message processing and related information bases. 

If you could be more specific, that would help.  I know that there has been a lot of effort to provide exactly this kind of continuity, so I don't know what is missing.


4. The specification uses lots of multicast messages. While multicast RREQ is inevitable, the necessity of multicast RREP/RERR is not clear. It bring issues related to control message overhead and security.

Multicast RERR is useful when many precursors need to receive the message ASAP.  The justification for multicast RREP is more detailed, but I think on this point there is definitely room for discussion.  Even for multicast RERR, serial unicast is preferable whenever the number of precursors is small.

 

5. The interaction with RIB: The route state maintenance requires "LocalRoute.State MUST be checked before IP packet forwarding and before any operation based on LocalRoute.State.". Having such check for each data packet might be heavy load for the system if the routing daemon runs in userspace (because of context switch). While interaction with RIB is inevitable, we want to reduce it as much as possible -- per data packet operation is too much.

This is an implementation detail.  Systems can be built with RIB and FIB co-located, which would be my preference.


6. There are too many "MAY" and "SHOULD" in the document without elaboration. Some of which might cause interoperability issues or even loops.

Do you suggest an elaboration after every single RFC 2119 term?

 
Please check the details inline:

section 1, overview

   The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol
   enables dynamic, self-starting, multihop routing

The term "self-starting" is very vague. It makes people think of auto-configuration. And I didn't see such kind of feature is supported. I would avoid using it.

The protocol is indeed self-starting, and previous commenters never suggested confusion with auto-configuration.  I can't think of another term that denotes that the routing table is built dynamically without necessarily requiring any preconfigured route table entries.  Can you suggest a better term?

 

  AODVv2 is an Experimental protocol.
 ...
 
I think much more information is required here:

1) Because RFC 3561 has already been experimented for 13 years, as its version 2, AODVv2 should summarize what kind of experiences have been obtained in the past 13 years, and justify the design choices made in the current draft (like use of RFC5444, removing some of the features, etc)

I never heard of a rule like this - that if a protocol is going to Experimental, we need to describe the experiments that have already been done.

However, the use of RFC 5444 was not justified by any experiment, but instead mandated by RFC 5498. I am surprised that you request justification for removing the features, since you were among the people who requested removing them.  This was done to satisfy that request.


2) The motivation and experiments to be conducted need to be elaborated. It's even necessary to have a separate section/subsection for it. Some experiment points that come to my mind without much thinking: support of multiple interfaces, support of gateways, use of different metrics, the security model, etc..

These are reasonable experiments and should be mentioned in a section for that purpose.


   The basic operations of the AODVv2 protocol are route discovery and
   route maintenance...

It's necessary to give an overview of the basic functioning of the protocol, rather than simply saying "use RREQ/RREP to carry information and build routes". Because after this, the draft jumps directly into the protocol details. 
It's extremely important for the readers who are not familiar with reactive protocol.

Which aspects of reactive protocol operation do you think should be mentioned?  Perhaps the longer the description gets, the less likely it is that people will read and digest it.


section 2, Terminology

Please pay attention to the style of the terms. Most of the time, style like AckReq is used, but sometimes RERR_Gen is used. 
Good to be consistent. 

   Unreachable Address
      An address reported in a Route Error message, as described in
      Section 7.4.1.

need to explain what's the address for exactly, rather than giving a pointer to a big section.

It seems difficult to imagine that someone would see the term "Unreachable Address" and be unable to determine that the address would be used in the Route Error message to notify other AODVv2 nodes that the address is unreachable.  That is exactly what the address is used for, and seems intuitive to me.  Do you have any suggestion about how to remedy the lack?

 

section 3, applicability statement

   AODVv2 handles a wide variety of mobility and traffic patterns by
   determining routes on-demand...

It necessary to explicitly call out what kind of traffic patterns that reactive protocols are not suitable for, such as lots of routers send data packets to instantaneous and multiple destinations. If that happens, what's the consequence (broadcasting storm, etc).

We can mention that AODVv2 supports traffic patterns for there are a lot of source/destination pairs that do not need routes to each other.  Sending data to multiple destinations at the same time sounds like multicast, which is out of scope.  I don't know about instantaneous destinations...?


 
   The routing algorithm in AODVv2 MAY be operated at layers other than
   the network layer, using layer-appropriate addresses.

Considering the deep coupling between AODVv2 and IP, I don't see how it can work. This should be removed.

Well, it's been done at layer 2.  It was used for 802.11s.  It's been done for Bluetooth.  Of course in those situations you wouldn't use the IP address, but that's a pretty simple translation to make.



4.2 router client set
   RouterClient.Cost
      The cost associated with reaching this address or address range.

Both "metric" and "cost" are used in the draft. If they are the same, please pick a term and use it consistently.

They are not the same.  Some people have been using metrics that measure benefit, not cost.  I don't like those metrics, myself.  Both terms are needed.


 
The AODVv2 router adding the Router Client MUST wait for
   any existing routing information about this Router Client to be
   purged from the network, i.e., at least MAX_SEQNUM_LIFETIME since the
   last SeqNum update on the router which is removing this Router
   Client. 

I'm not sure that I parsed this sentence correctly, but the adding/removing of router client seems to be more an external operation and out of the control of routing protocol itself.

It's just the routing information about the client in other places of the network, not anything related to an external operation.  Is there something specific that is confusing here?


4.3 neighbor set

 Neighbor.State ... There are three possible states: Confirmed, Unknown, and
      Blacklisted.  Unknown is the initial state.

I think the "Unknown" is a bit confusing here. It's actually something we already know -- a state that "we heard from that node, but bi-directionality is not confirmed". 
I think "Heard" is a more appropriate term to be used here.

That's O.K. with me - perhaps other people have some feedback here...?

 

4.4 sequence numbers

I think the comparison in wrap-around cases should be specified here.

Doesn't it work just to describe how subtraction works?  If the wrap-around cases are not exceptions, do they really need to be specified?  To me that sounds like a long and uninformative rathole.

 

4.5 Local route set

Alternatively, implementations
   MAY choose to modify the Routing Information Base directly.

This should be either more precise (in which condition, how we can modify the RIB?), or be removed.

I think this is an attempt to point out that there are a lot of implementation strategies.

 

 
   Multiple valid routes for the same address and prefix length but for
   different metric types may exist in the Local Route Set, but the
   decision of which of these routes to install in the Routing
   Information Base to use for forwarding is outside the scope of
   AODVv2.

It's OK, but maybe some rules must be specified and followed. For example, the metric used must be the same: if a packet is forwarded using metric A at router X, and then metric B at router Y, it's a obvious source of loops.

I don't think this is possible for monotonically increasing metrics.



4.6.  Multicast Route Message Set

Since this set is mainly for duplicate packet detection, I think some of the fields are kind of redundant. For example, an RREQ/RREP message can be identified by its originator's address and sequence number, why 6 fields (OrigAddr, OrigFprefixLen, OrigSeqNum, TargAddr, TargPrefixLen, TargSeqNum) are necessary here.

Because the originator can have two route discovery operations happening at the same time.


section 5 Metrics

   In Route Request messages, the metric describes the cost of the route
   from OrigAddr (and any other addresses included in the prefix length
   of RREQ_Gen's Router Client entry for OrigAddr) to the router sending
   the Route Request. 

So the metric carried in the RREQ is the metric from Router Client to the RREQ_Gen plus the metric from RREQ_Gen to the intermediate router. 
In the Router Client Set, we have only one field for RouterClient.Cost. On the other hand, "AODVv2 supports different metrics". 

          routerClient.cost             AODVv2 metric 
client-----------------------RREQ_gen---------------

What if those two metrics are of different types? This is quite possible because the two links might use different medium.

We should indeed allow for multiple metric types for any particular Router Client.  The quoted passage does not specifically prevent that, but I agree it should be made clearer.





section 6.2 (Next hop monitoring) and section 6.3 (Neighbor set update) are very related. One is about the function, and one is about the corresponding operation. The following sections don't follow this pattern -- why not making them to one?

This is worthwhile to explore, but I am not sure it could be done and finished this week.  Anyway, different people might like different organizations and the one in the draft is not wrong.  Could we put this as a second priority and look at it a little later?


section 6.7.1 (Evaluating route information) and section 6.8 (Suppressing redundant messages using Multicast Route message set) seem to have some overlapped operations. They all need to check the uniqueness of the messages, compare the metrics and stop processing when duplication is detected. Although they are applied to different information bases, they are doing the same thing.

There is a certain amount of overlap because there aren't all that many data elements to start with.  However, trying to structure an algorithm to use the minimum number of lines of code can start to make spaghetti code which is even harder to understand.  The purposes are different enough that I don't agree they are doing the same thing.  If this is not clear, then I can try to make an example but that would take another hour that I don't have until later this week.


section 6.9 (suppressing redundant RERR messages using the Route Error set) should obviously a part of section 6.10.2 (reporting invalid routes), but it's a separate section with higher hierarchy. 

more details inline:

   If such an entry does not exist, a new entry is created as described
   in Section 6.3.  While the value of Neighbor.State is Unknown,
   acknowledgement of RREP messages sent to that neighbor MUST be
   requested. ...

I think we need to precise this is one for the case of RREP transmission.

Sounds reasonable, thanks!


section 6.5.  Message Transmission

   To implement the congestion control, a queue length is set.  If the
   queue is full, in order to queue a new message, a message of lower
   priority must be removed from the queue.  If this is not possible,
   the new message MUST be discarded.  The queue should be sorted in
   order of message priority. 

I think it's more implementation details rather than specification.

We were requested to specify this.  I agree it is implementation detail and that should be made clear.

 
section 6.7.1

   4.  Compare route costs
       *  If AdvRte is better than all matching LocalRoutes, it SHOULD
          be used to update the Local Route Set because it offers
          improvement.  If it is not used to update the Local Route Set,
          the existing non-optimal LocalRoute will continue to be used,
          causing data traffic to use a non-optimal route.

If some routers made the update, and some routers choose not updating, I'm afraid there will be loops in the network.

A route that was previously loop free does not suddenly become a looping route in this situation.

I'll try to respond to the rest of your comments tomorrow.  Thanks for the careful review.

Regards,
Charlie P.

--------------72C9FF9D8A674F28E42F3841-- From nobody Tue May 3 01:57:08 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C568412D67E for ; Tue, 3 May 2016 01:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRK3YzsTlAs5 for ; Tue, 3 May 2016 01:57:05 -0700 (PDT) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4FB12D676 for ; Tue, 3 May 2016 01:57:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,571,1454976000"; d="scan'208";a="34566729" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 03 May 2016 09:56:54 +0100 X-IronPort-AV: E=Sophos;i="5.24,571,1454976000"; d="scan'208";a="116397253" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 03 May 2016 09:55:45 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Tue, 3 May 2016 09:55:44 +0100 From: "Dearlove, Christopher (UK)" To: Charlie Perkins , Jiazi YI , manet Thread-Topic: [manet] draft-ietf-manet-aodvv2-15 review Thread-Index: AQHRoV3GeekgHbAKyEufgLi2v4F5zJ+monwAgABK5HA= Date: Tue, 3 May 2016 08:55:43 +0000 Message-ID: References: <0e7fb67e-2711-9912-7e97-e2a54d0bf8ed@earthlink.net> In-Reply-To: <0e7fb67e-2711-9912-7e97-e2a54d0bf8ed@earthlink.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] draft-ietf-manet-aodvv2-15 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 08:57:07 -0000 Just one comment for now. Jiazi: > It's OK, but maybe some rules must be specified and followed. For example= , the metric used must be the same: if a packet is forwarded using metric A= at router X, and then metric B at router Y, it's a obvious source of loops. Charlie: > I don't think this is possible for monotonically increasing metrics. Simple case, A, B, C all connected. Metrics are symmetric. For metric X: AB= =3D3, AC=3DBC=3D1. For metric Y: BC=3D3, AB=3DAC=3D1. Packet source A, destination B. A uses metric X. It sees the best route as = A-C-B and forwards to C. However C is using metric Y, and sees the best rou= te as C-A-B and forwards to A. Loop. That I think is what Jiazi is meaning. Of course the metrics don't have to = be the same in that, for example, if when accumulating the route metric A -= B-C if A-B is a delay metric and B-C is a reliability metric, adding them t= ogether makes no sense and won't produce great routes, but won't loop. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From nobody Tue May 3 05:30:18 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AD512D7AB for ; Tue, 3 May 2016 05:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_FROM_MISSP_DKIM=0.01, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcxmc1PK0tgC for ; Tue, 3 May 2016 05:30:13 -0700 (PDT) Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF1212D7A9 for ; Tue, 3 May 2016 05:30:13 -0700 (PDT) Received: from turig.iit.cnr.it (turig.iit.cnr.it [146.48.98.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxbk.iit.cnr.it (Postfix) with ESMTPSA id C78D0C0C2E for ; Tue, 3 May 2016 14:30:07 +0200 (CEST) Date: Tue, 03 May 2016 14:34:01 +0200 From: Elisabetta Biondi To: manet@ietf.org Message-ID: <57289ab9.8knxcnwo0JdPm0XQ%chants16_publicity@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [manet] [ACM CHANTS 2016] Call for Papers - 4 weeks to deadline! X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:30:16 -0000 =============================================================================== =============================================================================== ACM CHANTS 2016 - 11th Workshop on Challenged Networks co-located with ACM MobiCom 2016 October 3-7, 2016, New York, USA www.acm-chants.org =============================================================================== =============================================================================== Challenged networks comprise those situations where communication is desired, but traditional Internet architectures fail to provide it effectively. Such networks may be characterized by intermittent connectivity, a heterogeneous mix of nodes, frequent nodal churn, and widely varying network conditions. Examples of challenged networks include deployments in rural and remote areas, networks to support emergency response operations, inter-planetary networks, sensor and wildlife monitoring networks, underwater networks, road vehicle networks, and, more recently, networks of micro aerial vehicles. The applications of challenged networks range from time-critical communications such as for disaster relief to delay-tolerant transmission in poorly connected regions or where censorship should be counteracted. However, challenged networking has also found many applications in everyday settings, for which they were not initially conceived, such as opportunistic networking supporting data-centric communications, traffic offloading from cellular networks, mobile cloud/edge computing, opportunistic and participatory sensing, challenged IoT. The increasing availability of wireless communications in embedded devices as well as integration of technologies such as Wi-Fi direct on Android platforms and LTE's D2D (device-to-device) communication on general purpose mobile devices, will further push the development of challenged networking solutions. Challenged networking has also chartered new directions for inter-disciplinary research, e.g., applying findings from social networks and network science. This workshop builds on the success of the ten previous CHANTS workshops, and WDTN 2005, and aims to stimulate research on the most novel topics of challenged networking research. This year's edition encourages submission of theoretical and experimental work (including studies of real deployment), with a primary interest in the **new directions of challenged networking such as mobile cloud/mobile edge computing, IoT, mobile data offloading, and challenged SDN**. The workshop seeks original work presented in the form of research papers describing new research approaches and results, as well as demo submissions. Highly disruptive work-in-progress and position papers are also welcome, provided they focus on particularly innovative, out-of-the-box, solutions or applications for challenged networks. All papers shall be forward-looking, describe their relationship to existing work, and shall argue their impact and implications for ongoing or future research. Topics of interest include, but are not limited to: - Delay/disruption-tolerant networks (DTNs), opportunistic communication and computing - Architecture, design, and implementation of communication systems for challenged networks - Modeling, analysis, and characterization of challenged networks and protocols - Challenged networking techniques for mobile cloud computing - Mobile data offloading via challenged networks - Challenged networking techniques for participatory and opportunistic sensing - Challenged networking in the Internet of Things - Big data analytics in challenged networking - Software-defined networking in challenged environments - Security/trust/privacy concerns and solutions in challenged networks - Energy-efficient communication in challenged networks - Information centric and content-centric networking in challenged networks - Real-world mobility trace collection, analysis, and modeling for challenged environments - Network science methods for challenged networks - Network coding in challenged networks - Novel challenged networking systems (e.g., networks of micro aerial vehicles) - Real deployment and case studies in various stages of use - Disrupted scenarios for challenged networks (e.g., disaster relief and emergency management) - Daily use applications (e.g., mobile social networking, crowdsourcing, censorship evasion, sensor networks, smart cities) - Test and simulation tools for evaluating challenged network systems - Configuration, management, and monitoring of challenged networks. PAPER FORMAT AND SUBMISSION INSTRUCTIONS ---------------------------------------- Submitted papers must be no longer than 6 pages, and should adhere to the standard ACM conference proceedings format. Demo proposals (to be published as part of the proceedings) must not be longer than 2 pages plus 1 page description of the precise setup and requirements (the 1-page setup description will not be published in the proceedings). Reviews will be single-blinded. Papers should neither have been published elsewhere nor being currently under review by another conference or journal. EDITORIAL FOLLOW-UPS -------------------- Extended versions of the selected workshop papers will be considered for possible fast track publication on the Computer Communications Journal (Elsevier), in a special section on Challenged Networks. IMPORTANT DATES --------------- - Abstract Registration: 25 May 2016 - Submission Deadline: 1 June 2016 - Acceptance Notification: 6 July 2016 - Camera Ready Due: 20 July 2016 PROGRAM COMMITTEE CHAIRS ------------------------ Chiara Boldrini (IIT-CNR, Italy) Marcelo Dias de Amorim (UPMC and CNRS, France) TECHNICAL PROGRAM COMMITTEE --------------------------- Kevin Almeroth (UC-Santa Barbara, USA) Mostafa Ammar (Georgia Institute of Technology, USA) Fehmi Ben Abdesslem (SICS Swedish ICT, Sweden) Guohong Cao (The Pennsylvania State University, USA) Marco Cello (Nokia Bell Labs) Vania Conan (Thales Communications & Security, France) Luis Costa (Universidade Federal do Rio de Janeiro, Brazil) Do Young Eun (North Carolina State University, USA) Kevin Fall (Carnegie Mellon University, USA) Stephen Farrell (Trinity College Dublin, Ireland) Domenico Giustiniano (IMDEA Networks Institute, Spain) Tristan Henderson (University of St Andrews, UK) Andrea Hess (Trinity College Dublin, Ireland) Pan Hui (Hong Kong Unive. of Science and Technology) Karin Anna Hummel (JKU Linz, Austria) Mohan Kumar (Rochester Institute of Technology, USA) Kyunghan Lee (UNIST, Korea) Anders Lindgren (SICS Swedish ICT, Sweden) Mirco Musolesi (University College London, UK) Katia Obraczka (UC Santa Cruz, USA) Melek Onen (Eurecom, France) Joerg Ott (Technische Universitat Munchen, Germany) Elena Pagani (Universita degli Studi di Milano, Italy) Andrea Passarella (IIT-CNR, Italy) Eric Rozner (IBM Research, USA) Pavlos Sermpezis (FORTH, Greece) Thrasyvoulos Spyropoulos (Eurecom, France) Stavros Toumpis (Athens University of Economics and Business, Greece) Thierry Turletti (INRIA, France) Yu Wang (University of North Carolina at Charlotte, USA) Eiko Yoneki (University of Cambridge, UK) Xiaolan Zhang (Fordham University, USA) WEB CHAIR --------- Fehmi Ben Abdesslem (SICS Swedish ICT, Sweden) PUBLICITY CHAIR --------------- Elisabetta Biondi (IIT-CNR, Italy) STEERING COMMITTEE ------------------ Kevin Almeroth (UC Santa Barbara, USA) Kevin Fall (Carnegie Mellon University, USA) Stephen Farrell (Trinity College Dublin, Ireland) Jorg Ott (Technische Universitat Munchen, Germany) Andrea Passarella (IIT-CNR, Italy) From nobody Tue May 3 07:03:40 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFFC12D80A for ; Tue, 3 May 2016 07:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk_iLbvWIICN for ; Tue, 3 May 2016 07:03:30 -0700 (PDT) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93B612D50F for ; Tue, 3 May 2016 07:03:24 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,572,1454976000"; d="scan'208,217"; a="34613600" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 03 May 2016 15:03:22 +0100 X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208,217";a="116484628" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 03 May 2016 15:03:23 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Tue, 3 May 2016 15:03:22 +0100 From: "Dearlove, Christopher (UK)" To: Lotte Steenbrink , manet Thread-Topic: [manet] AODVv2 responses to recent comments Thread-Index: AQHRUjmenBx9hbwuBk28hYSwiXsxV58C1pBAgEEypICAAjAlcIAWcFWAgEZE/gCABPKvQA== Date: Tue, 3 May 2016 14:03:21 +0000 Message-ID: References: <56D4EB7D.4010002@earthlink.net> <944B9E01-74B7-45AD-ACB8-FA79347BC22E@fu-berlin.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2C5CGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] AODVv2 responses to recent comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:03:39 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2C5CGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gc3RpbGwgcGllY2luZyB0b2dldGhlciBmcmFnbWVudGFyeSBpbmZvcm1hdGlvbi4gQnV0 IEkgYmVsaWV2ZSB0aGF0IHRoaXMgd2FzIGEgc2Vjb25kIHJlYXNvbiBmb3IgbG9vcGluZyAodGhl IGZpcnN0IGJlaW5nIGEgcmF0aGVyIHN0cmFuZ2UgaW50ZXJwcmV0YXRpb24gdGhhdCB3YXMgZWFz aWx5IGRpc2NvdW50ZWQsIGFuZCBtYWRlIGV4cGxpY2l0bHkgbm90IGFsbG93ZWQsIHRoaXMgaXMg bm90IGFib3V0IHRoYXQpLg0KDQpUaGlzIHdhcyBzb21lIHByb2JsZW0gdG8gZG8gd2l0aCBtdWx0 aXBsZSB1bmNvbmZpcm1lZCBlbnRyaWVzLiBXaGljaCB0aGUgYXV0aG9ycyBtYWRlIGltcG9zc2li bGUgYnkgcmVtb3ZpbmcgdGhhdCBmZWF0dXJlLiBCdXQgd2l0aG91dCBkaXNjdXNzaW5nIHRoYXQg aGVyZSwgYW5kIGFjdHVhbGx5IGFmdGVyIHRoZXJlIHdhcyBhIHN0YXRlbWVudCB0aGF0IHRoZXJl IHdlcmVu4oCZdCBhbnkgbG9vcGluZyBpc3N1ZXMuDQoNCkJ1dCBhcyB0aGF0IGhhc27igJl0IGFs bCBiZWVuIGNsZWFybHkgc2FpZCwgdGhlcmUgbWF5IHdlbGwgYmUgZXJyb3JzIGluIHRoZSBhYm92 ZS4gRG9lcyBpdCBtYXR0ZXI/IEkgdGhpbmsgeWVzLiBUaGVyZSBhcmUgdHdvIHdheXMgdG8gZmlu ZCBvdXQgaWYgYSBwcm90b2NvbCByZWFsbHkgd29ya3MuIE9uZSBpcyBhbmFseXNpcywgb25lIGlz IGltcGxlbWVudGluZyBhbmQgdGVzdGluZy4gTmVpdGhlciBpcyBwZXJmZWN0IG9mIGNvdXJzZS4N Cg0KSGVyZSB3ZeKAmXZlIGdvdCBhbiBhbmFseXNpcyB0aGF0IGZvdW5kIGEgcHJvYmxlbS4gSGFz IHRoZSBhbmFseXNpcyBiZWVuIHJlLXJ1biBvbiB0aGUgY2hhbmdlZCBwcm90b2NvbD8gQXMgdGhp bmdzIGFyZSBzdGlsbCBldm9sdmluZywgb3ZlciB0aGluZ3MgbGlrZSBkaXJlY3Rpb25hbCBtZXRy aWNzLCBpcyB0aGVyZSBhbiB1cCB0byBkYXRlIGFuYWx5c2lzPw0KDQpBbmQgSSBkb27igJl0IGJl bGlldmUgdGhlcmUgaXMgYW55IHVwIHRvIGRhdGUgKG9yIGV2ZW4gY2xvc2UgdG8gdXAgdG8gZGF0 ZSkgaW1wbGVtZW50YXRpb24uDQoNClRoaXMgZmVlZHMgaW50byBteSBnZW5lcmFsIHBlcmNlcHRp b24sIGluIGFub3RoZXIgZW1haWwuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9y IFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFi b3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8 ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVs bXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBD TTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20v YWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVk IGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJy ZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogbWFu ZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG90dGUgU3Rl ZW5icmluaw0KU2VudDogMzAgQXByaWwgMjAxNiAxMjoxOA0KVG86IG1hbmV0DQpTdWJqZWN0OiBS ZTogW21hbmV0XSBBT0RWdjIgcmVzcG9uc2VzIHRvIHJlY2VudCBjb21tZW50cw0KDQoNCioqKiBX QVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdh bmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0 Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlu a3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2Fy ZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJl Y2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3 ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklm IHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJv Y2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0 eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFp bHMucGRmPi4NCioqKiBXQVJOSU5HICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdl IG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoNCkhpIGFsbCwNCmZv ciB0aGUgc2FrZSBvZiBjb21wbGV0ZW5lc3MsIHRoZSBwYXBlciB3ZeKAmXZlIG1lbnRpb25lZCBp cyBhdmFpbGFibGUgb24gYXJYaXYgbm93Og0KDQpodHRwOi8vYXJ4aXYub3JnL2Ficy8xNjA0LjA3 MTc5DQoNCkFuZCB5b3UgY2FuIGZpbmQgdGhlIGNvZGUgb2YgdGhlIHRvb2wgdGhhdCB3YXMgdXNl ZCBoZXJlOiBodHRwczovL2dpdGh1Yi5jb20vYi15b3VzZWZpL3dSZWJlY2ENCg0KS2luZCByZWdh cmRzLA0KTG90dGUNCg0KQW0gMTYuMDMuMjAxNiB1bSAxODoxMiBzY2hyaWViIExvdHRlIFN0ZWVu YnJpbmsgPGxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlPG1haWx0bzpsb3R0ZS5zdGVlbmJy aW5rQGZ1LWJlcmxpbi5kZT4+Og0KDQpIaSBDaHJpc3RvcGhlciwNCg0KQW0gMDIuMDMuMjAxNiB1 bSAxMTozNiBzY2hyaWViIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PjoN Cg0KTXkgY29uY2VybnMgaGF2ZSBiZWVuIHRoYXQgeW91ciBjby1hdXRob3JzIGhhdmUgY29udGlu dWVkIHRvIGRpc2N1c3Mgd2hldGhlciBsb29waW5nIGNvdWxkIG9jY3VyIHNpbmNlIHlvdSBwdWJs aXNoZWQgdG8gdGhlIGxpc3Qgc2F5aW5nIGFsbCB3YXMgd2VsbC4gKEFuIGlzc3VlIHRvIGRvIHdp dGggbXVsdGlwbGUgdW5jb25maXJtZWQgcm91dGVzLikgTWF5YmUgdGhhdOKAmXMgYSBwcm9ibGVt LCBtYXliZSBpdCBpc27igJl0LiBCdXQgaXQgbGFja3MgdHJhbnNwYXJlbmN5LCBiZWNhdXNlIGl0 IGhhc27igJl0IGJlZW4gZGlzY3Vzc2VkIGhlcmUuDQoNClRoZSBsb29wIHBvc3NpYmlsaXR5IHlv deKAmXJlIHJlZmVycmluZyB0byB3YXMgYSBkaWZmZXJlbnQgb25lIHRoYW4gdGhlIG9uZSBkaXNj dXNzZWQgYnkgQ2hhcmxpZS4gV2XigJl2ZSBiZWVuIGNvbnRhY3RlZCBieSByZXNlYXJjaGVycyB3 aG8gYXJlIG1vZGVsIGNoZWNraW5nIE1BTkVUIHByb3RvY29scyB0byBzZWUgaWYgdGhleSBwZXJt aXQgYW55IHVud2FudGVkIGJlaGF2aW91ci4gVGhleeKAmXZlIHVzZWQgQU9EVnYyIGFzIGEgY2Fz ZSBzdHVkeSBmb3IgdGhlIGZyYW1ld29yayB0aGV54oCZdmUgaW1wbGVtZW50ZWQgdG8gZG8gdGhp cywgYW5kIHRoZXnigJl2ZSBmb3VuZCB0aGUgZm9sbG93aW5nIGxvb3A6DQoNCjxuZXR3b3JrLmpw Zz4NCg0KMS4gbjIgaW5pdGlhdGVzIGEgcm91dGUgZGlzY292ZXJ5IHByb2NlZHVyZSBmb3IgZGVz dGluYXRpb24gbjMgYnkgYnJvYWRjYXN0aW5nIGEg4oCccnJlceKAnSBtZXNzYWdlLg0KMi4gbjEg YW5kIG40IHVwb24gcmVjZWl2aW5nIHRoZSDigJxycmVx4oCdIG1lc3NhZ2UsIGFkZCBhIHJvdXRl IHRvIHRoZWlyIHJvdXRpbmcgdGFibGVzIHRvd2FyZHMgbjIgYW5kIHN0b3JlIG4yIGFzIHRoZWly IG5leHQgaG9wLiBTaW5jZSBpdCBpcyB0aGUgZmlyc3QgdGltZSB0aGF0IHRoZXNlIG5vZGVzIGhh dmUgcmVjZWl2ZWQgYSBtZXNzYWdlIGZyb20gbjIsIHRoZSBuZWlnaGJvciBzdGF0ZSBvZiBuMiBp cyBzZXQgdG8gdW5jb25maXJtZWQuIFRoZXJlZm9yZSwgdGhlIHJvdXRlIHN0YXRlIGlzIHVuY29u ZmlybWVkLg0KMy4gQXMgbjEgYW5kIG40IGFyZSBub3QgdGhlIGludGVuZGVkIGRlc3RpbmF0aW9u IG9mIHRoZSByb3V0ZSByZXF1ZXN0LCB0aGV5IHJlYnJvYWRjYXN0IHRoZSDigJxycmVx4oCdIG1l c3NhZ2UuDQo0LiBuMSByZWNlaXZlcyB0aGUg4oCccnJlceKAnSBtZXNzYWdlIHNlbnQgYnkgbjQg YW5kIHNpbmNlIHRoZSByb3V0ZSB0byBuMiBpcyB1bmNvbmZpcm1lZCBpdCBhZGRzIG40IGFzIG5l dyBuZXh0IGhvcCB0byBuMi4NCjUuIG40IGFsc28gYWRkcyBuMSBhcyB0aGUgbmV3IG5leHQgaG9w IHRvd2FyZHMgbjIgYWZ0ZXIgcHJvY2Vzc2luZyB0aGUg4oCccnJlceKAnSBzZW50IGJ5IG5vZGUx LiBBdCB0aGlzIHBvaW50IGEgbG9vcCBpcyBmb3JtZWQgYmV0d2VlbiBuMSBhbmQgbjQgYnV0IG5v dCB1c2VkIHlldC4NCjYuIG4zIHJlY2VpdmVzIHRoZSDigJxycmVx4oCdIG1lc3NhZ2Ugc2VudCBi eSBuMSBhbmQgc2luY2UgaXQgaXMgdGhlIGRlc3RpbmF0aW9uLCBpdCBzZW5kcyBhIOKAnHJyZXDi gJ0gbWVzc2FnZSB0b3dhcmRzIG4xLg0KNy4gbjIgbW92ZXMgb3V0IG9mIG4xIGFuZCBuNCBjb21t dW5pY2F0aW9uIHJhbmdlLg0KOC4gbjEgcmVjZWl2ZXMgdGhlIOKAnHJyZXDigJ0gbWVzc2FnZSBz ZW50IGJ5IG4zIGFuZCBhcyB0aGUgcm91dGUgc3RhdGUgdG93YXJkcyBuMiBpcyB1bmNvbmZpcm1l ZCBpdCBtdWx0aWNhc3RzIHRoZSDigJxycmVw4oCdIG1lc3NhZ2UgdG8gdGhlIGV4aXN0aW5nIG5l eHQgaG9wcywgbjIgYW5kIG40LiBTaW5jZSBuNCBpcyBhZGphY2VudCB0byBuMSwgaXQgcmVjZWl2 ZXMgdGhlIG1lc3NhZ2UgYW5kIHRoZW4gc2VuZHMgYW4gYWNrIHRvIG4xLiBUaGVyZWZvcmUsIG4x IHNldHMgdGhlIG5laWdoYm9yIHN0YXRlIG9mIG40IHRvIGNvbmZpcm0gYW5kIHN1YnNlcXVlbnRs eSB0aGUgcm91dGUgc3RhdGUgdG93YXJkcyBuMiB0byB2YWxpZC4gVGhlbiBleHB1bmdlIHRoZSBu ZXh0IGhvcCBuMiB3aGljaCBoYXMgbm90IHJlY2VpdmVkIGFuIGFjayBmcm9tLg0KOS4gbjQgYnkg cmVjZWl2aW5nIHRoZSDigJxycmVw4oCdIG1lc3NhZ2UgZnJvbSBuMSBtdWx0aWNhc3RzIGl0IHRv IGl0cyBuZXh0IGhvcHMgdG93YXJkcyBuMSBhbmQgbjIsDQphbmQgc2ltaWxhciB0byBuMSBpdCB1 cGRhdGVzIGl0cyByb3V0aW5nIHRhYmxlIGJ5IHZhbGlkYXRpbmcgbjEgYXMgaXRzIG5leHQgaG9w IHRvIG4yLiBBdCB0aGlzIHBvaW50LCBhIGxvb3AgYmV0d2VlbiBuMSBhbmQgbjQgYmVjb21lcyB2 YWxpZC4NCg0KDQoNCkluIHJlc3BvbnNlIHRvIHRoZXNlIGZpbmRpbmdzLCB3ZSd2ZSBjaGFuZ2Vk IDYuNy4xLiAgRXZhbHVhdGluZyBSb3V0ZSBJbmZvcm1hdGlvbiBpbiAtMTMsIHNvIHRoYXQgTG9v cEZyZWUoKSBpcyAqYWx3YXlzKiBjb25zaWRlcmVkIGJlZm9yZSBhZGRpbmcgYSBuZXcgcm91dGUs IGV2ZW4gaWYgYWxsIGtub3duIHJvdXRlcyB0byBkYXRlIGFyZSBVbmNvbmZpcm1lZC4NCg0KRm9s bG93aW5nIHVwLCB0aGV54oCZdmUgZm91bmQgYW5vdGhlciBsb29wIGluIC0xMzoNCg0KPG5ldHdv cmsuanBnPg0KDQoNCiAgMS4gIEF0IGZpcnN0IG5vZGVzIGFyZSBjb25uZWN0ZWQgdG8gZWFjaCBv dGhlciBhcyBzaG93biBpbiBGaWcxLmEuDQogIDIuICBuMCBpbml0aWF0ZXMgYSByb3V0ZSBkaXNj b3ZlcnkgcHJvY2VkdXJlIGZvciBkZXN0aW5hdGlvbiBuMyBieSBtdWx0aWNhc3RpbmcgYSDigJxy cmVx4oCdIG1lc3NhZ2UgdG8gbjIgd2l0aCBzcT0yLg0KICAzLiAgbjIgYWZ0ZXIgdXBkYXRpbmcg aXRzIHJvdXRpbmcgdGFibGUsIG11bHRpY2FzdCB0aGUg4oCccnJlceKAnSB0byBpdHMgbmVpZ2hi b3JzLCBuMSBhbmQgbjMuDQogIDQuICBuMSB1cG9uIHJlY2VpdmluZyB0aGUg4oCccnJlceKAnSBt ZXNzYWdlIHNlbnQgYnkgbjIgdXBkYXRlcyBpdHMgcm91dGluZyB0YWJsZSBhbmQgYWRkcyBhIHJv dXRlIHdpdGggaG9wLWNvdW50PTIsIHNxPTIgYW5kIG5leHQtaG9wZT0yDQogIDUuICBDb25zaWRl ciB0aGF0IHRvcG9sb2d5IGNoYW5nZXMgYXQgdGhpcyBwb2ludCBhbmQgbjEgbW92ZXMgaW50byBj b21tdW5pY2F0aW9uIHJhbmdlIG9mIG4wLCBnZXRzIGNvbm5lY3RlZCB0byBuMCwgYW5kIG4yIGxl YXZlcyBuMCBjb21tdW5pY2F0aW9uIHJhbmdlLCBnZXRzIGRpc2Nvbm5lY3RlZCBmcm9tIG4wLCB3 aGljaCBsZWFkcyB0byBuZXR3b3JrIHRvcG9sb2d5IHNob3duIGluIEZpZzEuYi4NCiAgNi4gIG4w LCB3aGljaCBoYXNu4oCZdCByZWNlaXZlZCBhbiDigJxycmVw4oCdIHlldCwgcmVzZW5kIHRoZSDi gJxycmVx4oCdIG1lc3NhZ2UgYWZ0ZXIgaW5jcmVhc2luZyBpdHMgc2VxdWVuY2UgbnVtYmVyIHRv IDMuDQogIDcuICBuMSByZWNlaXZlcyB0aGUgbmV3IOKAnHJyZXHigJ0gbWVzc2FnZSwgd2l0aCBz cT0zLCBuZXh0LWhvcD0wIGFuZCBob3AtY291bnQ9MSwgc2luY2UgaXTigJlzIGEgYmV0dGVyIHJv dXRlIGl0IHdvdWxkIGJlIGFkZGVkIHRvIHRoZSByb3V0aW5nIHRhYmxlLiBUaGVuIG4xIG11bHRp Y2FzdCB0aGUg4oCccnJlceKAnSBtZXNzYWdlIHRvIGl0cyBuZWlnaGJvcnMsIG4yIGFuZCBuMy4N CiAgOC4gIG4yIGV2YWx1YXRlIHRoZSByZWNlaXZlZCBtZXNzYWdlIHNlbnQgYnkgbjEgYW5kIGFk ZHMgYSBuZXcgcm91dGUgdG8gaXRzIHJvdXRpbmcgdGFibGUgd2l0aCBzcT0zLCBuZXh0LWhvcD0x IGFuZCBob3AtY291bnQ9MiBzaW5jZSB0aGUgc2VxdWVuY2UgbnVtYmVyIG9mIHRoZSByZWNlaXZl ZCBtZXNzYWdlIGlzIGdyZWF0ZXIgdGhhbiB0aGUgc3RvcmVkIG9uZS4NCkF0IHRoaXMgcG9pbnQg YSBsb29wIGhhcyBiZWVuIGZvcm1lZCBiZXR3ZWVuIG5vZGVzIG4xIGFuZCBuMi4NCg0KDQpTaW5j ZSB3ZeKAmXZlIG1vdmVkIHRvIGRpc2FsbG93aW5nIG11bHRpcGxlIFVuY29uZmlybWVkIHJvdXRl cyAoaW4gLTE0LCB3aGljaCBpc27igJl0IHB1Ymxpc2hlZCB5ZXQpLCB0aGlzIG9uZSBpcyByZXNv bHZlZCBhbHJlYWR5IGFzIHdlbGwuDQoNCg0KVGhlIHJlYXNvbiB3ZSBkaWRu4oCZdCBkaXNjdXNz IHRoaXMgZWFybGllciBvbiBbbWFuZXRdIHdhcyB0aGF0IHRoZSBhdXRob3JzIGhhZG7igJl0IHN1 Ym1pdHRlZCB0aGVpciBwYXBlciB5ZXQgKGFuZCBJIGRpZG7igJl0IHdhbnQgdG8gbGVhayB0aGVp ciB3b3JrKS4gVGhleeKAmXZlIGRvbmUgc28gbm93LCBhbmQgd2lsbCBzZW5kIHVzIGEgbGluayB0 byB0aGVpciBwYXBlciBvbmNlIGl04oCZcyBhdmFpbGFibGUuIEnigJltIGd1ZXNzaW5nIGl04oCZ bGwgdGFrZSBhIHdoaWxlIHRvIGJlIHB1Ymxpc2hlZCBwcm9wZXJseSwgYnV0IGl0IHNob3VsZCBi ZSBlbm91Z2ggZm9yIGZvciBvdXIgcHVycG9zZXMgZm9yIHRoZSBwYXBlciB0byBhcHBlYXIgb24g YXJ4aXYub3JnPGh0dHA6Ly9hcnhpdi5vcmcvPiBmb3Igbm934oCmDQoNCkJlc3QgcmVnYXJkcywN CkxvdHRlDQoNCg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwg RW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu Y29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNo bm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3 dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5k ICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNo IFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IENoYXJsaWUgUGVya2lu cyBbbWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0XQ0KU2VudDogMDEgTWFyY2gg MjAxNiAwMTowOA0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBtYW5ldA0KU3ViamVj dDogUmU6IFttYW5ldF0gQU9EVnYyIHJlc3BvbnNlcyB0byByZWNlbnQgY29tbWVudHMNCg0KDQoq KiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIg b3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRl cm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55 IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiBy ZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlv dSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20v aG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4u DQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlz IHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIw RW1haWxzLnBkZj4uDQpIZWxsbyBDaHJpcywNCk9uIDEvMTkvMjAxNiA1OjM3IEFNLCBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3cm90ZToNCkFuZCBvdXRzaWRlIHRob3NlIDMxLCB0aGF0IHdl 4oCZcmUgYXQgdGhpcyBwb3NpdGlvbiB3aXRoIGEgc3VnZ2VzdGlvbiB0aGVyZeKAmXMgcG9zc2li bGUgbG9vcGluZyAoYWJvdXQgd2hpY2ggSSBoYXZlIG5vIGlkZWEpIGlzbuKAmXQgdGhhdCBjb21m b3J0aW5nLg0KDQpJIGhvcGUgeW91ciBjb25jZXJucyBoYXZlIGJlZW4gcmVzb2x2ZWQgb24gdGhp cyBtYXR0ZXIuICBUaGUgcGFwZXIgbWVudGlvbmVkIG9uIHRoZSBtYWlsaW5nIGxpc3QgcG9pbnRl ZCBvdXQgdmFyaW91cyBhbWJpZ3VpdGllcyBpbiBSRkMgMzU2MSBkZXNjcmliZWQgaG93IHRoZSBh bWJpZ3VpdGllcyBtaWdodCBiZSBjb25zdHJ1ZWQgdG8gaW5zdGFsbCBzZWxmLXJvdXRlcyBhbmQs IGNvbWJpbmVkIHdpdGggcG9zc2libGUgaW5jb25zaXN0ZW50IGNob2ljZXMgZm9yIHNlcXVlbmNl IG51bWJlciwgbG9vcHMgY291bGQgcmVzdWx0LiAgQnV0IHRoZSBlbWFpbCB0byB0aGUgbGlzdCBz ZXZlcmFsIHdlZWtzIGFnbyBpbmRpY2F0ZWQgdGhhdCB0aGVzZSBhbWJpZ3VpdGllcyBkbyBub3Qg ZXhpc3QgaW4gQU9EVnYyLiAgVGhlIGF1dGhvcnMgb2YgdGhhdCBwYXBlciBoYXZlIGV4cHJlc3Nl ZCBpbnRlcmVzdCBpbiBkb2luZyBhIHNpbWlsYXIgYW5hbHlzaXMgb24gQU9EVnYyLg0KDQpPdGhl ciBkaXNjdXNzaW9uIGFib3V0IHJvdXRpbmcgbG9vcHMgaGFzIG5vdCBpZGVudGlmaWVkIHJvdXRp bmcgbG9vcCBwcm9ibGVtcyBpbiB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbi4gIFVzZSBvZiB1 bmNvbmZpcm1lZCBvciBpbnZhbGlkIHJvdXRlcyBmb3Igcm91dGluZyBtaWdodCBsZWFkIHRvIGVy cm9ycywgYnV0IHRoYXQgZG9lc24ndCBjYXJyeSBvdmVyIHRvIHByb2R1Y2UgbG9vcHMgaW4gdGhl IHJvdXRlIHRhYmxlLg0KDQpJJ20gbG9va2luZyBmb3IgYW55IG90aGVyIG9wZW4gaXNzdWVzIG91 dHNpZGUgb2YgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHdoaWNoIGlzIGJlaW5nIHJld29y a2VkIGFjY29yZGluZyB0byByZWNlbnQgY29tbWVudHMgYnV0IHNob3VsZCBiZSBzdWJtaXR0ZWQg c29vbi4NCg0KUmVnYXJkcywNCkNoYXJsaWUgUC4NCg0KDQoNCg0KDQpUaGVyZeKAmXMgYWxzbyBh IGxvdCBvZiBkb2N1bWVudCB0byByZXZpZXcuIFdoaWNoIG9mIGNvdXJzZSBJIGhhdmVu4oCZdCBk b25lIGF0IHRoaXMgdGltZS4gQnV0IG15IGF0dGVudGlvbiBkaWQgYWxpZ2h0IG9uIHRoZSBJQU5B IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGFuZCBJIG5vdGVkIHRoZXJlIHRoYXQ6DQotIE5vdCBz dXJlIHdoeSB0aGUganVtcCB0byAxMCBmb3IgbWVzc2FnZSB0eXBlcywgdGhvdWdoIEnigJltIG5v dCBvcHBvc2VkLg0KLSBUaGUgUEFUSF9NRVRSSUMgVExWIGNhbuKAmXQgYmUgdHlwZSAxMCwgdGhh dOKAmXMgYWxyZWFkeSB0YWtlbi4gU2VlIElBTkEgcmVnaXN0ZXIuDQotIFdlIHByZXZpb3VzbHkg cG9pbnRlZCBvdXQgdGhhdCBDT05UX1NFUV9OVU0gKENPTVBMRVRFKSBhbHJlYWR5IGV4aXN0cyBh bmQgZG9lcyB0aGUgam9iIHRoYXQgU0VRX05VTSBpcyBkb2luZywgc28gd2h5IGFsbG9jYXRlIGFu b3RoZXIgVExWPyAoWW91IGNvdWxkIGF2b2lkIHRoZSBuZWNlc3NpdHkgb2YgcmVwZWF0aW5nIChD T01QTEVURSkgYnkgc2ltcGx5IGNvbW1lbnRpbmcgb25jZSBhbmQgdGhlcmVhZnRlciBvbWl0dGlu Zy4pDQotIFdoeSB0aGUgc3VnZ2VzdGVkIHNraXBwaW5nIG9mIHR5cGVzIDEyIHRvIDE0Pw0KDQot LQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBT eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdy ZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNv bS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJ bnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAx MzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9y ZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZpY3RvcmlhIE1lcmNpZWNhDQpTZW50OiAxOCBKYW51YXJ5 IDIwMTYgMjE6NDUNClRvOiBtYW5ldA0KU3ViamVjdDogW21hbmV0XSBBT0RWdjIgcmVzcG9uc2Vz IHRvIHJlY2VudCBjb21tZW50cw0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9y aWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4 dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRo ZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9y IHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2Fu IGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2lu dHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9E b2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNw aWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJh ZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFs aW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCioqKiBXQVJOSU5HICoqKg0K RVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91 ciBvcmdhbml6YXRpb24uDQoNCkhpIGFsbCwNCldlIGhhdmUganVzdCByZWxlYXNlZCB0aGUgbmV3 ZXN0IEFPRFZ2MiBkcmFmdC4gVGhlIG1ham9yIHVwZGF0ZSBpcyB0aGUgc2VwYXJhdGlvbiBvZiB0 aGUgQU9EVnYyIHJvdXRlIHNldCBmcm9tIHRoZSBSSUIuDQoNCkhlcmUgYXJlIGFsc28gcmVzcG9u c2VzIHRvIHRoZSBjb21tZW50cyByZWNlaXZlZCBiZWZvcmUgQ2hyaXN0bWFzLiBUaGlzIHNob3Vs ZCBpbmNsdWRlIGFsbCB0aGUgcG9pbnRzIGZyb20gVGhvbWFzIENsYXVzZW4gcmVnYXJkaW5nIHZl cnNpb25zIDExIGFuZCAxMiwgYW5kIGFsc28gYSBjb3VwbGUgb2Ygb3RoZXIgcG9pbnRzIHdoaWNo IGhhdmUgYmVlbiBicm91Z2h0IHVwIHNpbmNlLiBBcG9sb2dpZXMgZm9yIHRoZSBodWdlIGVtYWls LiBGb3IgaXNzdWVzIHRoYXQgbmVlZCBmdXJ0aGVyIGRpc2N1c3Npb24sIEkgaGF2ZSB0cmllZCB0 byBpbmNsdWRlIHRoZSBtYWluIHBvaW50cyBvZiB0aGUgZGlzY3Vzc2lvbiBzbyBmYXIuIFBsZWFz ZSBmZWVsIGZyZWUgdG8gY3JlYXRlIGEgc2VwYXJhdGUgdGhyZWFkIGZvciBhbnkgZnVydGhlciBk aXNjdXNzaW9uLg0KDQpXZSBhcmUgc3RpbGwgbG9va2luZyBpbnRvIHRoZSBsb29wIGNvbmRpdGlv bnMgcmVjZW50bHkgcmVwb3J0ZWQgZm9yIEFPRFYsIGFsc28gc3RpbGwgd29ya2luZyBvbiB0aGUg dGV4dCBhYm91dCBzZWN1cml0eSwgYW5kIHVzZSBvZiBtc2ctaG9wLWxpbWl0Lg0KS2luZCByZWdh cmRzLA0KVmljdG9yaWEuDQoNCg0KMS4gRW5kLXRvLWVuZCAvIGhvcC1ieS1ob3AgYWNrcyAtIGlz c3VlIHdoZW4gYSByb3V0ZSBpcyBtYXJrZWQgYXMgY29uZmlybWVkIGFuZCB2YWxpZCB3aGVuIHRo ZSBsaW5rIHRvIHRoZSBuZXh0IGhvcCBpcyBjb25maXJtZWQgYXMgYmlkaXJlY3Rpb25hbCAoYnV0 IHRoZSBsaW5rcyBkb3duc3RyZWFtIGhhdmUgbm90IHlldCBiZWVuIHZlcmlmaWVkIGFzIGJpZGly ZWN0aW9uYWwpLg0KDQpBT0RWdjI6IFRoZSBhdXRob3JzIGJlbGlldmUgdGhpcyBpcyBhbiBpc3N1 ZSB3aGljaCB3b3VsZCBub3Qgb2NjdXIgZnJlcXVlbnRseSwgYW5kIHdvdWxkIHJpZ2h0IGl0c2Vs Zi4NCg0KVGhpcyBvbmx5IG9jY3VycyBmb3IgdGhlIHJvdXRlIHRvIE9yaWdBZGRyLiBXaGF0IG5l ZWRzIHRvIGhhcHBlbiBmb3IgdGhpcyB0byBvY2N1ciBpcyB0aGF0IGFuIGludGVybWVkaWF0ZSBu b2RlIHRoYXQgdGFrZXMgcGFydCBpbiB0aGUgcm91dGUgZGlzY292ZXJ5IGJldHdlZW4gT3JpZ0Fk ZHIgYW5kIFRhcmdBZGRyIGNvaW5jaWRlbnRhbGx5IGhhcyBwYWNrZXRzIHRvIHNlbmQgdG8gT3Jp Z0FkZHIgaW4gdGhlIHRpbWUgYmV0d2VlbiBjb25maXJtaW5nIHRoZSBsaW5rIHRvIGl0cyBvd24g bmV4dCBob3AgdG93YXJkIE9yaWdBZGRyIGlzIGJpZGlyZWN0aW9uYWwsIGFuZCB0aGUgdGltZSB0 YWtlbiBmb3IgYWxsIG90aGVyIHJvdXRlcnMgb24gdGhlIHBhdGggdG8gY29uZmlybSB0aGVpciBu ZXh0IGhvcHMgdG9vLiBJZiB0aGUgcm91dGUgaXMgdXNlZCB0byBmb3J3YXJkIHBhY2tldHMgYmVm b3JlIGV2ZXJ5IG90aGVyIGxpbmsgaW4gdGhlIHBhdGggaXMgY29uZmlybWVkIGFzIGJpZGlyZWN0 aW9uYWwsIGFuZCB0aGUgZGF0YSBwYWNrZXRzIGFyZSBmb3J3YXJkZWQgZmFzdGVyIHRoYW4gdGhl IFJSRVAgYW5kIGFueSBSUkVQX0Fja3MsIHRoZW4geWVzIHRoZXkgY291bGQgYmUgZGVsaXZlcmVk IHRvIGEgcm91dGVyIHdpdGhvdXQgYSB2YWxpZCByb3V0ZSB0byBPcmlnQWRkci4gQWx0ZXJuYXRp dmVseSBpZiBvbmUgb2YgdGhlIGxpbmtzIHR1cm5zIG91dCB0byBiZSB1bmlkaXJlY3Rpb25hbCB0 aGVuIHRoZSBkYXRhIHBhY2tldHMgd2lsbCBhbHNvIGFycml2ZSBhdCBhIHJvdXRlciB3aXRob3V0 IGEgdmFsaWQgcm91dGUuIEluIHRoZXNlIGNhc2VzLCBSRVJSIG1lc3NhZ2VzIHdpbGwgYmUgZ2Vu ZXJhdGVkIHRvd2FyZCB0aGUgc291cmNlIG9mIHRoZSB0cmFmZmljLCB0aGUgcm91dGUgdG8gT3Jp Z0FkZHIgd2lsbCBiZSBkZWxldGVkIGF0IHJvdXRlcnMgYmFjayB0b3dhcmQgVGFyZ0FkZHIsIGJ1 dCBpZiBkYXRhIHBhY2tldHMgYXJlIHN0aWxsIGZsb3dpbmcgZnJvbSBhbnkgc291cmNlIHRvIE9y aWdBZGRyLCB0aGUgcm91dGUgd2lsbCBiZSByZS1yZXF1ZXN0ZWQgYnkgdGhlIHJvdXRlciByZXNw b25zaWJsZSBmb3IgZGlzY292ZXJpbmcgcm91dGVzIGZvciB0aGUgc291cmNlIG9mIHRoZSBkYXRh Lg0KDQpUaGUgY2hhbmdlcyByZXF1aXJlZCB0byBtYWtlIGFja25vd2xlZGdlbWVudHMgZW5kLXRv LWVuZCB3b3VsZCByZXF1aXJlIGEgbG90IG1vcmUgY29udHJvbCB0cmFmZmljIGFuZCBiZSBuZWNl c3NhcnkgZm9yIGV2ZXJ5IHJvdXRlIGRpc2NvdmVyeSBhbmQgaW4gYWxtb3N0IGFsbCBjYXNlcyB3 b3VsZCBiZSB1bm5lY2Vzc2FyeS4NCg0KVGV4dCBoYXMgYmVlbiBhZGRlZCB0byB0aGUgZHJhZnQg aW4g4oCcTG9jYWwgUm91dGUgU3RhdGUgQ2hhbmdlc+KAnSB0byBkZXNjcmliZSB0aGlzLg0KDQoy LiBCdWZmZXJpbmcNCu+7v1Rob21hczoNCuKAnEl0IHdvdWxkIHNlZW0gdGhhdCBidWZmZXJpbmcs IGFzIHNwZWNpZmllZCwgZG9lcyBub3QgYWNjb21wbGlzaCB3aGF0DQppdCBzdGF0ZXMgdGhhdCBp dCBhY2NvbXBsaXNoZXM6IHBhY2tldHMgYXJlIChhcyB5b3UgZGVzY3JpYmUpIHN0aWxsIGJlaW5n DQpzZW50IHdoaWxlIG5vIHJvdXRlIGlzIGF2YWlsYWJsZSwgYW5kIHRoZXJlZm9yZSB3aWxsIGJl IGRyb3BwZWQgbGF0ZXIuDQo9PiBDb25zZXF1ZW50bHksIGl0IHNlZW1zIHRoYXQgYnVmZmVyaW5n IGlzIGEgZnV0aWxlIGV4ZXJjaXNlP+KAnQ0KDQpBT0RWdjI6IO+7v1BhY2tldHMgYXJlIGJ1ZmZl cmVkIGJlZm9yZSBhIHJvdXRlIGV4aXN0cy4gQSByb3V0ZXIgb25seSBiZWdpbnMgc2VuZGluZyB0 aGVtIHdoZW4gaXQgZGVlbXMgdGhlIHJvdXRlIHRvIGJlIHZhbGlkLiBJbiBnZW5lcmFsLCBidWZm ZXJpbmcgaXMgbm90IGZ1dGlsZS4NCg0KVHJ1ZSwgdGhlcmUgaXMgdGhpcyBjYXNlIG91dGxpbmVk IGFib3ZlIHdoZXJlIHRoZSByb3V0ZXIgY291bGQgZGVlbSB0aGUgcm91dGUgdmFsaWQgYmVmb3Jl IHRoZSBiaWRpcmVjdGlvbmFsaXR5IGNoZWNrIGhhcyBoYXBwZW5lZCBmb3IgZWFjaCBhbmQgZXZl cnkgaG9wLiBJZiB0aGUgbGlua3MgY2hvc2VuIGZvciB0aGUgcm91dGUgYXJlIG5vdCBhbGwgYmlk aXJlY3Rpb25hbCwgdGhlbiB5ZXMsIGFueSBkYXRhIHBhY2tldHMgZm9yd2FyZGVkIGFsb25nIHRo aXMgcm91dGUgd2lsbCBlbmQgdXAgYmVpbmcgZHJvcHBlZCBhdCBzb21lIHBvaW50IG9uIHRoYXQg cGF0aC4NClRoaXMgY2FzZSBpcyBjYXVzZWQgYnkgdGhlIFJSRVBfQWNrIGJlaW5nIGhvcC1ieS1o b3AsIGFuZCBub3QgY2F1c2VkIGJ5IGJ1ZmZlcmluZy4NCg0KVGhvbWFzOiDvu78NCuKAnEJ1ZmZl cnMgaGF2ZSBodWdlIGltcGFjdHMgb24gVENQIHBlcmZvcm1hbmNlLCBhbmQgSSBkb3VidCBpZiB0 aGUgaXNzdWVzIG9uIGUuZy4gVENQIGFyZSB3ZWxsIGVub3VnaCB1bmRlcnN0b29kIGJ5IHRoaXMg V0cgKEJ1ZmZlcmJsb2F0IHdhcyBhbiBleGFtcGxlIG9mIHdoZXJlIHBlb3BsZSBnb3QgaXQgd3Jv bmcsIGRlc3BpdGUgaGF2aW5nIGV4dGVuc2l2ZSBleHBlcmllbmNlKS7igJ0NCg0KQU9EVnYyOiBQ YWNrZXRzIHdpbGwgb25seSBiZSBidWZmZXJlZCB3aGlsZSBhIHJvdXRlIGlzIHJlcXVlc3RlZC4g VGhlIFRDUCBwYWNrZXRzIGJ1ZmZlcmVkIHdpbGwgYmUgcGFja2V0cyBmb3Igc2Vzc2lvbiBpbml0 aWFsaXNhdGlvbi4gVGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IGJ1ZmZlcmluZyB0aGVzZSB3aWxs IGhhdmUgYSBwb3NpdGl2ZSBlZmZlY3QuIFNvbWUgcmVmZXJlbmNlcyBoYXZlIGJlZW4gc3VnZ2Vz dGVkLCBsaXN0ZWQgaGVyZSwgdGhlIGZpcnN0IG9mIHdoaWNoIGhhcyBiZWVuIGluY2x1ZGVkIGlu IHRoZSBkcmFmdDoNCmh0dHA6Ly93d3cuaWVlZTgwMi5vcmcvMjEvYXJjaGl2ZWRfZG9jcy8yMDAz LTA5X2luY29taW5nL2Njci0yMDAxMDkta29vZGxpLnBkZg0KTW9iaWxlIEludGVybmV0d29ya2lu ZyB3aXRoIElQdjY6IENvbmNlcHRzLCBQcmluY2lwbGVzIGFuZCBQcmFjdGljZXMge0tvb2RsaSwg UGVya2luc30NCmRpc2MuZWNlLmlsbGlub2lzLmVkdS9zZW1pbmFyc190dXRvcmlhbHMvdGNwLXdp cmVsZXNzLXR1dG9yaWFsLnBwdDxodHRwOi8vZGlzYy5lY2UuaWxsaW5vaXMuZWR1L3NlbWluYXJz X3R1dG9yaWFscy90Y3Atd2lyZWxlc3MtdHV0b3JpYWwucHB0Pg0KQW5hbHlzaXMgb2YgVENQIHBl cmZvcm1hbmNlIG92ZXIgbW9iaWxlIGFkIGhvYyBuZXR3b3JrcyBodHRwOi8vZGwuYWNtLm9yZy9j aXRhdGlvbi5jZm0/aWQ9MzEzNTQwDQpBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCByZW1vdmUgdGhl IG1lbnRpb24gb2YgVENQLCBhbmQgaW5zdGVhZCBzdGF0ZSB0aGF0IGJ1ZmZlcmluZyBNQVkgYmUg dXNlZCBmb3IgcGFja2V0cyBhd2FpdGluZyBhIHJvdXRlLCBidXQgdGhhdCBpbXBsZW1lbnRhdGlv biBhbmQgaW1wbGljYXRpb25zIG9mIHRoaXMgYXJlIG91dCBvZiBzY29wZSBmb3IgQU9EVnYyLg0K DQoNCjMuIFVzZSBvZiBtc2ctaG9wLWxpbWl0IGFuZCBtc2ctaG9wLWNvdW50Og0KVGhvbWFzOg0K QnV0LCBlaXRoZXIgd2F5LCBhcyBhY2NvcmRpbmcgdG8geW91ciBtb2RlbCBtZXNzYWdlcyBhcmUg bmV2ZXIgZm9yd2FyZGVkLCBidXQgYWx3YXlzIGFyZSBpbnRlbmRlZCBmb3IgcmVjZWlwdCBieSBh IHJvdXRlciB3aGljaCBpcyBhIGRpcmVjdCBuZWlnaGJvciwgdGhlbiBhIDxtc2ctaG9wLWxpbWl0 PiA+MSAod2hpY2ggYXBwbGllcyB0byB0aGUgbWVzc2FnZSkgc2VlbXMgaW5hcHByb3ByaWF0ZS4N CkFjdHVhbGx5LCBhY2NvcmRpbmcgdG8gdGhhdCBtb2RlbCwgSSB3b3VsZCBldmVuIHNheSB0aGF0 IHJlY2VpcHQgb2YgYSBtZXNzYWdlIHdpdGggYSA8bXNnLWhvcC1jb3VudD4gPjEgc2hvdWxkIGJl IGludGVycHJldGVkIGFzIGEgbWFsZnVuY3Rpb24uDQpBcyB5b3UgcmVmZXIgdG8gUkZDNTQ0NCBh cHBlbmRpeCBCLCBkbyBub3RlIHRoYXQgQXBwZW5kaXggQiBvZiBSRkM1NDQ0IChhbmQsIG5vdGUg dGhlIGVycmF0YSA0MDAzKSB0YWxrcyBhYm91dDoNCiAgICAgIDxtc2ctaG9wLWxpbWl0PiBmaWVs ZCwgaWYgcHJlc2VudCwgY29udGFpbnMgdGhlIG51bWJlciBvZiBob3BzIG9uIHdoaWNoIHRoZSBt ZXNzYWdlIGlzIGFsbG93ZWQgdG8gdHJhdmVsIGJlZm9yZSBiZWluZyBkaXNjYXJkZWQgYnkgYSBN QU5FVCByb3V0ZXIuICBUaGUgPG1zZy1ob3AtbGltaXQ+IGlzIHNldCBieSB0aGUgbWVzc2FnZSBv cmlnaW5hdG9yIGFuZCBpcyB1c2VkIHRvIHByZXZlbnQgbWVzc2FnZXMgZnJvbSBlbmRsZXNzbHkg Y2lyY3VsYXRpbmcgaW4gYSBNQU5FVC4NClNwZWNpZmljYWxseSDigJxzZXQgYnkgdGhlIG1lc3Nh Z2Ugb3JpZ2luYXRvcuKAnSBhbmQg4oCcbnVtYmVyIG9mIGhvcHMgb24gd2hpY2ggdGhlIG1lc3Nh Z2UgaXMgYWxsb3dlZCB0byB0cmF2ZWzigJ0g4oCUIHdpdGggeW91ciBjb250cm9sIG1lc3NhZ2Vz IHRyYXZlbGluZyBqdXN0IG9uZSBob3AsIEkgYmVsaWV2ZSB0aGF0IHNldHRpbmcgPG1zZy1ob3At bGltaXQ+ID0gMSBpcyBjb3JyZWN0Lg0KDQpBT0RWdjI6IERpc2N1c3Npb24gaXMgc3RpbGwgbmVl ZGVkIGhlcmUuIFdlIHdvbmRlciBpZiB0aGVzZSBmaWVsZHMgYXJlIG5lY2Vzc2FyeSBhdCBhbGwg Zm9yIEFPRFZ2Mi4gV2Ugd2VyZSB1c2luZyB0aGVtIHRvIGxpbWl0IHRoZSBudW1iZXIgb2YgcmVn ZW5lcmF0aW9ucyBvZiBhIFJSRVEuIEhvd2V2ZXIsIHRoZSBob3AgbGltaXQgdmFsdWUgbmVlZHMg dG8gYmUgbGFyZ2UgZW5vdWdoIHRvIGFsbG93IGEgUlJFUSBmcm9tIG9uZSBzaWRlIG9mIHRoZSBu ZXR3b3JrIHRvIGFub3RoZXIuIEl0IG1pZ2h0IGJlIHRoZSBjYXNlIHRoYXQgdXNpbmcgdGhlIGhv cCBsaW1pdCwgYWxtb3N0IGV2ZXJ5IHJvdXRlciBpbiB0aGUgbmV0d29yayB3b3VsZCByZWNlaXZl IHRoYXQgUlJFUSBhbnl3YXksIGFuZCBieSB1c2luZyB0aGUgcmVkdW5kYW5jeSBjaGVjaywgd2Ug YWxyZWFkeSBzdG9wIFJSRVFzIGZyb20gY2lyY3VsYXRpbmcgZW5kbGVzc2x5Lg0KDQo0LiBBYnN0 cmFjdA0KVGhvbWFzOg0K4oCcSSBtYWRlIHRoZSBmb2xsb3dpbmcgY29tbWVudCwgd2hpY2ggc3Rp bGwgYXBwbGllczoNCuKAnFRoaXMgaXMgYSBsaXR0bGUgb3Zlci1zdGF0aW5nIHRoZSBhcHBsaWNh YmlsaXR5OiB0aGVzZSBzdGF0ZW1lbnRzIG1heSBiZSB0cnVlIGluIHNvbWUgc2NlbmFyaW9zIChm b3IgZXhhbXBsZSwgd2hlbiB0aGVyZSBhcmUgZmV3IGNvbmN1cnJlbnQgdHJhZmZpYyBmbG93cywg YW5kIHRoZXJlZm9yZSBmZXcgcm91dGVzIHRvIHJlcGFpciwgYW5kIHRoZXJlZm9yZSBmZXcgZmxv b2Rpbmcgb3BlcmF0aW9ucyB0byBjb250ZW5kIGZvciBjaGFubmVsIGFjY2VzcykuIEFzIGEgZ2Vu ZXJhbCBzdGF0ZW1lbnQsIHRoaXMgbGFzdCBzZW50ZW5jZSBpcyBpbmNvcnJlY3TigJ3igJ0NCg0K QU9EVnYyOiBUaGUgdGV4dCBoYXMgYmVlbiByZW1vdmVkIGFuZCB0aGUgYWJzdHJhY3Qgbm93IHN0 YXRlczog4oCcIFRoZSBBZCBIb2MgT24tZGVtYW5kIERpc3RhbmNlIFZlY3RvciBWZXJzaW9uIDIg KEFPRFZ2Mikgcm91dGluZyBwcm90b2NvbCBpcyBpbnRlbmRlZCBmb3IgdXNlIGJ5IG1vYmlsZSBy b3V0ZXJzIGluIHdpcmVsZXNzLCBtdWx0aWhvcCBuZXR3b3Jrcy4gIEFPRFZ2MiBkZXRlcm1pbmVz IHVuaWNhc3Qgcm91dGVzIGFtb25nIEFPRFZ2MiByb3V0ZXJzIHdpdGhpbiB0aGUgbmV0d29yayBp biBhbiBvbi1kZW1hbmQgZmFzaGlvbi7igJ0NCg0KNSw5LDEyLDEzLDIwLiBSb3V0ZXIgQ2xpZW50 DQpUaG9tYXM6DQrigJxJIG1hZGUgYSBjb21tZW50IHByZXZpb3VzbHkgdGhhdCDigJxSb3V0ZXIg Y2xpZW504oCdIGlzIGEgcG9vcmx5IGNob3NlbiB0ZXJtLCBhbmQgaGF2ZSBwcm9wb3NlZCBhbHRl cm5hdGl2ZXMuIEnigJl2ZSBzZWVuIHNvbWUgYXR0ZW1wdHMgb24gdGhlIGxpc3QgYXQgcmF0aGVy IHRoYW4gY2hhbmdlIHRoZSB0ZXJtLCBleHBsYWluIGl0IOKAlCBzb21lIG9mIHdoaWNoIGlzIGlu IHRoaXMgZG9jdW1lbnQuIFRoZSDigJxPdmVydmlld+KAnSBzdGlsbCB0YWxrcyBhYm91dCDigJxh IHJvdXRlcuKApm9uZSBvZiBpdHMgY2xpZW50c+KAnSAtIHdoaWNoIGlzIG5vIGxlc3MgY29uZnVz aW5nIHRoYW4gbGFzdCB0aW1lIEl3IHdlbnQgdGhyb3VnaCBpdC4NCkkgcmVpdGVyYXRlLCB3aHkg bm90IHVzZSDigJxMb2NhbCBBdHRhY2hlZCBOZXR3b3JrIFNldOKAnSwgd2hpY2ggaXMgdGhlIHRl cm0gdXNlZCBieSBvdGhlciBkb2N1bWVudHMgZnJvbSB0aGlzIFdHP+KAnQ0KDQpBT0RWdjI6IFdl IGFscmVhZHkgYW5zd2VyZWQgdGhpcyBzdWdnZXN0aW9uIG9uIHRoZSBNQU5FVCBsaXN0IGFuZCBh c2tlZCBmb3IgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLCBhbmQgbm8gcmVzcG9uc2VzIHdlcmUg cmVjZWl2ZWQuIFdlIGhhdmUgZGVmaW5lZCB3aGF0IHdlIG1lYW4gYnkgUm91dGVyIENsaWVudCwg YW5kIHRoZSB0ZXJtaW5vbG9neSBoYXMgc28gZmFyIG5vdCBjaGFuZ2VkLiBIb3dldmVyLCBzb21l IGFsdGVybmF0aXZlcyBoYXZlIGJlZW4gc3VnZ2VzdGVkLCBzbyBpZiB5b3UgZmVlbCBhbnkgb2Yg dGhlc2UgYXJlIG1vcmUgZWZmZWN0aXZlLCBwbGVhc2UgbGV0IHVzIGtub3c6DQrvu7/igKIgICAg QWR2ZXJ0aXNlZCBJUCBBZGRyZXNzOiBwdXRzIHRoZSBlbXBoYXNpcyBvbiBhZHZlcnRpc2VtZW50 IHJhdGhlciB0aGFuIHRvcG9sb2dpY2FsIGNvbm5lY3Rpb24NCuKAoiAgICBBY2Nlc3NpYmxlIElQ IEFkZHJlc3M6IHB1dHMgdGhlIGVtcGhhc2lzIG9uIGFjY2Vzc2liaWxpdHkgdGhyb3VnaCB0aGUg cGFydGljdWxhciByb3V0ZXIg4oCTIG5vdCBiYWQNCuKAoiAgICBSZWR1Y2VkIEZ1bmN0aW9uIERl dmljZSBbUkZEXTogZG9lc27igJl0IHJvbGwgb2ZmIHRoZSB0b25ndWUsIGJ1dCB0aGlzIGlzIHRl cm1pbm9sb2d5IHVzZWQgZm9yIEwyUiBpbiBJRUVFIDgwMiBXaXJlbGVzcyBmb3IgYSBzaW1pbGFy IHNpdHVhdGlvbg0K4oCiICAgIEFjY2Vzc2libGUgRGV2aWNlIEFkZHJlc3M6IGFkZHMgc29tZSBl bXBoYXNpcyBmb3IgdGhlIGRldmljZSBhcyB3ZWxsIGFzIHRoZSBhZGRyZXNzDQrvu7/igKIgICAg U3RhYmx5IENvbm5lY3RlZCBJUCBBZGRyZXNzOiBub3RoaW5nIGlzIHBlcm1hbmVudCwgb2YgY291 cnNlLCBidXQgdGhlIHJvdXRlciBjbGllbnQgc2V0IGlzIHRob3VnaHQgdG8gYmUgcmVsYXRpdmVs eSBzdGFibGUNCuKAoiAgICBUb3BvbG9naWNhbGx5IENvbm5lY3RlZCBJUCBhZGRyZXNzOiAuLi4g c3VnZ2VzdHMgdGhhdCBhICJ0b3BvbG9naWNhbCBjb25uZWN0aW9uIiBpcyBzdGFibGUgY29tcGFy ZWQgdG8gd2lyZWxlc3MNCuKAoiAgICBBZG1pbmlzdHJhdGl2ZWx5IEFzc2lnbmVkIElQIGFkZHJl c3M6IC4uLiBzb21laG93IGRvZXMgbm90IGNvbm5vdGUgdGhlICJvdGhlcm5lc3MiIG9mIHRoZSBy b3V0ZXIgY2xpZW50IGRldmljZXMuDQoNCjYuIE92ZXJ2aWV3IC0gYWRqYWNlbmN5DQpUaG9tYXM6 DQpUaGUgdGVybSDigJxjb25maXJtaW5nIGFkamFjZW5jeeKAnSBpcyBnb25lLCBhbmQgaXMgbm93 IHJlcGxhY2VkIGJ5IOKAnGNvbmZpcm1pbmcgYmlkaXJlY3Rpb25hbGl0eeKAnSAtIHdoaWNoLCBh bGFzLCBzdGlsbCBzb3VuZHMgbGlrZSB0aGVyZSBpcyBzb21lIGFjdGl2ZSBtb25pdG9yaW5nIChI RUxMTyBtZXNzYWdlIGV4Y2hhbmdlKSBnb2luZyBvbi4gVW5sZXNzIHRoYXQgaXMgdGhlIGNhc2Us IHRoZW4gcGxlYXNlIGJlIG1vcmUgc3BlY2lmaWMgaGVyZS4NCkkgbm90ZSB0aGF0IHRoZSB0ZXJt IGFkamFjZW5jeSBpcyB1c2VkIHRocm91Z2ggYW5kIHRocm91Z2ggdGhlIGRvY3VtZW50LCBidHcu DQoNCkFPRFZ2MjogVGhlIHRleHQgaGFzIGJlZW4gdXBkYXRlZCB0byBhdm9pZCB0aGUgd29yZCBh ZGphY2VuY3kuIFdlIGRvIG5vdCBiZWxpZXZlIHRoZSB0ZXh0IGltcGxpZXMgYWN0aXZlIG1vbml0 b3JpbmcgdGhyb3VnaCBIRUxMTyBtZXNzYWdlcy4NCg0KNy4gT3ZlcnZpZXcgLSBmb3J3YXJkaW5n IHBsYW5lDQpUaG9tYXM6IEkgc3VnZ2VzdGVkIGluIG15IGxhc3QgcmV2aWV3OiBUaGUgb3ZlcnZp ZXcgbXVzdCBhbHNvIGluY2x1ZGUgYSBwYXJhZ3JhcGggb24gdGhlIGludGVyc2VjdGlvbnMgYmV0 d2VlbiB0aGlzIHByb3RvY29sIGFuZCB0aGUgZm9yd2FyZGluZyBwbGFuZSDigJQgdGhpcywgYXMg aXQgaXMgZGlmZmVyZW50IChhbmQgbW9yZSBpbnZhc2l2ZSkgZnJvbSB0aGF0IHdoaWNoIGlzIHR5 cGljYWxseSBzZWVuIGluIHJvdXRpbmcgcHJvdG9jb2xzLg0KU3BlY2lmaWNhbGx5LCBhcyBhIHJl YWN0aXZlIHByb3RvY29sLCBpdCBpcyByZXF1aXJlZCAoYXQgbGVhc3QpIHRoYXQgdGhlIGZvcndh cmRpbmcgcGxhbmUgaXMgbW9kaWZpZWQgOg0KMSkgQSDigJxtaXNz4oCdIHdoZW4gbG9va2luZyB1 cCBhIG5leHQgaG9wIGZvciBhIGRhdGEgcGFja2V0IHRvIGJlIGZvcndhcmRlZCwgaXMgc2lnbmFs bGVkIHRvIHRoZSBBT0RWdjIgcHJvY2VzcyBzbyBhcyB0byBwZXJtaXQgdGhhdCByb3V0ZSBkaXNj b3ZlcnkgYmUgbGF1bmNoZWQ7DQoyKSBBIOKAnG1pc3PigJ0gd2hlbiBhdHRlbXB0aW5nIHRvIGRl bGl2ZXIgYSBkYXRhIHBhY2tldCB0byBhIG5leHQgaG9wLCB3aGljaCB3YXMgcmVjb3JkZWQgaW4g dGhlIHJvdXRpbmcgdGFibGUsIGlzIHNpZ25hbGxlZCB0byB0aGUgQU9EVnYyIHByb2Nlc3Mgc28g YXMgdG8gcGVybWl0IHRoYXQgYSByb3V0ZSByZXBhaXIgYmUgaW5pdGlhdGVkIGFuZC9vciBhIFJv dXRlIEVycm9yIGJlIGdlbmVyYXRlZC4NCjMpIEEg4oCcaGl04oCdIHdoZW4gbG9va2luZyB1cCBh IG5leHQgaG9wIGZvciBhIGRhdGEgcGFja2V0IHRvIGJlIGZvcndhcmRlZCB0byBhIGRlc3RpbmF0 aW9uIGlzIHNpZ25hbGxlZCB0byB0aGUgQU9EVnYyIHByb2Nlc3Mgc28gYXMgdG8gcGVybWl0IG1h aW50ZW5hbmNlIG9mIOKAnGFjdGl2ZSByb3V0ZeKAnSBSb3V0ZSBTdGF0ZSwgdGltZXJzIGFuZCBz dWNoLg0KTm90ZSB0aGF0IHRoZXNlIHRoaW5ncyBhcmUgbmVjZXNzYXJ5IHRvIGNhbGwgb3V0IGlu IHRoZSDigJxvdmVydmlld+KAnSBhbmQgaW4gdGhlIOKAnGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50 4oCdLCBib3RoOiBpdCBpcyBub3QgdGhhdCB0aGV5IGFyZSBuZWdhdGl2ZXMgcGVyIHNlLCBidXQg dGhhdCB0aGV5IGFyZSBpbXBvcnRhbnQgZmFjdG9ycyBnb3Zlcm5pbmcgdGhlIGFwcGxpY2FiaWxp dHkgb2YgdGhpcyBwcm90b2NvbDogd2lsbCBhIGdpdmVuIHBsYXRmb3JtIHBlcm1pdCBzdWNoIGFj Y2VzcyB0byB0aGUgZm9yd2FyZGluZyBwbGFuZSwgZm9yIGV4YW1wbGU/IEltcG9ydGFudCB0byB1 bmRlcnN0YW5kIGlmIGZvciB0aGF0IHBsYXRmb3JtIHRoaXMgcHJvdG9jb2wgaXMgYXBwbGUNCkkg c2VlIHRoYXQgdGhpcyB3YXMgbm90IGFkZHJlc3NlZCBpbiB0aGUgb3ZlcnZpZXcsIG5vciBpbiB0 aGUgYXBwbGljYWJpbGl0eSBvdGhlciB0aGFuIGJ5IGEgZm9yd2FyZCByZWZlcmVuY2UgdG8gc2Vj dGlvbiA2LjQuIFdoaWxlIGl0IGlzIHBvc2l0aXZlIHRoYXQgdGhlcmUgaXMgYSBzZWN0aW9uIDYu NCwgdGhpcyBkb2VzIG5vdCBleG9uZXJhdGUgdGhlIG92ZXJ2aWV3IGFuZCB0aGUgYXBwbGljYWJp bGl0eSBzdGF0ZW1lbnQgZm9yIGJlaW5nIGhvbmVzdCBhYm91dCB0aGUgcmVxdWlyZW1lbnRzIChu b3RhYmx5IHRvIHRoZSBwbGF0Zm9ybS9vcykgdGhhdCB0aGlzIHByb3RvY29sIGhhcyBmb3IgYmVp bmcgYXBwbGljYWJsZQ0KDQpBT0RWdjI6IFRoZSBPdmVydmlldyBhbmQgdGhlIEFwcGxpY2FiaWxp dHkgU3RhdGVtZW50IG5vdyByZWZlciB0byB0aGVzZSBiYXNpYyByZXF1aXJlbWVudHMgZm9yIHRo ZSBpbnRlcmFjdGlvbiB3aXRoIHRoZSBmb3J3YXJkaW5nIHBsYW5lLiBUaGUgQXBwbGljYWJpbGl0 eSBTdGF0ZW1lbnQgYWxzbyBjb250YWlucyB0aGUgcmVmZXJlbmNlIHRvIHRoZSBsYXRlciBzZWN0 aW9uIHdoaWNoIGRlc2NyaWJlcyB0aGlzIGluIG1vcmUgZGV0YWlsLg0KDQo4LiA3MTgyIGFuZCBz ZWN1cml0eQ0KDQpUaG9tYXM6IEkgc3VnZ2VzdGVkIGluIG15IGxhc3QgcmV2aWV3OiBJdCBpcyBp bXBvcnRhbnQgdG8gZG8gbW9yZSB0aGFuIHRoaXM6IDcxODIgZG9lcyBvbmx5IHByb3ZpZGUg4oCc Y29udGFpbmVyc+KAnSBmb3IgSUNWcyBhbmQgdGltZXN0YW1wcywgYW5kIGRvZXMgbm90IHNwZWNp ZnkgaG93IHRvIHVzZSB0aGVtIHRvIG9idGFpbiBzcGVjaWZpYyBzZWN1cml0eSBwcm9wZXJ0aWVz LiBSRkM3MTgyIG1heSBiZSBhIHRvb2wgdGhhdCBjYW4gYmUgdXNlZCwgYnV0IGhvdyogdGhhdCB0 b29sIGlzIHVzZWQgaXMgd2hhdCBkZXRlcm1pbmVzIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzLg0K VGhlcmVmb3JlLCBzYXlpbmcgdGhhdCDigJxzZWN1cml0eSBpcyBkZWFsdCB3aXRoIGJ5IHVzaW5n IFJGQzcxODLigJ0gaXMgZWl0aGVyIGFuIGluY29tcGxldGUgc3RhdGVtZW50LCBvciBpcyBpbmRp Y2F0aXZlIG9mIGluc3VmZmljaWVudCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy7igJ0NClRoZSBh Y3R1YWwgc2VudGVuY2UgaW4gdGhlIEktRCBoYXMgYmVlbiBjaGFuZ2VkLCBub3cgaXQgZXhwbGlj aXRseSBuYW1lcyB0aGUgdHdvIFRMVnMgZnJvbSA3MTgyIHRoYXQgaXQgdXNlcy4gVGhhdCBpcywg YWxhcywgc3RpbGwgbm90IHN1ZmZpY2llbnQuDQpNYWtpbmcgdGhlIGFzaWRlIHRoYXQgd2FzIGRp c2N1c3NlZCByZWNlbnRseSBvbiB0aGUgbGlzdCwgdGhhdCAoaSkgY29udHJvbCBtZXNzYWdlcyBh cmUgbm90IGZvcndhcmRlZCwgYW5kIHRoYXQgKGlpKSB0aGV5IGFyZSBtb2RpZmllZCBpbiB0cmFu c2l0LCB0aGUgc2VjdXJpdHkvdHJ1c3QgbW9kZWwgaXMgc29tZXdoYXQgZGlmZmVyZW50IGZyb20g dGhhdCBvZiA3MTgxIGFuZCBjb25zZXF1ZW50bHkgZm9yIHdoYXQgNzE4MiB3YXMgaW5pdGlhbGx5 IHdyaXR0ZW4gZm9yLiBJIHRoaW5rIHRoYXQgIGNhbGxpbmcgb3V0IHRoZSB0cnVzdCBtb2RlbCwg YW5kIGhvdyA3MTgyIGFjdHVhbGx5IGlzIHVzZWQgaGVyZSwgbWlnaHQgYmUgd2hhdCBpcyBjYWxs ZWQgZm9yLg0KQ29udGludWluZyB3aXRoIHRoZSBhc2lkZSwgdGhpcyAqZXNwZWNpYWxseSogYXMg dGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHNheXM6ICJQcm92aWRpbmcgc2VjdXJpdHkgZm9y IGEgcmVhY3RpdmUgcm91dGluZyBwcm90b2NvbCBjYW4gYmUgZGlmZmljdWx04oCdDQoNClRob21h czoNCu+7v09LLCBzbyBhc3N1bWUgdGhhdCBJIHVuZGVyc3RhbmQgcmVnZW5lcmF0aW9uIGFzIHBl ciBteSBwcmV2aW91cyBlbWFpbCwgYXMgbWVhbmluZyDigJxnZW5lcmF0ZSBhIG5ldyBtZXNzYWdl IGFuZCBzZW5kIHRvIG15IG5laWdoYm9ycywgYmFzZWQgb24gd2hhdCBJIGxlYXJuZWQgd2hlbiBw cm9jZXNzaW5nIGEgcmVjZWl2ZWQgbWVzc2FnZeKAnSDigJQganVzdCBsaWtlIGFueSBkaXN0YW5j ZSB2ZWN0b3IgcHJvdG9jb2wgZG9lcy4NCkluIHRoYXQgbW9kZWwsIHdoYXQgeW91IHdyaXRlIG1h a2VzIHNlbnNlOiBlYWNoIG9yaWdpbmF0b3Igb2YgYSBjb250cm9sIG1lc3NhZ2UgKGkuZS4sIHdo b2V2ZXIgZ2VuZXJhdGVzIG9yIHJlZ2VuZXJhdGVzIGl0KSBpcyBmcmVlIHRvIGluY2x1ZGUgdGhl IGluZm9ybWF0aW9uIGl0IGRlc2lyZXMsIHN1Y2ggYXMgdGhlIDQgcG9pbnRzIHlvdSBsaXN0IGFi b3ZlLiBObyBpc3N1ZXMgd2l0aCB0aGF0Lg0KSG93ZXZlciwgYW5kIHRoaXMgam9pbnMgd2hhdCBJ IHBvaW50ZWQgb3V0IGluIGEgcHJldmlvdXMgZW1haWwsIHlvdSB3cml0ZSBpbiB0aGUgYXBwbGlj YWJpbGl0eSBzdGF0ZW1lbnQ6ICJQcm92aWRpbmcgc2VjdXJpdHkgZm9yIGEgcmVhY3RpdmUgcm91 dGluZyBwcm90b2NvbCBjYW4gYmUgZGlmZmljdWx0LiINCldoaWxlIHdlIGNhbiBkaXNjdXNzIGlm IHRoZSBuYXR1cmUgb2Yg4oCccmVhY3RpdmUgcm91dGluZyBwcm90b2NvbOKAnSBnZW5lcmF0ZXMg cGFydGljdWxhciBkaWZmaWN1bHRpZXMsIHdlIGNlcnRhaW5seSBjYW4gYWdyZWUgdGhhdCB0aGlz IHByb3RvY29sIGhhcyB0aGUgc2FtZSDigJxkaWZmaWN1bHRpZXPigJ0gYXMgYSBkaXN0YW5jZSB2 ZWN0b3IgcHJvdG9jb2w6IHJvdXRpbmcgdG9wb2xvZ3kgaW5mb3JtYXRpb24gKGJ5IGRlZmluaXRp b24pIG5vdCBiZWluZyBleGNoYW5nZWQgZW5kLXRvLWVuZCwgYnV0IGJldHdlZW4gbmVpZ2hib3Jz ICh3aG8gZG8gY2FsY3VsYXRpb25zIGFuZCBnZW5lcmF0ZSB0aGVpciBvd24gYW5ub3VuY2VtZW50 cyDigJQgcmVnZW5lcmF0aW9uLCBhcyB5b3UgY2FsbCBpdCkuDQpUaGlzIG1lYW5zIHRoYXQgYSBz cGVjaWZpYyBzZWN1cml0eSBtb2RlbCBvZiB0cmFuc2l0aXZlIHRydXN0IG11c3QgYmUgYXNzdW1l ZCwgbm8/IEkgdHJ1c3QgVmljdG9yaWEsIHRoZXJlZm9yZSB3aGVuIFZpY3RvcmlhIHNheXMg4oCc U3RhbiB0b2xkIG1l4oCdIHRoZW4gSSB0cnVzdCB0aGF0IHNoZSBhY3R1YWxseSB2ZXJpZmllZCB0 aGF0ICJpdCB3YXMgaW5kZWVkIFN0YW4gd2hvIHRvbGQgaGVyIOKApuKAnSDigJQgYW5kIGVpdGhl ciB3YXksIEkgaGF2ZSBubyB3YXkgb2YgdmVyaWZ5aW5nPw0KSSBkaWQgbm90IHNlZSB0aGUgdHJ1 c3QgbW9kZWwgLyB0cnVzdCBhc3N1bXB0aW9uIGRpc2N1c3NlZCBpbiB0aGUgc3BlY2lmaWNhdGlv biAoc3BlY2lmaWNhbGx5IG5vdCBpbiBhcHBsaWNhYmlsaXR5IGFuZCBpbiBzZWN0aW9uIDEzLCBi b3RoIG9mIHdoZXJlIGl0IHNob3VsZCBiZSBjYWxsZWQgb3V0KSwgYnV0IEkgdGhpbmsgdGhhdCB0 aGlzIGlzIGFjdHVhbGx5IGEgY3J1Y2lhbCBwb2ludCB0byBnZXQgcmlnaHQsIGluIG9yZGVyIHRv IGFwcHJvYWNoIGRldmVsb3BpbmcgdGhlIE1USSBzZWN1cml0eSBtZWNoYW5pc21zLg0KQW55d2F5 cywgdGhhdCBvYnNlcnZhdGlvbiBhY3R1YWxseSBjb250cmFzdHMgc3Ryb25nbHkgd2l0aCB3aGF0 IHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCB0aGVuIGdvZXMgb24gdG8gc2F5LCBuYW1lbHk6 DQogICBBT0RWdjIgcHJvdmlkZXMgZm9yIG1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBzZWN1cml0eSBh Z2FpbnN0IHJlcGxheQ0KICAgYXR0YWNrcyBieSB1c2luZyBpbnRlZ3JpdHkgY2hlY2sgdmFsdWVz LCB0aW1lc3RhbXBzIGFuZCBzZXF1ZW5jZQ0KICAgbnVtYmVycywgYXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMTMuDQpUaGlzIGlzIHRydWUgb25seSBpbiBhcyBtdWNoIGFzIG1lc3NhZ2VzIGFyZSBp bmRlZWQgZXhjaGFuZ2VkIGJldHdlZW4gbmVpZ2hib3JzOiB3aGVuIHlvdSDigJxyZWdlbmVyYXRl 4oCdIGEgbWVzc2FnZSwgaS5lLiwgZ2VuZXJhdGUgYSBuZXcgbWVzc2FnZSBpbiByZXNwb25zZSB0 byByZWNlaXB0IG9mIGEgbWVzc2FnZSwgeW91IGdlbmVyYXRlIGJyYW5kIG5ldyBwYXlsb2FkIChi dXQgcG9zc2libHkgaW5jbHVkaW5nIHNvbWUgb2YgdGhlIGRhdGEgZnJvbSB0aGUgcmVjZWl2ZWQg bWVzc2FnZSwgb2YgY291cnNlKTogdGh1cywgYW55IElDVnMg4oCcZnJvbSBmYXJ0aGVyIGF3YXkg dGhhbiB0aGUgbmVpZ2hib3LigJ0gd2lsbCBiZSB1c2VsZXNzIChvciwgaWYgeW91IHplcm8gb3V0 IHRoZSBwYXJ0cyB0aGF0IHlvdSBjaGFuZ2UsIHRoZXNlIHBhcnRzIHdpbGwgbm90IGJlIHByb3Rl Y3RlZCkuDQpUaGUgYWJvdmUgc2VudGVuY2UsIHF1b3RlZCBmcm9tIHRoZSBhcHBsaWNhYmlsaXR5 IHN0YXRlbWVudCwgYW5kIHRoYXQgd2hpY2ggdHJhbnNwaXJlcyBmcm9tIHNlY3Rpb24gMTMsIHNl ZW1zIC0gY2VydGFpbmx5LCBhYnNlbnQgdGhlIHRydXN0IG1vZGVsIGFzc3VtZWQgLSB0byBzdWdn ZXN0IHRoYXQgZW5kLXRvLWVuZCBwcm90ZWN0aW9uL3ZhbGlkYXRpb24gaXMgcHJvdmlkZWQuIEJ1 dCwgdGhpcyBpcyBub3QgdGhlIGNhc2UuDQpGaW5hbGx5IHRvIHRoZSBhcHBsaWNhYmlsaXR5IHN0 YXRlbWVudCwgYSBxdWVzdGlvbjoNCklmIHNlY3VyaXR5IGFzc29jaWF0aW9ucyBjYW4gYmUgZXN0 YWJsaXNoZWQsIGVuY3J5cHRpb24gY2FuIGJlIHVzZWQgZm9yIEFPRFZ2MiBtZXNzYWdlcyB0byBl bnN1cmUgdGhhdCBvbmx5IHRydXN0ZWQgcm91dGVycyBwYXJ0aWNpcGF0ZSBpbiByb3V0aW5nIG9w ZXJhdGlvbnMuDQpXaGF0IHlvdSB3YW50IHRvIHNheSBoZXJlIGlzIHRoYXQg4oCcaWYgYWxsIHRy dXN0ZWQgcm91dGVycyBoYXZlIGEgc2hhcmVkIHNlY3JldCwgdGhlbiB3ZeKAmXJlIGFibGUgdG8g dXNlIHRoYXQgc2hhcmVkIHNlY3JldCB0byBpZ25vcmUgbm9uLXRydXN0ZWQgcm91dGVyc+KAnSwg cmlnaHQ/DQpXaGlsZSDigJxzZWN1cml0eSBhc3NvY2lhdGlvbnPigJ0gdGhhdCBkbyBub3QgcGFz cyB0aHJvdWdoIGEgc2hhcmVkIHNlY3JldCBwcm9iYWJseSBjYW4gYmUgdGhvdWdodCB1cCwgaXTi gJlzIG5vdCB0cml2aWFsIGFuZCBJIGRpZCBub3QgZmluZCBhbnkgZGlzY3Vzc2lvbiBvZiB0aGF0 IGluIHRoZSBkb2N1bWVudD8NCkhhdmluZywgb24gdGhlIHRvcGljIG9mIHNlY3VyaXR5LCByZS1y ZWFkIFNlY3Rpb24gMTMsIHdoaWNoIHN0YXJ0czoNCiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMg dmFyaW91cyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgcG90ZW50aWFsDQogICBhdmVudWVz IHRvIHNlY3VyZSBBT0RWdjIgcm91dGluZy4NCldoaWxlIHRoaXMgaXMgYW4gaG9uZXN0IGRlc2Ny aXB0aW9uIG9mIHdoYXQgZm9sbG93cywgSSByZW1haW4gY29udmluY2VkIHRoYXQgdGhpcyBpcyBu b3Qgc3VmZmljaWVudC4gU28gbGV0IG1lIGFzayBhcyBwcmVjaXNlbHkgYXMgSSBjYW46DQpvIHdo YXQgaXMgdGhlIE1USSBzZWN1cml0eSBtZWNoYW5pc20gdGhhdCBhIGNvbmZvcm1hbnQgaW1wbGVt ZW50YXRpb24gbXVzdCBwcm92aWRlPyBTcGVjaWZpY2FsbHk6IC0gd2hpY2ggYXJlIHRoZSBwcm9j ZXNzaW5nIHN0ZXBzIChmb3IgZXhhbXBsZSBpbiBzZWN0aW9uIDcuMi4xIGFuZCBzZWN0aW9uIDcu Mi4yIGZvciBSUkVQIC0gYW5kIHNpbWlsYXJseSBmb3IgdGhlIG90aGVyIG1lc3NhZ2UgdHlwZXMp IHRoYXQgZGVmaW5lIHRoYXQgc2VjdXJpdHkgbWVjaGFuaXNtDQpvIHdoYXQgcHJvdGVjdGlvbiBp cyBvZmZlcmVkIGJ5IHRoYXQgTVRJIHNlY3VyaXR5IG1lY2hhbmlzbT8gQW5kIHdoYXQgcmVtYWlu cyB2dWxuZXJhYmxlLg0KSWYgdGhpcyBzcGVjaWZpY2F0aW9uIHRhcmdldHMgc3RkLnRyYWNrLCB0 aGVuIGl0IHNob3VsZCBpbmNsdWRlIChyZWFzb25hYmx5IHNvbGlkLCBidXQgZGVmaW5pdGVseSB3 ZWxsIHNwZWNpZmllZCkgTVRJIHNlY3VyaXR5Lg0KDQpDaHJpcyBEZWFybG92ZToNCu+7v1RoZXJl IGFyZSB0d28gcG90ZW50aWFsIGNob2ljZXM6DQoNCi0gUlJFUSBoYXMgYW4gaW50ZWdyaXR5IGNo ZWNrIHZhbHVlIHRvIGluZGljYXRlIHRoYXQgc29tZW9uZSB0cnVzdGVkIGNyZWF0ZWQgaXQsIGlm IG5vdCBuZWNlc3NhcmlseSB0aGUgZGVzdGluYXRpb24uIFRoYXQgc29tZW9uZSBtaWdodCBiZSBp ZGVudGlmaWFibGUgb3Igbm90Lg0KLSBSUkVRIGhhcyBhIHNpZ25hdHVyZSB0aGF0IGluZGljYXRl cyB0aGF0IHRoZSBkZXN0aW5hdGlvbiBjcmVhdGVkIGl0Lg0KDQpVbmZvcnR1bmF0ZWx5LCBhbiBS UkVRIHRoYXQgY2hhbmdlcyBhcyBpdCBpcyBmb3J3YXJkZWQgKGFnZ3JlZ2F0aW5nIGRhdGEgb2Yg YW55IHNvcnQpIG1ha2VzIHRoZSBzZWNvbmQgb3B0aW9uIHRyaWNreSwgdW5sZXNzIHRoZXJl4oCZ cyBzb21lIHNvcnQgb2YgYWdncmVnYXRpbmcgc2lnbmF0dXJlIGFzIGl0IGlzIGZvcndhcmRlZC4g QnV0IEnigJltIG5vdCBhbiBleHBlcnQgb24gdGhlIGxhdHRlci4NCg0KVGhlIG1vc3QgdHJpdmlh bCBjYXNlIG9mIHRoZSBmb3JtZXIgaXMgc2ltcGx5IHRoYXQgZXZlcnlvbmUgdHJ1c3RlZCBoYXMg YSBzaW5nbGUgc2hhcmVkIGtleS4gVGhhdCBoYXMgb2J2aW91cyBpc3N1ZXMg4oCTIGFsdGhvdWdo IGl0IHdhcyBnb29kIGVub3VnaCB0aGF0IGVtYm9kaWVkIGFzIFJGQyA3MTgzIHdlIGNvdWxkIGdl dCA3MTgxIHRocm91Z2ggdGhlIHN5c3RlbSAoYXMgYSDigJxtdXN0IGltcGxlbWVudCwgZG8gbm90 IG5lZWQgdG8gdXNl4oCdIG1pbmltYWwgY2FzZSkuIEFsdGVybmF0aXZlbHkgc29tZXRoaW5nIGlk ZW50aXR5LWJhc2VkIChlLmcuIGRyYWZ0LWlldGYtbWFuZXQtaWJzKSBjb3VsZCBiZSB1c2VkLCBz byB5b3Uga25vdyB3aG8gY3JlYXRlZCB0aGUgbWVzc2FnZSB5b3UgcmVjZWl2ZWQsIGJ1dCB5b3Ug YXJlIHJlbHlpbmcgb24gYSBjaGFpbiBvZiB0cnVzdCwgaG9wIGJ5IGhvcC4gQXQgd2hpY2ggcG9p bnQgeW91IG1pZ2h0IGFzIHdlbGwganVzdCBzaWduIHBhY2tldHMgKHNlZSBSRkMgNzE4MikuDQoN CkJ1dCBpbiBldmVuIHRoZSB3ZWFrZXN0IGNhc2UgKHRoZSBzaW5nbGUgc2hhcmVkIGtleSB1c2Vk IGhvcCBieSBob3ApIHRoZXJlIGhhcyB0byBiZSBhIGZhaWx1cmUgZm9yIHRoaW5ncyB0byBnbyB3 cm9uZyAtIGVpdGhlciBsb3NzIG9mIGtleSAoaW4gd2hpY2ggY2FzZSBhbGwgYmV0cyBhcmUgb2Zm KSBvciBzdWJvcm5pbmcgb25lIHJvdXRlciAod2hvIGNhbiBkbyBxdWl0ZSBhIGxvdCBvZiBkYW1h Z2UpLg0KDQpJIGhhdmVuJ3QgcmVhZCB0aGUgbGF0ZXN0IEFPRFZ2MiBkcmFmdCB5ZXQsIGJ1dCB0 aGlzIHNvcnQgb2YgdGhpbmcgc2hvdWxkIGJlIGRlc2NyaWJlZCBpbiBpdHMgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgLSB0aGUgcHJldmlvdXMgZHJhZnQgdGhvdWdoIGRpZG4ndCBkaXNjdXNzIHRo aXMgYXMgZmFyIGFzIEkgcmVjYWxsLg0KDQpDaHJpcyBEZWFybG92ZToNCu+7v0lmIHlvdSBnbyBk b3duIHRoaXMgcm91dGUgb2YgYXNzdW1pbmcgdHJhbnNpdGl2ZSB0cnVzdCwgdGhlbiB5b3UgbWln aHQgYXMgd2VsbCB1c2UgNzE4MuKAmXMgcGFja2V0IElDViBhbmQgdGltZXN0YW1wIHJhdGhlciB0 aGFuIG1lc3NhZ2UgSUNWIGFuZCB0aW1lc3RhbXAuDQoNClRoZXJlIGlzIGEgY29tcGxpY2F0aW9u IChtb3N0bHkgb25lIG9mIHByZXNlbnRhdGlvbikgdGhhdCB0aGUgNTQ0NCBtdWx0aXBsZXhlciAo cmF0aGVyIHRoYW4gQU9EVnYyKSBuZWVkcyB0byBkbyB0aGlzLCBhdCBsZWFzdCBmb3IgcGFja2V0 cyBjb250YWluaW5nIEFPRFZ2MiBtZXNzYWdlcyAoYnV0IGF0IHdoaWNoIHBvaW50LCBwcm9iYWJs eSBhbGwgNTQ0NCBwYWNrZXRzKS4gU28geW91IGVpdGhlciwgZGVwZW5kaW5nIG9uIHlvdXIgcG9p bnQgb2YgdmlldywgbmVlZCB0byByZXF1ZXN0IGl0IHRvIGRvIHRoYXQsIG9yIChhZG1pbmlzdHJh dGl2ZWx5KSBkZWNsaW5lIHRvIG9wZXJhdGUgZXhjZXB0IG92ZXIgYSA1NDQ0IG11bHRpcGxleGVy IHRoYXQgaXMgZG9pbmcgdGhpcy4NCg0KVGhlIGFkdmFudGFnZSBpcyBvbmUgb2Ygc2F2ZWQgc3Bh Y2UgYW5kIHRpbWUgd2hlbiBwYWNrZXRzIGNvbnRhaW4gbW9yZSB0aGFuIG9uZSBtZXNzYWdlLiBQ bHVzIHNsaWdodGx5IGJldHRlciBwcm90ZWN0aW9uIChob3AgY291bnQgYW5kIGxpbWl0IGFyZSBj b3ZlcmVkKSBidXQgd2hpY2ggcHJvYmFibHkgZG9lc27igJl0IG1hdHRlciBoZXJlLg0KDQpJZiBt ZXNzYWdlcyBhcmUgY2hhbmdlZC9yZXBsYWNlZCBvbiBhIG9uZS10by1vbmUgYmFzaXMgYXMgZm9y d2FyZGVkLCB0aGVuIHRoZSBvbmx5IHNvbHV0aW9ucyBJIGNhbiBzZWUgYXJlIGhvcCBieSBob3Ag dHJhbnNpdGl2ZSB0cnVzdCAocGFja2V0cyBvciBtZXNzYWdlcyBwZXIgaG9wKSwgb3Igc29tZXRo aW5nIGNvbXBsaWNhdGVkIGludm9sdmluZyBhZ2dyZWdhdGlvbiBhbmQga25vd2xlZGdlIG9mIGNo YW5nZXMuIEJ1dCB0aGUgbGF0dGVyIHdvdWxkIGJlIGEgcmVzZWFyY2ggdGFzayB0byBkZXZlbG9w LCBzbyBsZXTigJlzIG5vdCB0cnkgdGhhdC4NCg0KSmlhemkgWWk6DQpJ77u/IGFncmVlIHdpdGgg Q2hyaXMgYW5kIFRob21hcyBvbiB0aGVpciBjb25jZXJucyBvbiB0aGUgaG9wLWJ5LWhvcCBzZWN1 cml0eSBpc3N1ZS4NClRoaXMgaXMgdmVyeSBkaWZmZXJlbnQgZnJvbSBjbGFzc2ljYWwgRFYgcHJv dG9jb2wsIGluIHdoaWNoIHRoZSB2ZWN0b3IgaW5mb3JtYXRpb24gaXMgZGVzaWduZWQgdG8gYmUg ZXhjaGFuZ2VkIGJldHdlZW4gbmVpZ2hib3Vycy4NCkluIEFPRFZ2MiwgdGhlIFJSRVEvUlJFUC9S RVJSIGFyZSB0byBiZSBmb3J3YXJkZWQgdGhyb3VnaCBtdWx0aXBsZSBob3BzLiBBIHJvdXRlciBj YW4gc2lnbiBhIG1lc3NhZ2UgdGhhdCBpc24ndCBhY3R1YWxseSBpbml0aWFsaXNlZCBieSBpdHNl bGYgLS0gdGhpcyBpcywgYXQgbGVhc3QsIGFnYWluc3QgaW50dWl0aW9uLg0KVGhpcyBjYW4gYmUg YW4gaXNzdWUgaWYgd2UgaGF2ZSBjb21wcm9taXNlZCByb3V0ZXJzIGluIHRoZSBuZXR3b3JrLiBP ZiBjb3Vyc2UsIGEgY29tcHJvbWlzZWQgcm91dGVyIGlzIGEgcHJvYmxlbSBmb3IgZXZlcnkgcHJv dG9jb2wsIGxpa2UgT0xTUnYyLiBCdXQgaW4gT0xTUnYyLCBhIGNvbXByb21pc2VkIHJvdXRlciBj YW4gb25seSBzcGVhayBvbiBiZWhhbGYgb2YgaXRzZWxmIC0tIGhvd2V2ZXIsIGluIEFPRFZ2Miwg YSBjb21wcm9taXNlZC9taXMtY29uZmlndXJlZCByb3V0ZXIgY2FuIHByZXRlbmQgdG8gYmUgYW55 IG90aGVyIHJvdXRlciAoZm9yIGV4YW1wbGUsIGdlbmVyYXRlIFJSRVEgbWVzc2FnZXMgdXNpbmcg YW5vdGhlciBhZGRyZXNzIGFzIE9yaWdBZGRyKS4gIFRoZSBjb25zZXF1ZW5jZSB3aWxsIGJlIG11 Y2ggbW9yZSBzZXJpb3VzIGlmIHRoYXQgaGFwcGVucy4NCg0KQU9EVnYyOiBUaGlzIGlzIG5vdCB5 ZXQgYWRkcmVzc2VkLg0KDQo5LiBUZXJtaW5vbG9neSAtIGhvc3QsIHJvdXRlcnMsIHJvdXRlciBj bGllbnRzOg0KDQpUaG9tYXM6IE15IGxhc3QgcmV2aWV3IHN1Z2dlc3RlZDoNCuKAnFRoaXMgaGFz IGJlZW4gYnJvdWdodCB1cCBvbiB0aGUgbGlzdCBzZXZlcmFsIHRpbWVzIGluIHRoZSBwYXN0LCB3 aXRob3V0IGhhdmluZyBiZWVuIGFkZHJlc3NlZC4NClRoZXJlIGFyZSDigJxob3N0c+KAnSBhbmQg dGhlcmUgYXJlIOKAnHJvdXRlcnPigJ0g4oCUIHdob3NlIHJvbGVzIGFyZSB3ZWxsIGRlZmluZWQu IE5vZGXigJ0gbm90IHNvIG11Y2gg4oCUIHdoaWNoIGlzIGNsZWFyIGZyb20gbG9va2luZyBhdCB0 aGUgZGVmaW5pdGlvbiBoZXJlOiDigJxlaXRoZXIgQU9EVnYyIHJvdXRlcnMgb3Igcm91dGVyIGNs aWVudHPigJ0gKHdpdGgg4oCccm91dGVyIGNsaWVudHPigJ0gYmVpbmcgZGVmaW5lZCBhcyDigJxh biBBT0RWdjIgcm91dGVyIGlzIGFsc28gaXRzIG93biByb3V0ZXIgY2xpZW504oCdKS4NCg0KVGhp cyBpcyB2ZXJ5IG11Y2ggcmVsYXRlZCB0byB0aGUgdXNlIG9mIOKAnFJvdXRlciBDbGllbnTigJ0s IGFuZCBib3RoIHRoYXQgdGVybSwgYW5kIOKAnG5vZGXigJ0gaW5kaWNhdGl2ZSB0aGF0IHNvbWUg Y2xhcml0eSBpcyBuZWVkZWQgaGVyZS4NCg0KQWxsIGEgcm91dGVyIGNhcmVzIGFib3V0IGlzIOKA nGFuIGFkZHJlc3PigJ0uIElmIHRoYXQgYWRkcmVzcyBpcyBvZiBhIG5ldHdvcmssIG9yIGEgcm91 dGVyLCBvciBhbiBpbnRlcmZhY2UgKGFuZCwgaWYgc2FpZCBpbnRlcmZhY2UgaXMgaW5zdGFsbGVk IGluIGEgcm91dGVyIG9yIGEgaG9zdCkgZG9lc27igJl0IG1hdHRlci4NCg0KU28sIOKAnGFuIGFk ZHJlc3PigJ0gaXMgc29tZXRoaW5nIHRoYXQgdGhlIHJvdXRpbmcgcHJvdG9jb2wgc2hvdWxkIGNh cmUgYWJvdXQgZmluZGluZyBwYXRocyB0by4gV2hpY2ggbWVhbnMgdGhhdCBlYWNoIGFkZHJlc3Mg dGhhdCBzaG91bGQgYmUgbWFkZSByZWFjaGFibGUgYnkgdGhlIHJvdXRpbmcgcHJvdG9jb2wgc2hv dWxkIGJlIGFkdmVydGlzZWQgYnkgKGF0IGxlYXN0KSBvbmUgcm91dGVyIGluIHRoZSBuZXR3b3Jr Lg0KDQpPbmUgd2F5IG9mIGRvaW5nIHRoYXQgd291bGQgYmUgdG8gc2ltcGx5IHRhbGsgYWJvdXQg 4oCcQXR0YWNoZWQgTmV0d29ya3PigJ0gYXMgaXMgZG9uZSBpbiBSRkM3MTgxLCB3aGVyZWluIGFu IGFkZHJlc3MgaW5jbHVkZWQgaW4gdGhlIOKAnEF0dGFjaGVkIE5ldHdvcmsgU2V04oCdIGlzIGFk dmVydGlzZWQgYnkgYW4gT0xTUnYyIHJvdXRlci4uLi5pbiB0aGlzIGNhc2UsIHRoZSBlcXVpdmFs ZW50IHdvdWxkIGJlIOKAnGZvciBlYWNoIGFkZHJlc3MgaW4gdGhlIEF0dGFjaGVkIE5ldHdvcmsg U2V0IG9mIGFuIEFPRFZ2MiByb3V0ZXIgdGhlIHJvdXRlciBNVVNUIHJlc3BvbmQgYXV0aG9yaXRh dGl2ZWx5IHRvIGEgUlJFUSwgYW5kIE1VU1QgbWFpbnRhaW4gdGhlIGNvcnJlc3BvbmRpbmcgc2Vx dWVuY2UgbnVtYmVy4oCdLg0KVGhlIHRleHQsIGFzIGl0IGN1cnJlbnRseSBpcywgaXMgcmVhbGx5 IGhhcmQgdG8gcmVhZCwgYW5kIGEgcmUtZWRpdCBhbG9uZyB0aGVzZSBsaW5lcyB3b3VsZCBnbyBh IGxvbmcgd2F5LuKAnQ0KDQpJIG5vdGUgdGhhdCB0aGUgdGVybXMg4oCcTm9kZeKAnSBhbmQg4oCc Um91dGVyIENsaWVudOKAnSBhcmUgc3RpbGwgdXNlZCwgaW4gdGhlaXIgb3JpZ2luYWwgZm9ybSwg YW5kIHRoYXQgb3RoZXIgdGhhbiBzb21lIHNsaWdodCB3b3Jkc21pdGhpbmcgdGhpcyBjb21tZW50 IGhhcyBub3QgYmVlbiBhZGRyZXNzZWQgaW4gdGhlIGRvY3VtZW50Lg0KDQpJIHJlaXRlcmF0ZSB0 aGF0IHRoZSBuZWVkIHRvIHVzZSByb3V0ZXIsIGhvc3QsIG5vZGUsIGFuZCByb3V0ZXIgY2xpZW50 IGluIGFuZCBieSBpdHNlbGYgc2hvdWxkIGJlIGFuIGluZGljYXRvciB0aGF0IHRpZ2h0ZW5pbmcg dXAgb2YgdGVybWlub2xvZ3kgaXMgcmVxdWlyZWQuDQoNCkFPRFZ2MjogU2VlIDUuIFRoZSB1c2Ug b2Yg4oCcbm9kZeKAnSBoYXMgYmVlbiBhZGRyZXNzZWQuDQoNCjEwLiBUZXJtaW5vbG9neSBhbmQg ZWxzZXdoZXJlIC0gYWRkcmVzcw0KVGhvbWFzOiBJIG1hZGUgdGhlIGZvbGxvd2luZyBjb21tZW50 IHRvIFJvdXRhYmxlIFVuaWNhc3QgSVAgQWRkcmVzczoNCuKAnEFyZSB0aGVyZSBhbnkgdGVjaG5p Y2FsIHJlYXNvbiB3aHkgbm90IHNpbXBseSAqYW55KiBhZGRyZXNzIGNvdWxkIGJlIGNvbnNpZGVy ZWQgYnkgdGhlIHJvdXRpbmcgcHJvdG9jb2w/DQpNeSB1bmRlcnN0YW5kaW5nLCBidXQgY29ycmVj dCBtZSBpZiBJIGFtIHdyb25nLCBpcyB0aGF0IGFsbCB0aGF0IGlzIHJlcXVpcmVkIGlzIHRoYXQg YWxsIGludGVyZmFjZXMgaW4gYSBnaXZlbiBBT0RWdjIgcm91dGluZyBkb21haW4gaGFzIGFuIHVu aXF1ZSBhZGRyZXNzLg0KVGhhdCBzb21lIG9mIHRoZXNlIGFkZHJlc3NlcyAoYnkgYW4gSVAgYWRk cmVzc2luZyBhcmNoaXRlY3R1cmUgZG9jdW1lbnQpIGhhcyBzcGVjaWFsIHNlbWFudGljcyBhc3Nv Y2lhdGVkIChzdWNoIGFzIGFyZSBsaW5rIGxvY2Fscywgb3IgYXJlIGZvciBwcml2YXRlIHVzZSwg b3IgYXJlIGZvciBleGFtcGxlIHVzZSBvbmx5LCBvciBhcmUgZm9yIG11bHRpY2FzdCkgaXMgb3V0 IG9mIHNjb3BlIGhlcmU/DQpJIHNlZSBub3RoaW5nIGhhcyBjaGFuZ2VkIG9uIHRoZSBhYm92ZSwg c28gbGV0IG1lIGJlIG1vcmUgZXhwbGljaXQ6IHRoZSByb3V0aW5nIHByb3RvY29sIGl0c2VsZiBw cm9iYWJseSkgc2hvdWxkIG5vdCBjYXJlIGFib3V0IHdoYXQga2luZCBvZiBhZGRyZXNzZXMgYXJl IGZpbGxlZCBpbnRvIGl0LiBJcyBhbiAxOTIuMTYuLzE2IGFkZHJlc3MgYXBwcm9wcmlhdGU/IE5v dCBhY3Jvc3MgdGhlIGludGVybmV0LCBidXQgaXQgbWF5IGJlIGluIHNvbWVib2R54oCZcyBwcml2 YXRlIGRlcGxveW1lbnRzLiBTaG91bGQgdGhlIHJvdXRpbmcgcHJvdG9jb2wgYmUg4oCcYWRkcmVz cyBwb2xpY2XigJ0gYW5kIGlzIGltcGxlbWVudGF0aW9uIG9mIGEg4oCcSSByZWZ1c2UgdG8gcm91 dGUgdGhlc2UgYWRkcmVzc2Vz4oCm4oCdIGEgcmVxdWlyZW1lbnQgZm9yIGNsYWltaW5nIGNvbmZv cm1hbmNlPyBTdWdnZXN0IHNpbXBseSBzdGF0aW5nIHdoYXQgdGhlIHJlcXVpcmVtZW50cyBhcmUg dW5kZXIgd2hpY2ggdGhlIHJvdXRpbmcgcHJvdG9jb2wgd2lsbCB3b3JrIOKAlCBhbmQgbGVhdmUg 4oCcYWRkcmVzcyBhc3NpZ25tZW50IHBvbGl0aWNz4oCdIGFzaWRlLg0KDQpBT0RWdjI6IFdlIGFz ayBmb3IgY2xhcmlmaWNhdGlvbiBvbiB0aGlzIGlzc3VlLiBXZSB1c2UgdGhlIHBocmFzZSDigJxy b3V0YWJsZSBhbmQgdW5pY2FzdOKAnSBpbiB0aGUgZHJhZnQgd2l0aCByZXNwZWN0IHRvIE9yaWdB ZGRyIGFuZCBUYXJnQWRkci4gV2UgZG9udCBtZWFuIHRvIGV4Y2x1ZGUgYWRkcmVzc2VzIGZyb20g dGhlIHByaXZhdGUgYWRkcmVzcyByYW5nZXMuIEJ1dCB3ZSBkb250IHdhbnQgdG8gcmVxdWVzdCBy b3V0ZXMgZm9yIG11bHRpY2FzdCwgaW5kZXRlcm1pbmF0ZSwgbGluay1sb2NhbCwgb3IgbG9vcGJh Y2sgYWRkcmVzc2VzLiBUaGlzIGlzIG5vdCBhYm91dCByb3V0ZXIgaW50ZXJmYWNlIGFkZHJlc3Nl cyB3aGljaCBhcmUgdXNlZCBmb3IgQU9EVnYyLg0KDQoxMS4gTXVsdGlwbGUgaW50ZXJmYWNlcyB3 aXRoIHRoZSBzYW1lIElQIGFkZHJlc3MsIDY2MjEgaW1wbGljYXRpb25zDQoNClRob21hczogSSBh bHNvIGNvbnRpbnVlZDoNCk5vdywgd2l0aCB0aGF0IGJlaW5nIHNhaWQgYWxzbywgdGhlIFdHIHdh bnRlZCB0aGF0IFJGQzcxODEgc3VwcG9ydHMgbm90IGp1c3QgbXVsdGlwbGUgaW50ZXJmYWNlcywg YnV0IGFsc28gdGhlIHNhbWUgYWRkcmVzcyB1c2VkIG9uIG11bHRpcGxlIGludGVyZmFjZXMgb2Yg dGhlIHNhbWUgcm91dGVyLiBUaGVyZSB3ZXJlIGdvb2QgcmVhc29ucyBmb3IgdGhhdCwgYW5kIHdo aWxlIGl0IHdhcyBub3QgdHJpdmlhbCB0byBpbXBsZW1lbnQsIGl0IHR1cm5lZCBvdXQgdG8gYmUg dGhlIHJpZ2h0IHRoaW5nIHRvIHN1cHBvcnQuIElmIHRoZXJlIGFyZSB0ZWNobmljYWwgcmVhc29u cyB3aHkgdGhpcyBpcyBub3Qgc3VwcG9ydGVkIGluIEFPRFZ2MiAoZm9yIGV4YW1wbGUsIGlmIHRo aXMgY2Fubm90IGJlIG1hZGUgd29yayBiZWNhdXNlIG9mIDxyZWFzb24+KSB0aGVuIHRoYXQgc2hv dWxkIGJlIGNhbGxlZCBvdXQgaW4gdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGFsc28/DQpD b252ZXJzZWx5LCBpZiBpdCBpcyBwb3NzaWJsZSBpbiBBT0RWdjIsIHRoZW4gSSBkbyBub3QgYmVs aWV2ZSB0aGF0IGl0IGlzIGNsZWFybHkgc3BlY2lmaWVkIGhvdyAoYXQgbGVhc3QsIGluIHRoZSDi gJxuYWl2ZeKAnSBvbiBwYXBlciBleGFtcGxlcyBJIGRyZXcgdXAsIHNvbWV0aGluZyBlbmRlZCB1 cCBub3Qgd29ya2luZykuIFNvIGVpdGhlciB0aGUgcHJvdG9jb2wgYXMtaXMgZG9lcyBub3Qgc3Vw cG9ydCBpdCAoYnV0IGNvdWxkIGJlIG1hZGUgdG8/KSBvciBpdCBpcyBzdXBwb3J0ZWQgKGJ1dCBq dXN0IG5lZWQgdG8gYmUgc3BlbGxlZCBvdXQpLCBvciBpcyBub3QgcG9zc2libGUgKGFuZCBuZWVk IHRvIGJlIGRpc2NsYWltZWQgaW4gdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50KS4NClN0YW4g UmF0bGlmZiB3YXMgYSBkcml2aW5nIGZvcmNlIGluIGhvbGRpbmcgdGhlIFdH4oCZcyBjb2xsZWN0 aXZlIGZlZXQgdG8gdGhlIGZpcmUgaW4gZ2V0dGluZyB0aGlzIHN1cHBvcnQgaW5jbHVkZWQgaW4g UkZDNzE4MSwgYW5kIHdvdWxkIGxpa2VseSBiZSB0aGUgcmlnaHQgcGVyc29uIHRvIGNvbnN1bHQg b24gdGhpcyBtYXR0ZXI/DQpJIGFjdHVhbGx5IGhhdmUgbm90IHNlZW4gY2hhbmdlcywgb3IgY29t bWVudHMsIG9uIHRoaXMuIEluIE9MU1J2MiwgdGhlIFdHIHdhcyBtYWtpbmcgaXQgYSBzdHJvbmcg cmVxdWlyZW1lbnQgdGhhdCBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gdXNlIHRoZSBzYW1lIElQ IGFkZHJlc3Mgb24gZGlmZmVyZW50IGludGVyZmFjZXMgb2YgYSByb3V0ZXIuIEl0IHdhcyBzb21l d2hhdCB0ZWRpb3VzIHRvIGRlc2lnbiBhcm91bmQsIGJ1dCBpdCB3YXMgd29ya2VkIG91dCwgYW5k IHRoZSBjb25kaXRpb25zIHVuZGVyIHdoaWNoIHRoYXQgd2FzIHBvc3NpYmxlIHdlcmUgZGVmaW5l ZCBhbmQgZG9jdW1lbnRlZC4NCkkgd291bGQgbGlrZSB0byBzZWUgdGhlIHNhbWUgZG9uZSBmb3Ig dGhpcyBwcm90b2NvbC4NCkkgYWxzbyBub3RlIHRoYXQgdGhpcyBpcyBub3QgdW5yZWxhdGVkIHRv IFJGQzY2MjEtZGlzY3Vzc2lvbnMuIEZvciBleGFtcGxlLCB3aGVuIHNlbGVjdGluZyBTLU1QUnMg b24gYSBtdWx0aS1pbnRlcmZhY2UgYW5kIG11bHRpLWFkZHJlc3MtcGVyLWludGVyZmFjZSByb3V0 ZXIsIGNhcmUgbXVzdCBiZSB0YWtlbiBsZWFzdCB0aGluZ3Mgd29u4oCZdCB3b3JrLiBTbywgaWYg KGFuZCB0aGlzIGxpbmtzIGJhY2sgdG8gcHJldmlvdXMgbWFpbHMpIFJGQzY2MjEgaXMgYSByZXF1 aXJlbWVudCBvciBkZXNpcmUgZm9yIHRoaXMgcHJvdG9jb2wsIHRoZW4gdGhlcmUgYXJlIHNvbWUg Y29uc2lkZXJhdGlvbnMgcmVxdWlyZWQgaGVyZS4NCg0KQU9EVnYyOiBXZSBoYXZlIHJlbW92ZWQg cmVmZXJlbmNlcyB0byBSRkMgNjYyMS4NCkluaXRpYWwgdGhvdWdodHMgb24gdGhpcyB0b3BpYyBv ZiBtdWx0aXBsZSBpbnRlcmZhY2VzIHVzaW5nIHRoZSBzYW1lIElQIGFkZHJlc3MsIGlzIHRoYXQg dGhpcyB3b3VsZG7igJl0IGNhdXNlIGEgcHJvYmxlbSwgaWYgdGhlIHJvdXRlciBoYXMgb25seSBv bmUgc2VxdWVuY2UgbnVtYmVyLiBIb3dldmVyLCB0aGlzIGlzIHVwIGZvciBmdXJ0aGVyIGRpc2N1 c3Npb24uDQoNCjEyLiBJbnRlcmZhY2VzIGNvbmZpZ3VyZWQgYXMgcm91dGVyIGNsaWVudHMNCg0K VGhvbWFzOiBJIHNlZSB0aGF0IHRoZSBkZWZpbml0aW9uIG9mIOKAnFJvdXRlciBDbGllbnTigJ0g aGFzIGNoYW5nZWQgdG8gYmUNCuKAnEFuIGFkZHJlc3Mgb3IgYWRkcmVzcyByYW5nZeKApnRoZSBB T0RWdjIgcm91dGVy4oCZcyBpbnRlcmZhY2UgYWRkcmVzc2VzIGFyZSBhbHNvIGNvbmZpZ3VyZWQg YXMgcm91dGVyIGNsaWVudHPigJ0NCkJldHRlciB0aGFuIGJlZm9yZSwgYnV0IHN0aWxsIG1pc3Np bmcgdGhlIHRhcmdldC4gVGhlIHRlcm0g4oCcUm91dGVyIENsaWVudOKAnSBpcywgYXMgSSBpbmRp Y2F0ZWQgbnVtZXJvdXMgdGltZXMgYmVmb3JlLCBvZGQuDQpCdXQgdGhlIHNlY29uZCBwYXJ0IG9m IHRoZSBzZW50ZW5jZSwgZG9lcyB0aGF0IG1lYW4gKHdoYXQgaXQgc2F5cykgdGhhdCB0aGUgaW50 ZXJmYWNlcyBtdXN0IGJlIGNvbmZpZ3VyZWQgc3BlY2lhbGx5LCBzbyBhcyB0byBiZSBhYmxlIHRv IGJlIOKAnHJvdXRlciBjbGllbnRz4oCdPyBUaGF0IGNhbuKAmXQgYmUgdHJ1ZS4NCldoYXQgeW91 IGxpa2VseSBtZWFuIGlzOg0KQW4gQU9EVnYyIHJvdXRlciBpcyBjb25maWd1cmVkIHNvIGFzIHRv IGNvbnNpZGVyIGl0cyBvd24gaW50ZXJmYWNlcyBhcyBwYXJ0IG9mIHRoZSBsb2NhbGx5IGF0dGFj aGVkIG5ldHdvcmsgc2V04oCdID8NCllvdSBjb25maWd1cmUgdGhlIHJvdXRlciwgcmlnaHQ/IE5v IHNwZWNpYWwg4oCcaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24gcHJvcGVydGllc+KAnSBhcmUgcmVx dWlyZWQgZm9yIGFuIGludGVyZmFjZSB0byBiZSBhbm5vdW5jYWJsZSBieSAgYW4gQU9EVnYyIHJv dXRlcj8gKEFuZCwgZ2V0dGluZyByaWQgb2Ygbm9kZSB3b3VsZCBhY3R1YWxseSBtYWtlIHRoZSBk ZWZpbml0aW9uIHNob3J0ZXIgYW5kIG5pY2VyKQ0KDQpBT0RWdjI6IFRoZSB3b3JkaW5nIHdlIHVz ZSBzYXlzOiAiVGhlIElQIEFkZHJlc3NlcyBvZiB0aGUgcm91dGVyJ3MgaW50ZXJmYWNlcyB3aWxs IGFwcGVhciBpbiB0aGUgUm91dGVyIENsaWVudCBUYWJsZS4iIGFuZCBpbiB0aGUgVGVybWlub2xv Z3k6ICJUaGUgQU9EVnYyIHJvdXRlcidzIGludGVyZmFjZSBhZGRyZXNzZXMgYXJlIGFsc28gY29u ZmlndXJlZCBhcyBSb3V0ZXIgQ2xpZW50cy4iIEJvdGggc3RhdGVtZW50cyBzYXkgdGhhdCDigJhp bnRlcmZhY2UgYWRkcmVzc2VzIGFyZSBjb25maWd1cmVkIGFzIHJvdXRlciBjbGllbnRz4oCZIC4u LndlIGFyZSBub3Qgc3VyZSB3aHkgdGhpcyBpcyBtaXN1bmRlcnN0b29kLiBXZSBoYXZlIGEgcm91 dGVyIGNsaWVudCBsaXN0LCBhbmQgdGhlIEFPRFZ2MiByb3V0ZXLigJlzIGludGVyZmFjZSBhZGRy ZXNzZXMgYXJlIGluY2x1ZGVkIGluIHRoaXMgbGlzdC4gVGhlIGludGVyZmFjZSBpdHNlbGYgZG9l c27igJl0IGhhdmUgc3BlY2lhbCDigJxpbnRlcmZhY2UgY29uZmlndXJhdGlvbiBwcm9wZXJ0aWVz 4oCdLg0KDQoxMyAtIG1vcmUgb24gcm91dGVyIGNsaWVudHMNClRob21hczogTm93LCBzbmlwcGlu ZyBvdXQgZnJvbSB0aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQ6DQoiTXVsdGktaG9taW5nIG9m IGFuIElQIGFkZHJlc3MgaXMgbm90IHN1cHBvcnRlZCBieSBBT0RWdjIsIGFuZCB0aGVyZWZvcmUg YSBSb3V0ZXIgQ2xpZW50LCBpLmUuIGFuIElQIEFkZHJlc3MsICDigKYgIg0K4oCmZXZpZGVuY2Ug dG8gdGhlcmUgYmVpbmcgc29tZSByZWR1bmRhbnQgdGVybWlub2xvZ3kgaGVyZSB0byB3ZWVkIGF3 YXkuDQoNCkFPRFZ2MjogVGhhdCB3YXMgdGhlcmUgYXMgYSByZW1pbmRlciB0aGF0IGEgcm91dGVy IGNsaWVudCBpcyBiYXNlZCBvbiBJUCBhZGRyZXNzLCBldmVuIHRob3VnaCB0aGUgZGV2aWNlIHdp dGggdGhhdCBJUCBhZGRyZXNzIG1heSBoYXZlIG90aGVyIElQIGFkZHJlc3NlcyB0b28uIEl04oCZ cyB0aGUgSVAgYWRkcmVzcyB0aGF0IGlzIHRoZSByb3V0ZXIgY2xpZW50LCBub3QgdGhlIGRldmlj ZSBhcyBhIHdob2xlIHdpdGggaXRzIGVudGlyZSBjb2xsZWN0aW9uIG9mIGNvbmZpZ3VyZWQgSVAg YWRkcmVzc2VzLiBPbmUgSVAgYWRkcmVzcyBvZiB0aGF0IGRldmljZSBtaWdodCBiZSBjb25maWd1 cmVkIGFzIGEgcm91dGVyIGNsaWVudCBvbiBvbmUgcm91dGVyLCBhbmQgYSBkaWZmZXJlbnQgSVAg YWRkcmVzcyBvZiB0aGF0IGRldmljZSBjb3VsZCBiZSBjb25maWd1cmVkIGFzIGEgcm91dGVyIGNs aWVudCBvbiBhbm90aGVyIHJvdXRlci4gVGhlIElQIGFkZHJlc3NlcyB3b3VsZCBzZWVtIHRvIEFP RFZ2MiB0byBiZSBvbiBkaWZmZXJlbnQgZGV2aWNlcy4NCg0KDQoxNC4gZGF0YSBlbGVtZW50cw0K DQpUaG9tYXM6IFRoZSBiZWxvdyBpcyBhIGxpdHRsZSBiaXQgb2YgYSBtZXRhLWNvbW1lbnQsIEkg YW0gbm90IHF1aXRlIHN1cmUgd2hhdCBJIHRoaW5rIGhlcmUuIFRoZSBkZWZpbml0aW9ucyBmb3Ig VGFyZ2V0IE5vZGUgYW5kIHN1Y2ggd2VyZSBjb25mdXNpbmcgYmVmb3JlLiBUaGV5IHN0aWxsIGFy ZSwgc29tZXdoYXQuDQpJIHRoaW5rIHRoYXQgaXQgbWF5IGJlIGJlY2F1c2UgdGhlIGRlZmluaXRp b25zIG5vdyB1c2VkIGFyZSBzaW1wbHkgY29weS1wYXN0ZWQgb3V0IGZyb20gdGhlIHRhYmxlcyBp biB0aGUgcHJldmlvdXMgdmVyc2lvbiwgZm9yIGV4YW1wbGU6DQogICDigJxBbiBBT0RWdjIgRGF0 YSBFbGVtZW50IGNvbnRhaW5pbmcgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIElQIHBh Y2tldCB0cmlnZ2VyaW5nIHJvdXRlIGRpc2NvdmVyeS7igJ0NCk9LLCBJIGNhbiB0cmFjZSBiYWNr IGFuZCBzZWUgdGhhdCBhIERhdGEgRWxlbWVudCBpcyBzb21ldGhpbmcgdGhhdCBleGlzdHMgaW5z aWRlIGEgcHJvdG9jb2wgbWVzc2FnZS4gVG8gbWUsIGhvd2V2ZXIsIHRoYXTigJlzIG5vdCByZWFs bHkgZ2VuZXJhbCB0ZXJtaW5vbG9neSBhcyBzdWNoLCBidXQgcGFydCBvZiB0aGUgc3BlY2lmaWNh dGlvbiBvZiBhIHBhY2tldCBmb3JtYXQgLSBvciByYXRoZXIsIGl0IGlzIHRoZSBub3RhdGlvbiB0 aGF0IHlvdSB1c2Ugd2hlbiBkZXNjcmliaW5nIGFuIGFsZ29yaXRobS4gQnkgdGhlIHdheSwgd2h5 IGFyZSBzb21lIG5vdGF0aW9ucyBpbiBDYW1lbENhc2Ugd2hlcmVhcyBvdGhlcnMgaGF2ZSBhIHNw YWNlIGluIHRoZW0sIGUuZy4g4oCcVGFyZ2V0IE5vZGXigJ0gYW5kIOKAnFRhcmdNZXRyaWPigJ0s IGJvdGggb2Ygd2hpY2ggYXJlIERhdGEgRWxlbWVudHM/IFdvdWxkIGJlIGdvb2Qgd2l0aCBhIGNv bnNpc3RlbnQgYXBwcm9hY2ggaGVyZS4NCkkgKnRoaW5rKiB0aGF0IGl0IHdvdWxkIGJlIGJldHRl ciB0byB0YWtlIGFsbCB0aG9zZSDigJxEYXRhIEVsZW1lbnTigJ0gYml0cyBhbmQgbW92ZSB0byBh IHNlcGFyYXRlIHNlY3Rpb24gKG9yIHN1YnNlY3Rpb24pIHRvIHRoZSB0ZXJtaW5vbG9neSwgYW5k IHRoZW4ga2VlcCBhbGwgdGhlIOKAnG90aGVyIHN0dWZm4oCdIChOZWlnaGJvciwg4oCmKSBpbiBp dHMgb3duIHNlY3Rpb24uDQoNCkFPRFZ2MjogWW91ciBjb21tZW50IGZyb20gZHJhZnQgMTEgd2hl cmUgd2UgYWxyZWFkeSBoYWQgZGF0YSBlbGVtZW50cyBpbiBhIHNlcGFyYXRlIHRhYmxlLCBzYXlz Og0KIkFsc28gc3VnZ2VzdCBhYm9saXNoaW5nIHRoaXMgdGFibGUgYW5kIGZvbGRpbmcgdGhlIGRl ZmluaXRpb25zIGluIHdpdGggdGhlIG90aGVyIGRlZmluaXRpb25zIGluIHRoZSB0ZXJtaW5vbG9n eSBzZWN0aW9uLiINCldlIGhhdmUgdXBkYXRlZCB0byBub3QgcmVmZXIgc28gaGVhdmlseSB0byB0 aGUgdGVybSBEYXRhIEVsZW1lbnQuIEFsbCB0aGUgdGVybXMgYXJlIGRlc2NyaWJlZCBpbiB0aGUg VGVybWlub2xvZ3kgc2VjdGlvbi4gVGhvc2UgaW4gQ2FtZWxDYXNlIGFyZSB1c2VkIGFzIG1lc3Nh Z2UgZmllbGRzLg0KDQoNCjE1LiBSb3V0ZSDigJx0byBhIHNwZWNpZmljIGFkZHJlc3PigJ0NClRo b21hczoNCkkgbWFkZSBhIGNvbW1lbnQ6IFNlY29uZCwgc2hvdWxkIOKAnHZhbGlkIHJvdXRl4oCd IG5vdCBiZSBxdWFsaWZpZWQgYnkg4oCcdG8gYSBzcGVjaWZpYyBhZGRyZXNz4oCdP+KAnQ0KV2hp Y2ggd2FzIG5vdCBhZGRyZXNzZWQuDQoNCkFPRFZ2MjogRXZlcnkgcm91dGUgaXMgdG8gYSBzcGVj aWZpYyBhZGRyZXNzLi4udGhlIGFkZHJlc3MgaXMgc3BlY2lmaWVkIGJ5IFJvdXRlLkFkZHJlc3Mg YW5kIFJvdXRlLlByZWZpeExlbmd0aC4NCkRvIHlvdSBtZWFuIHRoYXQgcm91dGVzIGFyZSB0byB0 aGUgYWRkcmVzcyBUYXJnQWRkciBvciBPcmlnQWRkciBhbmQgdGhlcmVmb3JlIHRvIGEgc3BlY2lm aWMgaG9zdCBhZGRyZXNzIHJhdGhlciB0aGFuIHRvIGEgbmV0d29yayBwcmVmaXg/IFRoaXMgaXMg bm90IHRoZSBjYXNlLiBQcmVmaXggTGVuZ3RoIGlzIGluY2x1ZGVkIGluIEFPRFZ2MiBtZXNzYWdl cyBzbyB0aGF0IHRoZSByb3V0ZSBsZWFybmVkIGZyb20gdGhlIG1lc3NhZ2UgcmVwcmVzZW50cyB0 aGUgcHJlZml4IHdoaWNoIE9yaWdBZGRyIG9yIFRhcmdBZGRyIHJlc2lkZXMgb24gKGlmIHRoZSBy b3V0ZXIgY2xpZW50IGVudHJ5IGNvcnJlc3BvbmRpbmcgdG8gT3JpZ0FkZHIgYXQgUlJFUV9HZW4g b3IgVGFyZ0FkZHIgYXQgUlJFUF9HZW4gaXMgY29uZmlndXJlZCB3aXRoIGEgcHJlZml4IGxlbmd0 aCkuIGUuZy4gT3JpZ0FkZHIgaXMgMTAuMC4wLjEgYnV0IHRoZSBjb3JyZXNwb25kaW5nIHJvdXRl ciBjbGllbnQgZW50cnkgYXQgUlJFUV9HZW4gY291bGQgYmUgMTAuMC4wLjAvODxodHRwOi8vMTAu MC4wLjAvOD4uIFNvIHdoZW4gY29uc3RydWN0aW5nIHRoZSBSUkVRIHlvdSBpbmNsdWRlIGEgcHJl Zml4IGxlbmd0aCBvZiA4LCBhbmQgd2hlbiByZWNlaXZpbmcgdGhlIFJSRVEgYW5kIGxlYXJuaW5n IHRoZSByb3V0ZSB0byBPcmlnQWRkciwgeW91IGNhbiBpbnN0YWxsIGEgcm91dGUgdG8gMTAuMC4w LjAvODxodHRwOi8vMTAuMC4wLjAvOD4uICBUZXh0IGhhcyBiZWVuIHVwZGF0ZWQgdG8gbWFrZSB0 aGlzIG1vcmUgb2J2aW91cy4NCg0KMTYuIHVucmVhY2hhYmxlIGFkZHJlc3MNCg0KVGhvbWFzOiBJ IGFsc28gbWFkZSBhIGNvbW1lbnQgb24gIlVucmVhY2hhYmxlIEFkZHJlc3PigJ0gLSBJIGFtIGds YWQgSSBkaWQsIGJlY2F1c2UgSSBhcHBhcmVudGx5IGhhZCBhIGRpZmZlcmVudCB1bmRlcnN0YW5k aW5nIHRoYW4gd2hhdCB3YXMgaW50ZW5kZWQuIEkgbm93IHNlZSB0aGF0IGFuIFVucmVhY2hhYmxl IEFkZHJlc3MgYnkgZGVmaW5pdGlvbiBpcyBhbiBhZGRyZXNzIGxpc3RlZCBpbiBhIFJFUlIgbWVz c2FnZSwgYW5kIG5vdCB0aGUgc2FtZSBhcyBhbiBhZGRyZXNzIHRvIHdoaWNoIG5vIHJvdXRlIGhh cyB5ZXQgIGJlZW4gZGlzY292ZXJlZD8gSWYgeWVzLCB0aGVuIHBsZWFzZSB1c2UgYSBkaWZmZXJl bnQgdGVybSwgc3VjaCBhcyBGb3JtZXJseVJlYWNoYWJsZUFkZHJlc3PigJ0gb3Igc29tZXRoaW5n IG9mIHRoZSBzb3J0Pw0KDQpBT0RWdjI6ICJGb3JtZXJseSByZWFjaGFibGUiIGlzIGluYWNjdXJh dGUuLi4gd2Ugc2VuZCBhIFJFUlIgaWYgYW5vdGhlciByb3V0ZXIgZm9yd2FyZHMgYSBwYWNrZXQg dmlhIHVzLCBhbmQgd2UgZG9udCBoYXZlIGEgcm91dGUsIG5vdCBqdXN0IHdoZW4gd2UgbG9zZSBh IHJvdXRlLiBXZSBtaWdodCBuZXZlciBoYXZlIGhhZCBhIHJvdXRlLCBvciBtaWdodCBuZXZlciBo YXZlIGhhZCBhIHZhbGlkIHJvdXRlLCBzbyB0aGUgYWRkcmVzcyBtYXkgbm90IGhhdmUgYmVlbiAi Zm9ybWVybHkgcmVhY2hhYmxlIi4gQWxzbywgSSB0aGluayAiRm9ybWVybHlSZWFjaGFibGVBZGRy ZXNzIiBpcyBhIHJlYWxseSB1Z2x5IHRlcm0uIFVucmVhY2hhYmxlIG1lYW5zICJ3ZSBkb27igJl0 IGhhdmUgYSByb3V0ZSBhbmQgd2UgYXJlbuKAmXQgZ29pbmcgdG8gcmVxdWVzdCBvbmUiIG9yICJ3 ZSBsb3N0IHRoaXMgcm91dGUiIChkZXBlbmRpbmcgb24gd2h5IHRoZSBSRVJSIGlzIGJlaW5nIHNl bnQpLiBJdCBkb2VzbuKAmXQgbWVhbiAid2UgZGlkbuKAmXQgcmVxdWVzdCBvbmUgeWV0IiwgYW5k IGl0IHdvdWxkIGJlIHdyb25nIHRvIGNsYXNzIGFuIGFkZHJlc3MgYXMgdW5yZWFjaGFibGUgYmVj YXVzZSB3ZSBoYWRu4oCZdCByZXF1ZXN0ZWQgYSByb3V0ZSBmb3IgaXQgeWV0LCB0aGF0IGlzLCBh c3N1bWluZyBpdOKAmXMgY29uZmlndXJlZCBhcyBhIHJvdXRlciBjbGllbnQuDQoNCklmIGEgYmV0 dGVyIHRlcm0gaXMgc3VnZ2VzdGVkIHdlIGNvdWxkIGNvbnNpZGVyIGNoYW5naW5nIGJ1dCBhdCB0 aGUgbW9tZW50IHdlIGhhdmUga2VwdCDigJxVbnJlYWNoYWJsZSBBZGRyZXNz4oCdLg0KDQoNCjE3 LiBBcHBsaWNhYmlsaXR5IC0gbXVsdGlwbGUgaW50ZXJmYWNlcyBzYW1lIGFkZHJlc3MsIDY2MjEg YWdhaW4NCg0KVGhvbWFzOiBBcHBsaWNhYmlsaXR5IHN0YXRlbWVudDogRmlyc3QsIEkgd291bGQg bGlrZSB0byByZWNvZ25pemUgdGhlIGVmZm9ydHMgbWFkZSB0byBpbXByb3ZlIHRoaXMgc2luY2Ug bGFzdCByZXZpZXcuIFRoYW5rcw0KU2Vjb25kLCB0aGUgZG9jdW1lbnQgc3RhdGVzOiAiQU9EVnYy IHN1cHBvcnRzIHJvdXRlcnMgd2l0aCBtdWx0aXBsZSBpbnRlcmZhY2VzLCBhcyBsb25nIGFzIGVh Y2ggaW50ZXJmYWNlIGNvbmZpZ3VyZWQgZm9yIEFPRFZ2MiBoYXMgYSB1bmljYXN0IElQIGFkZHJl c3MuICBBIHJvdXRlciBtYXkgdXNlIHRoZSBzYW1lIElQIGFkZHJlc3Mgb24gbXVsdGlwbGUgaW50 ZXJmYWNlcy4gIEFkZHJlc3MgYXNzaWdubWVudCBwcm9jZWR1cmVzIGFyZSBvdXQgb2Ygc2NvcGUg Zm9yIEFPRFZ2Mi7igJ0NCklzIHRoYXQgdHJ1ZT8gR3JhbnRlZCwgSSBoYXZlIG5vdCB3b3JrZWQg dGhpcyB0aHJvdWdoIGluIGRldGFpbCwgYnV0IEkgY2FuIHByZXNlbnQgYSBjb3VudGVyLWV4YW1w bGU6IHRoZSB1c2Ugb2YgUkZDNjYyMSBtZWFucyB0aGF0IHRoZXJlIGNlcnRhaW5seSBhcmUgc29t ZSBjb25zdHJhaW50cyB0aGF0IG11c3QgYmUgcmVzcGVjdGVkIGxlYXN0IHZhcmlvdXMgZmxvb2Rp bmcgb3B0aW1pemF0aW9ucyBtYXkgbm90IHdvcmsuDQpTZWNvbmRseSwgaWYgdGhlIG11bHRpcGxl LWludGVyZmFjZXMtd2l0aC1zYW1lLWFkZHJlc3MgYXJlIG9uIHRoZSBzYW1lIEwyLCBhbmQgdGhp cyBpcyB3aGF0IEkgaGF2ZSBub3Qgd29ya2VkIHRocm91Z2gsIGFyZSB0aGVyZSBhbnkgc2l0dWF0 aW9ucyB0aGF0IHdpbGwgbm90IHdvcms/DQpUaGUgaW1tZWRpYXRlbHkgcHJldmlvdXMgdmVyc2lv biBvZiB0aGlzIHNwZWNpZmljYXRpb24gcmVhZDoNCiJBT0RWdjIgc3VwcG9ydHMgcm91dGVycyB3 aXRoIG11bHRpcGxlIGludGVyZmFjZXMsIGFzIGxvbmcgYXMgZWFjaCBpbnRlcmZhY2UgY29uZmln dXJlZCBmb3IgQU9EVnYyIGhhcyBpdHMgb3duIHVuaWNhc3Qgcm91dGFibGUgSVAgYWRkcmVzcyIN ClNvIHdoYXQgY2hhbmdlZCB0aGF0IG1lYW5zIHRoYXQgZWFjaCBpbnRlcmZhY2Ugbm8gbG9uZ2Vy IG5lZWRzIGl0cyAqb3duKiB1bmljYXN0IGFkZHJlc3M/DQoNCkFPRFZ2MjogV2VsbCwgYmFzZWQg b24gcHJldmlvdXMgcXVlc3Rpb25zIG9uIHRoaXMsIHdlIHRhbGtlZCBpdCB0aHJvdWdoIGFuZCBk ZWNpZGVkIHRoZXJlIHNob3VsZG7igJl0IGJlIGFuIGlzc3VlIGlmIGRpZmZlcmVudCBpbnRlcmZh Y2VzIG9mIGEgcm91dGVyIHVzZWQgdGhlIHNhbWUgSVAgYWRkcmVzcy4gTm90ZSB0aGF0IHdlIGNo YW5nZWQgQU9EVnYyIHNvIHRoYXQgdGhlcmUgaXMgb25lIHNlcXVlbmNlIG51bWJlciBwZXIgcm91 dGVyLiBObyBsb25nZXIgY2FuIGEgcm91dGVyIHVzZSBkaWZmZXJlbnQgc2VxdWVuY2UgbnVtYmVy cyBvbiBkaWZmZXJlbnQgaW50ZXJmYWNlcy4gSWYgYW4gUlJFUSB3ZW50IG91dCBvZiB0d28gaW50 ZXJmYWNlcyB1c2luZyB0aGUgc2FtZSBhZGRyZXNzLCB3ZSB3b3JrZWQgaXQgdGhyb3VnaCBhbmQg ZGVjaWRlZCB0aGUgcmVxdWVzdCB3b3VsZCBiZSBwcm9jZXNzZWQgY29ycmVjdGx5Lg0KQWxzbywg dGV4dCByZWZlcnJpbmcgdG8gUkZDIDY2MjEgaGFzIGJlZW4gcmVtb3ZlZC4NCg0KMTguIEFwcGxp Y2FiaWxpdHkgYW5kIGFwcGVuZGl4IC0gbXVsdGlob21pbmcNCg0KVGhvbWFzOiBJIHBvaW50ZWQg b3V0IHRvIHRoZSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudDoNCkkgdGhpbmsgdGhhdCBhcHBlbmRp eCBCIG5lZWRzIHRvIGJlIHJlbW92ZWQuIEVzc2VudGlhbGx5LCBpdCBtYWtlcyBjbGFpbXMgdGhh dCBpdCBpcyBwb3NzaWJsZSB0byBkbyBtdWx0aS1ob21pbmcg4oCUIGJ1dCBuZWl0aGVyIHNwZWNp ZmllcyBob3cgaXQgaXMgZG9uZSwgbm9yIGdpdmVzIHBvaW50ZXJzIHRvIGRvY3VtZW50cyB0aGF0 IGp1c3RpZnkgdGhlIGNsYWltLg0KQU9EVnYyIGRvZXMgbm90IHN1cHBvcnQgbXVsdGktaG9taW5n IOKAlCB0aGF04oCZcyBjbGVhciwgYW5kIGl0IGlzIGZpbmUgdGhhdCBpdCBpcyBjYWxsZWQgb3V0 IGhlcmUuIFRoYW5rIHlvdSBmb3IgdGhhdC4NCk5vdywgd2l0aCB0aGF0IGJlaW5nIHNhaWQsIEkg YW0gdG9ybiBiZXR3ZWVuIGJlaW5nIHNhdGlzZmllZCB0aGF0IGl0IGlzIGNhbGxlZCBvdXQgb24g b25lIGhhbmQsIGFuZCB3YW50aW5nIHRvIGhhdmUg4oCcbXVsdGkgaG9taW5n4oCdIG9uIHRoZSBv dGhlciBoYW5kLiBSRkM3MTgxIHN1cHBvcnRzIG11bHRpLWhvbWluZywgRldJVy4NCkkgYmVsaWV2 ZSB0aGF0IHRoaXMgYWxzbyB3b3VsZCBtZXJpdCBzb21lIGV4cGxpY2l0IGRpc2N1c3Npb24gYnkg dGhlIFdHLCBpbiBvcmRlciB0byB1bmRlcnN0YW5kIGlmIHRoaXMgZGVzaWduIGRlY2lzaW9uIGlz IGFjY2VwdGFibGU/DQpJIHNlZSB0aGF0IEFwcGVuZGl4IEIgc3RpbGwgaXMgaW4gdGhlIGRvY3Vt ZW50LCBhbmQgSSBkbyBub3QgcmVjYWxsIGhhdmluZyBzZWVuIHRoaXMgZGlzY3Vzc2VkIG9uIHRo ZSBtYWlsaW5nIGxpc3QuIFNpbXBseSByZW1vdmluZyB0aGUgcmVmZXJlbmNlIGZyb20gdGhlIEFw cGxpY2FiaWxpdHkgU3RhdGVtZW50IHRvIEFwcGVuZGl4IEIgZG9lcyBub3QgYWRkcmVzcyB0aGUg aXNzdWUgdGhhdCBJIHJhaXNlZCBpbiBteSBwcmV2aW91cyByZXZpZXcuDQoNCkFPRFZ2MjogQXBw ZW5kaXggaGFzIGJlZW4gcmVtb3ZlZCBhbmQgbWF5IGFwcGVhciBpbiBhIGZ1dHVyZSBpbmZvcm1h dGlvbmFsIGRvY3VtZW50Lg0KDQoxOS4gaW50ZXJmYWNlcyBsaXN0IC0gdXNlIG9mIOKAnFNIT1VM ROKAnQ0KDQpUaG9tYXM6IFRvIDQuMSwgSSBtYWRlIHRoZSBmb2xsb3dpbmcgY29tbWVudDoNCiJJ cyB0aGlzIGEgc2hvdWxkLCBvciBhIFNIT1VMRD8gSWYgdGhlIGxhdHRlciwgc2hvdWxkIGl0IGJl IGEgTVVTVD8NCkluIGdlbmVyYWwsIHRoZXJlIGFyZSBhIGxvdCBvZiBzdWNoIOKAnG1heWJlIG5v cm1hdGl2ZSBsYW5ndWFnZeKAnSB0aHJvdWdoIHRoZSBkb2N1bWVudCwgYW5kIEkgd291bGQgbXVj aCBsaWtlIHRvIHNlZSBhbiBlZGl0b3JpYWwgcGFzcyDigJQgZXNzZW50aWFsbHkgYWxsIG1heS9z aG91bGQvIG11c3QgYW5kIGZyaWVuZHMgY2FyZWZ1bGx5IGV2YWx1YXRlZCBhcyBpZiB0aGV5IHNo b3VsZCBiZWNvbWUgMjExOS10ZXJtcywgYW5kIC4uLiBtb3JlIGltcG9ydGFudGx5IChpdCBoYXMg YmVlbiBjYWxsZWQgb3V0IGJlZm9yZSwgZndpdykgcXVpdGUgYSBiaXQgb2Ygc2hvdWxkL1NIT1VM RCB3aGljaCBvdWdodCB0byBiZSB0cmFuc2Zvcm1lZCBpbnRvIE1VU1QuDQpHZW5lcmFsbHksIGFp bWluZyBmb3IgYSB2ZXJ5IGEgbG93IG51bWJlciBvZiBTSE9VTEQgaXMgYSBnb29kIGRlc2lnbiBt ZXRyaWMgZm9yIGEgZG9jdW1lbnTigJ0NCkFzaWRlIGZyb20gdGhlIGdlbmVyYWwgY29tbWVudCBv biAyMTE5LWxhbmd1YWdlLCB3aHkgaXMgdGhpcyBhIFNIT1VMRD8NCg0KQU9EVnYyOiBXZSBjaGFu Z2VkIHRoaXMgaW5zdGFuY2UgdG8gYSBNVVNUIGFuZCB3aWxsIGJlIGNoZWNraW5nIGZvciDigJxt YXliZSBub3JtYXRpdmUgbGFuZ3VhZ2XigJ0uDQoNCg0KMjAuIFJvdXRlciBjbGllbnQgLSBMb2Nh bCBBdHRhY2hlZCBOZXR3b3JrIFNldA0KDQpUaG9tYXM6IFRvIDQuMiwgSSBtYWRlIHRoZSBmb2xs b3dpbmcgY29tbWVudDoNCkFzIGluZGljYXRlZCBlYXJsaWVyLCBJIGJlbGlldmUgdGhhdCB0aGUg dGVybSDigJxSb3V0ZXIgQ2xpZW504oCdIGlzIGlsbCBjaG9zZW4uIEkgYmVsaWV2ZSB0aGF0IGl0 IGlzIG1vcmUgYXBwcm9wcmlhdGVseSBhbiDigJxBdHRhY2hlZCBOZXR3b3JrIFNldOKAnSBzaW5j ZSDigJQgYXMgaW5kaWNhdGVkIHByZXZpb3VzbHkg4oCUIHRoZSB0ZXJtIOKAnFJvdXRlciBDbGll bnTigJ0gaXMgYW1iaWd1b3VzLiBJIGFtIHBsZWFzZWQgdG8gc2VlLCB0aG91Z2gsIHRoYXQgdGhp cyDigJxSb3V0ZXIgQ2xpZW50IExpc3TigJ0gaW4gcmVhbGl0eSBpcyBhbiDigJxBdHRhY2hlZCBO ZXR3b3JrIFNldOKAnSBhbmQgc28gdGhhdCBjaGFuZ2Ugc2hvdWxkIGJlIChyZWxhdGl2ZWx5KSBl YXN5Lg0KVGhlIGFib3ZlIGNvbW1lbnQgc3RpbGwgaXMgYXBwbGljYWJsZSB0byB0aGlzIHJldmlz aW9uLA0KDQpBT0RWdjI6IFNlZSA1LDksMTIsMTMuDQoNCg0KMjEuIFN1Ym5ldA0KVGhvbWFzOiBU byA0LjIsIEkgbWFkZSB0aGUgZm9sbG93aW5nIGNvbW1lbnQ6DQpBbHNvLCBJIHJlY29tbWVuZCB0 byBub3Qgc2F5IOKAnHN1Ym5ldOKAnSDigJQgaG93IGFib3V0IHJlcGhyYXNpbmcgdG8g4oCcSWYg YSBwcmVmaXggaXMgaW5jbHVkZWQgaW4gdGhlIGF0dGFjaGVkIG5ldHdvcmsgc2V0IG9mIGFuIEFP RFZ2MiByb3V0ZXIsIHRoZW4gdGhhdCBBT0RWdjIgcm91dGVyIE1VU1QgcHJvdmlkZSBjb25uZWN0 aXZpdHkgZm9yLCBpLmUuIGFuc3dlciB0byBSUkVRcyBhbmQgbWFpbnRhaW4gc2VxdWVuY2UgbnVt YmVycyBmb3IsIGFsbCBhZGRyZXNzZXMgZnJvbSB3aXRoaW4gdGhhdCBwcmVmaXgu4oCdDQpJIG5v dGUgdGhhdCB3aGlsZSB0aGUgdGVybSBoYXMgYmVlbiByZW1vdmVkIGZyb20gc2VjdGlvbiA0LCB0 aGVyZeKAmXJlIDQgbGluZ2VyaW5nIGluc3RhbmNlcyBvZiB0aGlzIHRlcm0gaW4gdGhlIGRvY3Vt ZW50LCB0aGF0IGNvdWxkIGVhc2lseSBiZSByZW1vdmVkLg0KDQpBT0RWdjI6IEFsbCBtZW50aW9u cyBvZiAic3VibmV0IiB3ZXJlIGluIHRoZSBFTkFSIHNlY3Rpb24uIFRoZXkgaGF2ZSBiZWVuIHVw ZGF0ZWQgdG8gc2F5IG5ldHdvcmssIG9yICJuZXR3b3JrcyBhdHRhY2hlZCB0byB0aGUgcm91dGVy cyINCg0KDQoyMi4gcmVsb2NhdGluZyByb3V0ZXIgY2xpZW50DQoNClRob21hczogSSBBbHNvIG1h ZGUgYSBjb21tZW50IGFib3V0IEFwcGVuZGl4IEIgaW4gbXkgcHJldmlvdXMgcmV2aWV3LCB3aGlj aCBpcyByZWZlcmVuY2VkIGhlcmUuIFRoYXQgY29tbWVudCBzdGlsbCBhcHBsaWVzLg0KDQpBT0RW djI6IE1vdmVkIGludG8gbWFpbiBkcmFmdC4NCg0KDQoyMy4gTmVpZ2hib3IgTW9uaXRvcmluZw0K DQpUaG9tYXM6IFRvIFNlY3Rpb24gNC4zLCBJIG5vdGljZWQ6DQpEb2VzIHNlY3Rpb24gNi4yIGRl c2NyaWJlIGhvdyB0byBtb25pdG9yIGFuIGVzdGFibGlzaGVkIGFkamFjZW5jeSBvbmx5LCBvciBo b3cgdG8gZGlzY292ZXIgbmVpZ2hib3VyaW5nIEFPRFZ2MiByb3V0ZXJzPyBMb29raW5nIGluIDYu MiwgSSBzZWUNCuKAnE5vdCBldmVyeSBwYWlyIG9mIG5laWdoYm9yaW5nIHJvdXRlcnMgd2lsbCBu ZWNlc3NhcmlseSBmb3JtIGFuIGFkamFjZW5jeSzigJ0g4oCUIHNvIGl0IGxpa2VseSBpc27igJl0 IDYuMiB0aGF0IHRlbGxzIG1lIGhvdyB0byBtYWludGFpbiB0aGlzIHRhYmxlPw0KSW4gc2hvcnQs IOKAnEEgbmVpZ2hib3VyIHRhYmxlIE1VU1QgYmUgbWFpbnRhaW5lZOKAnSDigJQgd2hlcmUgY2Fu IEkgZmluZCBpbmZvcm1hdGlvbiBvbiBob3cgdG8gZG8gdGhpcz8NClNlY3Rpb24gNi4yIHN0YXRl czoNCuKAnFRoZSBkZWZhdWx0IGFwcHJvYWNoIGZvciBtb25pdG9yaW5nIGJpZGlyZWN0aW9uYWwg Y29ubmVjdGl2aXR5IHRvIHRoZSBuZXh0IGhvcCB0b3dhcmQgT3JpZ0FkZHIgaXMgdG8gcmVxdWVz dCBhY2tub3dsZWRnZW1lbnQgb2YgUm91dGUgUmVwbHkgbWVzc2FnZXMu4oCdDQpUaGF0IGNlcnRh aW5seSB3aWxsIHRlbGwgbWUgaWYgYSBsaW5rIG92ZXIgd2hpY2ggYW4gUlJFUCBpcyBzZW50IGlz IGJpLWRpcmVjdGlvbmFsLCBidXQgd2lsbCBub3QgbWFpbnRhaW4gYSDigJxuZWlnaGJvciB0YWJs ZeKAnS4NClNvIGhvdyBpcyB0aGlzIGRvbmU/IE9yLCBpcyB0aGUg4oCcTmVpZ2hib3IgVGFibGXi gJ0gbm90IHN1cHBvc2VkIHRvIGNvbnRhaW4gdGhlIGNvbXBsZXRlIHNldCBvZiBuZWlnaGJvdXJz PyBXaGF0IGluZm9ybWF0aW9uIOKAnC4uLk1VU1QgYmUgbWFpbnRhaW5lZOKAnSB0aGVuLCBpbiB0 aGlzIHRhYmxlPw0KVGhpcyBpcyB2ZXJ5IHVuY2xlYXIsIEkgd291bGQgbm90IGtub3cgaG93IHRv IGltcGxlbWVudCBhIG1lY2hhbmlzbSB0aGF0IHBvcHVsYXRlcyB0aGlzIOKAnE5laWdoYm9yIFRh Ymxl4oCdIHdpdGggdGhlIG5lZWRlZCBpbmZvcm1hdGlvbiBoZXJlLg0KSSBzZWUgbm8gKHJlbGV2 YW50KSBjaGFuZ2VzIHRvIDYuMiBub3IgdG8gNC4zIHNvIEkgYXNzdW1lIHRoYXQgdGhpcyBjb21t ZW50IGhhcyBub3QgYmVlbiBhZGRyZXNzZWQNCg0KQU9EVnYyOiBBIG5ldyBzZWN0aW9uIHdhcyBh ZGRlZCB0byBzaG93IGhvdyB0byB1cGRhdGUgdGhlIG5laWdoYm91ciB0YWJsZS4gVGhlcmUgaGF2 ZSBhbHNvIGJlZW4gdXBkYXRlcyB0byB0aGlzIGVudGlyZSBzZWN0aW9uIHNpbmNlIHZlcnNpb24g MTIuDQoNCjI0LiAgICAgcHNldWRvLWNvZGUNCg0KVGhvbWFzOg0KSSBhbSB0aHJvd2luZyB0aGlz IGluIGhlcmUsIGFzIEkgYW0gc3VyZSB0aGF0IEkgY29tbWVudGVkIG9uIHRoYXQgaW4gdGhlIHBy ZXZpb3VzIHJldmlldywgYnV0IEkgZG8gbm90IHNlZSB0aGF0IGFkZHJlc3NlZDogaXMgQXBwZW5k aXggQyBub3JtYXRpdmUsIG9yIG5vdD8gSXQgcmVwcmVzZW50cyDigJwgYSBzZWNvbmQgc3BlY2lm aWNhdGlvbiBvZiB0aGUgcHJvdG9jb2wsIGluIGEgZGlmZmVyZW50IGxhbmd1YWdl4oCdIGZyb20g dGhlIG1haW4gcGFydCBvZiB0aGUgc3BlY2lmaWNhdGlvbi4gSSBoYXZlIG5vdCB3YWxrZWQgdGhy b3VnaCBhbmQgbWFkZSAyMDAlIHN1cmUgdGhhdCBib3RoIGFyZSBwZXJmZWN0bHkgYWxpZ25lZCBh bmQgdGhhdCB0aGVyZSBhcmUgbm8gYW1iaWd1aXRpZXMsIGJ1dCBoYXZpbmcgdHdvIGRpZmZlcmVu dCBzcGVjaWZpY2F0aW9ucyBvZiBhIHByb3RvY29sIGlzIGEgcmVjaXBlIGZvciBkaXNhc3Rlci4g IFBsZWFzZSBlaXRoZXIgbWFrZSAyMDAwJSBzdXJlIHRoYXQgdGhleSBhcmUgc3BlY2lmeWluZyB0 aGUgc2FtZSB0aGluZyB3aXRob3V0IGFtYmlndWl0aWVzLCBvciByZW1vdmUgb25lLg0KDQpBT0RW djI6IFJlbW92ZWQgLSBtYXliZSB0byBpbmNsdWRlIGluIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1l bnQgaW4gZnV0dXJlLg0KDQoNCjI1LiBzZXFudW0gYXMgMTYgYml0IHVuc2lnbmVkIGludGVnZXIN Cg0KVGhvbWFzOiBUbyBzZWN0aW9uIDQuNCwgSSB3cm90ZToNCiJ3b3VsZCBsaWtlIHRvIG5pdC1w aWNrIHRoYXQ6IHRoZSByb3V0ZXIgY2FuIG1haW50YWluIHRoaXMgc2VxdWVuY2UgbnVtYmVyIGlu IHdoYXRldmVyIGZvcm1hdCBpdCBwbGVhc2VzIOKAlCBidXQsIHdoZW4gaXQgaW5jbHVkZXMgaXQg aW4gY29udHJvbCBtZXNzYWdlcywgaXQgbXVzdCBiZSByZXByZXNlbnRhYmxlIGluIGEgc3BlY2lm aWVkIGZvcm1hdCwgcmVzcGVjdGluZyBjZXJ0YWluIHJ1bGVzLuKAnQ0KSSBzZWUgdGhhdCB0aGVy ZSB3ZXJlIG5vIGNoYW5nZXMgZm9sbG93aW5nIHRoaXMgY29tbWVudC4NCg0KQU9EVnYyOiBXaHkg c3RvcmUgaXQgYXMgYW55dGhpbmcgb3RoZXIgdGhhbiB3aGF0IGl0IG5lZWRzIHRvIGJlIHdoZW4g aXQgZ29lcyBpbnRvIGEgbWVzc2FnZT8gSG93ZXZlciwgd2Ugbm93IHN0YXRlICJNVVNUIHJlcG9y dCBpdHMgb3duIHNlcXVlbmNlIG51bWJlciBhcyBhIDE2IGJpdC4uLi53aGVuZXZlciBpdCBjcmVh dGVzIGEgUlJFUSBvciBSUkVQIG1lc3NhZ2UiLg0KDQoNCjI2LiBtdWx0aXBsZSBzZXFudW1zPw0K DQpUaG9tYXM6DQpUbyBzZWN0aW9uIDQuNCBJIGFza2VkIGZvciBjbGFyaWZpY2F0aW9uIGFzIHRv IGlmIHNlcXVlbmNlIG51bWJlcnMgd2VyZSBwZXIgaW50ZXJmYWNlIG9yIHBlciByb3V0ZXIsIGFz IHRoZSBzcGVjaWZpY2F0aW9uIHdhcyB1bmNsZWFyIG9uIHRoYXQuIFRoZSB3b3JkcyBoYXMgY2hh bmdlZCwgYnV0IGl0IHN0aWxsIGlzIHVuY2xlYXI6IGhvdyBtYW55IHNlcXVlbmNlIG51bWJlcnMg ZG9lcyBhIHJvdXRlciBtYWludGFpbj8gT25lPyBPbmUgcGVyIGludGVyZmFjZT8NCg0KQU9EVnYy OiBXZSB0cmllZCB0byBzdGFydCBkaXNjdXNzaW9uIG9uIHRoYXQgcG9pbnQsIGFuZCBpbiB0aGUg bWVhbnRpbWUgd2UgcmV2ZXJ0ZWQgdG8gaGF2aW5nIDEgc2VxbnVtIHBlciByb3V0ZXIuIFdlIHRo aW5rIHRoZSB0ZXh0IGlzIGNsZWFyLi4uIHdlIHJlZmVyIHRvICJ0aGUgcm91dGVycyBzZXF1ZW5j ZSBudW1iZXIiIG9yICJpdHMgc2VxdWVuY2UgbnVtYmVyIiAtIG5ldmVyIGhpbnRpbmcgdGhhdCB0 aGVyZSBjb3VsZCBiZSBtdWx0aXBsZSBzZXFudW1zIHBlciByb3V0ZXIgKGFzIGZhciBhcyBJJ20g YXdhcmUpLg0KDQoNCjI3LiBzZXRzL2xpc3RzL3RhYmxlcw0KDQpUaG9tYXM6DQpJbiBteSBwcmV2 aW91cyByZXZpZXcsIEkgZXhwcmVzc2VkIHRoYXQgaXQgd291bGQgYmUgcHJlZmVyZW50aWFsIHRv IHVzZSDigJxhIG5vdGF0aW9uIG9mIFNldHPigJ0gcmF0aGVyIHRoYW4gdGFibGVzLiBJIHNlZSB0 aGF0IHRoaXMgaGFzIG5vdCBjaGFuZ2VkLg0KDQpBT0RWdjI6IFlvdSBwcmVmZXJyZWQgc2V0cyBy YXRoZXIgdGhhbiBsaXN0cyBpbiB5b3VyIHByZXZpb3VzIHJldmlldy4uLmFuZCBleHBsYWluZWQg b3VyIHJlYXNvbmluZyBmb3IgdGhpcyBpbiByZXNwb25zZXMgdG8gdGhlIE1BTkVUIGxpc3QsIGFu ZCB3ZSBkaWQgbm90IHJlY2VpdmUgZnVydGhlciBjb21tZW50cy4NCg0KDQoyOC4gdXNlIG9mIOKA nG5vZGXigJ0NCg0KVGhvbWFzOg0KSSBtYWRlIGEgY29tbWVudCBvbiBub2RlIGFuZCBhZGRyZXNz LCBsZXQgbWUgcGljayB0aGlzIHVwIGFnYWluLiBUaGUgZm9sbG93aW5nOg0KUnRlTXNnLk9yaWdB ZGRyDQpBbiBJUCBhZGRyZXNzIG9mIHRoZSBub2RlIHdoaWNoIHJlcXVpcmVzIHRoZSByb3V0ZSwg aS5lLiwgdGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBJUCBwYWNrZXQgdHJpZ2dlcmluZyB0aGUg cm91dGUgcmVxdWVzdC4NCndvdWxkIGJlIG1vcmUgY29tcGFjdCBhbmQgY2xlYXIgaWYgZ2V0dGlu ZyByaWQgb2YgdGhlIHRlcm0g4oCcbm9kZeKAnSBhbmQgc2FpZDoNClJ0ZU1zZy5PcmlnQWRkcg0K VGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBJUCBwYWNrZXQgdHJpZ2dlcmluZyB0aGUgcm91dGUg cmVxdWVzdC4NCg0KQU9EVnYyOiBDaGFuZ2UgbWFkZSBhcyBzdWdnZXN0ZWQuDQoNCjI5LiByb3V0 ZSB0YWJsZS9yaWIvcm91dGluZyBzZXQNCg0KVGhvbWFzOiBUbyBzZWN0aW9uIDQuNiwgYW5kIEkg KGFuZCBvdGhlcnMpIGhhdmUgY29tbWVudGVkIG9uIHRoaXMgYmVmb3JlOg0KQWxsIEFPRFZ2MiBy b3V0ZXJzIE1VU1QgbWFpbnRhaW4gYSByb3V0ZSB0YWJsZS4gIFRoZSByb3V0ZSB0YWJsZSBlbnRy eSBpcyBhIGNvbmNlcHR1YWwgZGF0YSBzdHJ1Y3R1cmUuICBJbXBsZW1lbnRhdGlvbnMgTUFZIHVz ZSBhbnkgaW50ZXJuYWwgcmVwcmVzZW50YXRpb24gYnV0IE1VU1QgY29udGFpbiB0aGUgZm9sbG93 aW5nIGluZm9ybWF0aW9uOg0KSW4gb3JkZXIgdG8gYXZvaWQgY29uZnVzaW9uLCByZW5hbWUgdGhp cyB0byDigJxSb3V0aW5nIEluZm9ybWF0aW9uIEJhc2XigJ0gb3Ig4oCcUm91dGluZyBTZXTigJ0g 4oCUIGEgUm91dGluZyBUYWJsZSBpcyBhbiBvcGVyYXRpbmcgc3lzdGVtIGNvbnN0cnVjdCwgd2hl cmVvbiBvcGVyYXRpb25zIGRpcmVjdGx5IGluZmx1ZW5jZSBwYWNrZXQgZm9yd2FyZGluZy4gV2hh dCB5b3UgYXJlIGRlZmluaW5nIGhlcmUgaXMgYSBSSUIvYW4gUlMuDQoNCkFPRFZ2MjogRG9uZSBp biB2ZXJzaW9uIDEzLg0KDQoNCjMwLiBycmVxIGZvciBwcmVmaXgsIHVzZSBvZiDigJxpcCBhZGRy ZXNz4oCdIGFuZCDigJxhZGRyZXNzIg0KDQpUaG9tYXM6DQpUaGUgY29uZnVzaW9uIHRoYXQgSSBw b2ludGVkIG91dCBpbiBteSBwcmV2aW91cyByZXZpZXcgb24g4oCcSVAgYWRkcmVzc+KAnSBhbmQg 4oCcQWRkcmVzc+KAnSBiZWluZyB1c2VkIGEgYml0IGhhcGhhemFyZGx5IHBlcnNpc3RzLCBmd2l3 LiBJdCBtYWtlcyBtZSB0aGluaywgY2FuIGEgcm91dGVyIHNlbmQgYW4gUlJFUSBmb3IgYSBwcmVm aXg/DQoNCkFPRFZ2MjogU2VlIGFsc28gIzE1LiBSUkVRX0dlbiBjYW4gaW5jbHVkZSB0aGUgcHJl Zml4IGFzc29jaWF0ZWQgd2l0aCBPcmlnQWRkciBieSBhZGRpbmcgYSBwcmVmaXggbGVuZ3RoIHRv IHRoZSBtZXNzYWdlLCB0aGUgcHJlZml4IGxlbmd0aCBhc3NvY2lhdGVkIHdpdGggdGhlIHJvdXRl ciBjbGllbnQgZW50cnkgY29ycmVzcG9uZGluZyB0byBPcmlnQWRkci4gU28gYWxsIHJvdXRlcnMg d2hpY2ggcmVjZWl2ZSBpdCBjYW4gbGVhcm4gYSByb3V0ZSB0byB0aGUgcHJlZml4IG9uIHdoaWNo IE9yaWdBZGRyIHJlc2lkZXMuIEJ1dCBmb3IgVGFyZ0FkZHIuLi4gdGhlIFJSRVEgb25seSBoYXMg b25lIHRhcmdldCBJUCBhZGRyZXNzIC0gdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3Mgb2YgdGhl IHBhY2tldCByZXF1aXJpbmcgdGhlIHJvdXRlLi4uIHNvIHdoYXQgcHJlZml4IGxlbmd0aCB3b3Vs ZCBpdCB1c2U/IFRoZSBSUkVRIHJlcXVlc3RzIGEgcm91dGUgdG8gYSBzaW5nbGUgSVAgYWRkcmVz cy4gSG93ZXZlciwgd2hlbiB0aGUgUlJFUCBpcyBjcmVhdGVkLCBSUkVQX0dlbiBzaG91bGQgaW5j bHVkZSB0aGUgcHJlZml4IGxlbmd0aCBhc3NvY2lhdGVkIHdpdGggdGhlIHJvdXRlciBjbGllbnQg ZW50cnkgZm9yIFRhcmdBZGRyLiBTbyBhbGwgcm91dGVycyB3aGljaCByZWNlaXZlIHRoaXMgUlJF UCBsZWFybiBhIHJvdXRlIHRvIHRoZSBwcmVmaXggVGFyZ0FkZHIgaXMgcGFydCBvZiAoaWYgdGhl IHJvdXRlciBjbGllbnQgZW50cnkgaXMgY29uZmlndXJlZCB3aXRoIGEgcHJlZml4IGxlbmd0aCku IFRoZSB0ZXh0IGhhcyBiZWVuIHVwZGF0ZWQgdG8gbWFrZSB0aGlzIG1vcmUgb2J2aW91cy4NCg0K DQozMS4gbmV4dCBob3AgaXAgYWRkcmVzcyB3b3JkaW5nDQoNClRob21hczoNCkkgYWxzbyBjYWxs ZWQgdGhpcyBvdXQgaW4gbXkgcHJldmlvdXMgcmV2aWV3IGFzIGluY29ycmVjdCwgYW5kIGRlc3Bp dGUgd29yZHNtaXRoaW5nIGl0IHN0aWxsIGlzOg0KDQogICAgICAgIFJvdXRlLk5leHRIb3ANCiAg ICAgICAgICAgICAgVGhlIHNvdXJjZSBJUCBhZGRyZXNzIG9mIHRoZSBtZXNzYWdlIGFkdmVydGlz aW5nIHRoZSByb3V0ZSB0bw0KICAgICAgICAgICAgICBSb3V0ZS5BZGRyZXNzLCBpLmUuIGFuIElQ IGFkZHJlc3Mgb2YgdGhlIEFPRFZ2MiByb3V0ZXIgdXNlZCBmb3INCiAgICAgICAgICAgICAgdGhl IG5leHQgaG9wIG9uIHRoZSBwYXRoIHRvd2FyZCBSb3V0ZS5BZGRyZXNzLg0KDQpJZiB0aGF0IOKA nG1lc3NhZ2XigJ0gaXMgYW4gUkZDNTQ0NCBlbnRpdHksIHRoZW4gaXQgZG9lcyB0byBoYXZlIGEg 4oCcc291cmNlIElQIEFkZHJlc3PigJ0g4oCUIHRoZSBlbmNhcHN1bGF0aW5nIElQIGRhdGFncmFt IGNvbnRhaW5pbmcgdGhlIHBhY2tldCBjb250YWluaW5nIHRoZSBtZXNzYWdlIGRvZXMuIEFuZCB0 aGUgbWVzc2FnZSBNQVkgaGF2ZSBhbiBPcmlnaW5hdG9yIEFkZHJlc3MNCg0KQU9EVnYyOiBVcGRh dGVkIHRvIHNheSDigJx0aGUgc291cmNlIElQIGFkZHJlc3Mgb2YgdGhlIElQIHBhY2tldCBjb250 YWluaW5nIHRoZSBtZXNzYWdlIGFkdmVydGlzaW5nLi4u4oCdDQoNCg0KDQoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K VGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGlu dGVuZGVkDQpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5 c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yDQpkaXN0cmlidXRlIGl0cyBjb250 ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQptYW5ldCBtYWlsaW5n IGxpc3QNCg0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0 QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KDQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2C5CGLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUt Y29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7fQ0K c3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHls ZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA2OTMw NjQ5ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4MDQzMzkxNjt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIHN0aWxsIHBpZWNpbmcgdG9nZXRoZXIgZnJhZ21l bnRhcnkgaW5mb3JtYXRpb24uIEJ1dCBJIGJlbGlldmUgdGhhdCB0aGlzIHdhcyBhIHNlY29uZCBy ZWFzb24gZm9yIGxvb3BpbmcgKHRoZSBmaXJzdCBiZWluZyBhIHJhdGhlciBzdHJhbmdlIGludGVy cHJldGF0aW9uDQogdGhhdCB3YXMgZWFzaWx5IGRpc2NvdW50ZWQsIGFuZCBtYWRlIGV4cGxpY2l0 bHkgbm90IGFsbG93ZWQsIHRoaXMgaXMgbm90IGFib3V0IHRoYXQpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyB3 YXMgc29tZSBwcm9ibGVtIHRvIGRvIHdpdGggbXVsdGlwbGUgdW5jb25maXJtZWQgZW50cmllcy4g V2hpY2ggdGhlIGF1dGhvcnMgbWFkZSBpbXBvc3NpYmxlIGJ5IHJlbW92aW5nIHRoYXQgZmVhdHVy ZS4gQnV0IHdpdGhvdXQgZGlzY3Vzc2luZyB0aGF0IGhlcmUsDQogYW5kIGFjdHVhbGx5IGFmdGVy IHRoZXJlIHdhcyBhIHN0YXRlbWVudCB0aGF0IHRoZXJlIHdlcmVu4oCZdCBhbnkgbG9vcGluZyBp c3N1ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5CdXQgYXMgdGhhdCBoYXNu4oCZdCBhbGwgYmVlbiBjbGVhcmx5IHNh aWQsIHRoZXJlIG1heSB3ZWxsIGJlIGVycm9ycyBpbiB0aGUgYWJvdmUuIERvZXMgaXQgbWF0dGVy PyBJIHRoaW5rIHllcy4gVGhlcmUgYXJlIHR3byB3YXlzIHRvIGZpbmQgb3V0IGlmIGEgcHJvdG9j b2wgcmVhbGx5DQogd29ya3MuIE9uZSBpcyBhbmFseXNpcywgb25lIGlzIGltcGxlbWVudGluZyBh bmQgdGVzdGluZy4gTmVpdGhlciBpcyBwZXJmZWN0IG9mIGNvdXJzZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlcmUg d2XigJl2ZSBnb3QgYW4gYW5hbHlzaXMgdGhhdCBmb3VuZCBhIHByb2JsZW0uIEhhcyB0aGUgYW5h bHlzaXMgYmVlbiByZS1ydW4gb24gdGhlIGNoYW5nZWQgcHJvdG9jb2w/IEFzIHRoaW5ncyBhcmUg c3RpbGwgZXZvbHZpbmcsIG92ZXIgdGhpbmdzIGxpa2UgZGlyZWN0aW9uYWwNCiBtZXRyaWNzLCBp cyB0aGVyZSBhbiB1cCB0byBkYXRlIGFuYWx5c2lzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIEkgZG9u4oCZdCBi ZWxpZXZlIHRoZXJlIGlzIGFueSB1cCB0byBkYXRlIChvciBldmVuIGNsb3NlIHRvIHVwIHRvIGRh dGUpIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBmZWVkcyBpbnRvIG15IGdlbmVyYWwg cGVyY2VwdGlvbiwgaW4gYW5vdGhlciBlbWFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4N ClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOyYjNDM7NDQgKDApMTI0 NSAyNDIxOTQgJm5ic3A7fCAmbmJzcDs8Yj5FOg0KPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5k ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+ PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+ DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0 ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3Jl YXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6 Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cu YmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5C QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJy ZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWFuZXQgW21haWx0bzpt YW5ldC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3R0ZSBTdGVlbmJy aW5rPGJyPg0KPGI+U2VudDo8L2I+IDMwIEFwcmlsIDIwMTYgMTI6MTg8YnI+DQo8Yj5Ubzo8L2I+ IG1hbmV0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIEFPRFZ2MiByZXNwb25zZXMg dG8gcmVjZW50IGNvbW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48 L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNl bnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3Jn YW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5l dC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIi Pjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3Vs ZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bh bj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3Nw YW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBp biBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVu dC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMv UmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVl bCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDov L2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0 cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0 aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh ZGRpbmc6MS4wcHQgNC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qPHN0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+KioNCjwvc3Bhbj48L3N0cm9uZz48L3NwYW4+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5XQVJOSU5HDQo8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Kioq PC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBv cmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5mb3IgdGhlIHNha2Ugb2YgY29tcGxldGVuZXNzLCB0aGUgcGFwZXIgd2XigJl2ZSBtZW50aW9u ZWQgaXMgYXZhaWxhYmxlIG9uIGFyWGl2IG5vdzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL2FyeGl2Lm9yZy9hYnMv MTYwNC4wNzE3OSI+aHR0cDovL2FyeGl2Lm9yZy9hYnMvMTYwNC4wNzE3OTwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIHlvdSBjYW4g ZmluZCB0aGUgY29kZSBvZiB0aGUgdG9vbCB0aGF0IHdhcyB1c2VkIGhlcmU6Jm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly9naXRodWIuY29tL2IteW91c2VmaS93UmViZWNhIj5odHRwczovL2dpdGh1Yi5j b20vYi15b3VzZWZpL3dSZWJlY2E8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvdHRlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbSAxNi4w My4yMDE2IHVtIDE4OjEyIHNjaHJpZWIgTG90dGUgU3RlZW5icmluayAmbHQ7PGEgaHJlZj0ibWFp bHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlIj5sb3R0ZS5zdGVlbmJyaW5rQGZ1LWJl cmxpbi5kZTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIENocmlzdG9waGVyLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbSAwMi4wMy4yMDE2IHVtIDExOjM2IHNjaHJpZWIgRGVhcmxv dmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0Ozo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkg Y29uY2VybnMgaGF2ZSBiZWVuIHRoYXQgeW91ciBjby1hdXRob3JzIGhhdmUgY29udGludWVkIHRv IGRpc2N1c3Mgd2hldGhlciBsb29waW5nIGNvdWxkIG9jY3VyIHNpbmNlIHlvdSBwdWJsaXNoZWQg dG8gdGhlIGxpc3Qgc2F5aW5nDQogYWxsIHdhcyB3ZWxsLiAoQW4gaXNzdWUgdG8gZG8gd2l0aCBt dWx0aXBsZSB1bmNvbmZpcm1lZCByb3V0ZXMuKSBNYXliZSB0aGF04oCZcyBhIHByb2JsZW0sIG1h eWJlIGl0IGlzbuKAmXQuIEJ1dCBpdCBsYWNrcyB0cmFuc3BhcmVuY3ksIGJlY2F1c2UgaXQgaGFz buKAmXQgYmVlbiBkaXNjdXNzZWQgaGVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IGxvb3AgcG9zc2liaWxpdHkgeW914oCZcmUgcmVmZXJyaW5nIHRvIHdhcyBhIGRpZmZlcmVudCBv bmUgdGhhbiB0aGUgb25lIGRpc2N1c3NlZCBieSBDaGFybGllLiBXZeKAmXZlIGJlZW4gY29udGFj dGVkIGJ5IHJlc2VhcmNoZXJzIHdobyBhcmUgbW9kZWwgY2hlY2tpbmcgTUFORVQgcHJvdG9jb2xz IHRvIHNlZSBpZiB0aGV5IHBlcm1pdCBhbnkgdW53YW50ZWQgYmVoYXZpb3VyLiBUaGV54oCZdmUg dXNlZCBBT0RWdjINCiBhcyBhIGNhc2Ugc3R1ZHkgZm9yIHRoZSBmcmFtZXdvcmsgdGhleeKAmXZl IGltcGxlbWVudGVkIHRvIGRvIHRoaXMsIGFuZCB0aGV54oCZdmUgZm91bmQgdGhlIGZvbGxvd2lu ZyBsb29wOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbHQ7bmV0d29yay5qcGcmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7YmFja2dyb3Vu ZDp3aGl0ZSI+MS4gbjIgaW5pdGlhdGVzIGEgcm91dGUgZGlzY292ZXJ5IHByb2NlZHVyZSBmb3Ig ZGVzdGluYXRpb24gbjMgYnkgYnJvYWRjYXN0aW5nIGEg4oCccnJlceKAnSBtZXNzYWdlLjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYWxpZ246anVzdGlmeTtiYWNrZ3JvdW5kOndoaXRlIj4yLiBuMSBhbmQgbjQgdXBv biByZWNlaXZpbmcgdGhlIOKAnHJyZXHigJ0gbWVzc2FnZSwgYWRkIGEgcm91dGUgdG8gdGhlaXIg cm91dGluZyB0YWJsZXMgdG93YXJkcyBuMiBhbmQgc3RvcmUgbjIgYXMgdGhlaXIgbmV4dCBob3Au IFNpbmNlIGl0IGlzIHRoZSBmaXJzdCB0aW1lIHRoYXQgdGhlc2Ugbm9kZXMgaGF2ZSByZWNlaXZl ZCBhIG1lc3NhZ2UNCiBmcm9tIG4yLCB0aGUgbmVpZ2hib3Igc3RhdGUgb2YgbjIgaXMgc2V0IHRv IHVuY29uZmlybWVkLiBUaGVyZWZvcmUsIHRoZSByb3V0ZSBzdGF0ZSBpcyB1bmNvbmZpcm1lZC48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7YmFja2dyb3VuZDp3aGl0ZSI+My4gQXMgbjEgYW5k IG40IGFyZSBub3QgdGhlIGludGVuZGVkIGRlc3RpbmF0aW9uIG9mIHRoZSByb3V0ZSByZXF1ZXN0 LCB0aGV5IHJlYnJvYWRjYXN0IHRoZSDigJxycmVx4oCdIG1lc3NhZ2UuPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h bGlnbjpqdXN0aWZ5O2JhY2tncm91bmQ6d2hpdGUiPjQuIG4xIHJlY2VpdmVzIHRoZSDigJxycmVx 4oCdIG1lc3NhZ2Ugc2VudCBieSBuNCBhbmQgc2luY2UgdGhlIHJvdXRlIHRvIG4yIGlzIHVuY29u ZmlybWVkIGl0IGFkZHMgbjQgYXMgbmV3IG5leHQgaG9wIHRvIG4yLjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxp Z246anVzdGlmeTtiYWNrZ3JvdW5kOndoaXRlIj41LiBuNCBhbHNvIGFkZHMgbjEgYXMgdGhlIG5l dyBuZXh0IGhvcCB0b3dhcmRzIG4yIGFmdGVyIHByb2Nlc3NpbmcgdGhlIOKAnHJyZXHigJ0gc2Vu dCBieSBub2RlMS4gQXQgdGhpcyBwb2ludCBhIGxvb3AgaXMgZm9ybWVkIGJldHdlZW4gbjEgYW5k IG40IGJ1dCBub3QgdXNlZCB5ZXQuPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O2JhY2tncm91 bmQ6d2hpdGUiPjYuIG4zIHJlY2VpdmVzIHRoZSDigJxycmVx4oCdIG1lc3NhZ2Ugc2VudCBieSBu MSBhbmQgc2luY2UgaXQgaXMgdGhlIGRlc3RpbmF0aW9uLCBpdCBzZW5kcyBhIOKAnHJyZXDigJ0g bWVzc2FnZSB0b3dhcmRzIG4xLjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTtiYWNrZ3JvdW5k OndoaXRlIj43LiBuMiBtb3ZlcyBvdXQgb2YgbjEgYW5kIG40IGNvbW11bmljYXRpb24gcmFuZ2Uu PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O2JhY2tncm91bmQ6d2hpdGUiPjguIG4xIHJlY2Vp dmVzIHRoZSDigJxycmVw4oCdIG1lc3NhZ2Ugc2VudCBieSBuMyBhbmQgYXMgdGhlIHJvdXRlIHN0 YXRlIHRvd2FyZHMgbjIgaXMgdW5jb25maXJtZWQgaXQgbXVsdGljYXN0cyB0aGUg4oCccnJlcOKA nSBtZXNzYWdlIHRvIHRoZSBleGlzdGluZyBuZXh0IGhvcHMsIG4yIGFuZCBuNC4gU2luY2UgbjQg aXMgYWRqYWNlbnQgdG8gbjEsDQogaXQgcmVjZWl2ZXMgdGhlIG1lc3NhZ2UgYW5kIHRoZW4gc2Vu ZHMgYW4gYWNrIHRvIG4xLiBUaGVyZWZvcmUsIG4xIHNldHMgdGhlIG5laWdoYm9yIHN0YXRlIG9m IG40IHRvIGNvbmZpcm0gYW5kIHN1YnNlcXVlbnRseSB0aGUgcm91dGUgc3RhdGUgdG93YXJkcyBu MiB0byB2YWxpZC4gVGhlbiBleHB1bmdlIHRoZSBuZXh0IGhvcCBuMiB3aGljaCBoYXMgbm90IHJl Y2VpdmVkIGFuIGFjayBmcm9tLjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTtiYWNrZ3JvdW5k OndoaXRlIj45LiBuNCBieSByZWNlaXZpbmcgdGhlIOKAnHJyZXDigJ0gbWVzc2FnZSBmcm9tIG4x IG11bHRpY2FzdHMgaXQgdG8gaXRzIG5leHQgaG9wcyB0b3dhcmRzIG4xIGFuZCBuMiw8YnIgaWQ9 Inl1aV8zXzE2XzBfMV8xNDUwMTMxNDExOTk3XzI1NDMiPg0KYW5kIHNpbWlsYXIgdG8gbjEgaXQg dXBkYXRlcyBpdHMgcm91dGluZyB0YWJsZSBieSB2YWxpZGF0aW5nIG4xIGFzIGl0cyBuZXh0IGhv cCB0byBuMi4gQXQgdGhpcyBwb2ludCwgYSBsb29wIGJldHdlZW4gbjEgYW5kIG40IGJlY29tZXMg dmFsaWQuPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW4gcmVzcG9uc2UgdG8gdGhl c2UgZmluZGluZ3MsIHdlJ3ZlIGNoYW5nZWQmbmJzcDs2LjcuMS4gJm5ic3A7RXZhbHVhdGluZyBS b3V0ZSBJbmZvcm1hdGlvbiBpbiAtMTMsJm5ic3A7c28gdGhhdCBMb29wRnJlZSgpIGlzICphbHdh eXMqIGNvbnNpZGVyZWQgYmVmb3JlIGFkZGluZyBhIG5ldyByb3V0ZSwgZXZlbiBpZiBhbGwga25v d24gcm91dGVzIHRvIGRhdGUNCiBhcmUgVW5jb25maXJtZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9sbG93 aW5nIHVwLCB0aGV54oCZdmUgZm91bmQgYW5vdGhlciBsb29wIGluIC0xMzo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtuZXR3 b3JrLmpwZyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIx IiB0eXBlPSIxIiBpZD0ieXVpXzNfMTZfMF8xXzE0NTc0NTcyMzE5OThfMTQ1MDQiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRl IiBpZD0ieXVpXzNfMTZfMF8xXzE0NTc0NTcyMzE5OThfMTQ3NzMiPg0KQXQgZmlyc3Qgbm9kZXMg YXJlIGNvbm5lY3RlZCB0byBlYWNoIG90aGVyIGFzIHNob3duIGluIEZpZzEuYS48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIiBpZD0ieXVpXzNfMTZfMF8xXzE0NTc0 NTcyMzE5OThfMTQ1NjMiPg0KbjAgaW5pdGlhdGVzIGEgcm91dGUgZGlzY292ZXJ5IHByb2NlZHVy ZSBmb3IgZGVzdGluYXRpb24gbjMgYnkgbXVsdGljYXN0aW5nIGEg4oCccnJlceKAnSBtZXNzYWdl IHRvIG4yIHdpdGggc3E9Mi48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndo aXRlIiBpZD0ieXVpXzNfMTZfMF8xXzE0NTc0NTcyMzE5OThfMTQ1NjUiPg0KbjIgYWZ0ZXIgdXBk YXRpbmcgaXRzIHJvdXRpbmcgdGFibGUsIG11bHRpY2FzdCB0aGUg4oCccnJlceKAnSB0byBpdHMg bmVpZ2hib3JzLCBuMSBhbmQgbjMuPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7YmFja2dyb3Vu ZDp3aGl0ZSIgaWQ9Inl1aV8zXzE2XzBfMV8xNDU3NDU3MjMxOTk4XzE0NTAzIj4NCm4xIHVwb24g cmVjZWl2aW5nIHRoZSDigJxycmVx4oCdIG1lc3NhZ2Ugc2VudCBieSBuMiB1cGRhdGVzIGl0cyBy b3V0aW5nIHRhYmxlIGFuZCBhZGRzIGEgcm91dGUgd2l0aCBob3AtY291bnQ9Miwgc3E9MiBhbmQg bmV4dC1ob3BlPTI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIiBp ZD0ieXVpXzNfMTZfMF8xXzE0NTc0NTcyMzE5OThfMTQ1NjEiPg0KQ29uc2lkZXIgdGhhdCB0b3Bv bG9neSBjaGFuZ2VzIGF0IHRoaXMgcG9pbnQgYW5kIG4xIG1vdmVzIGludG8gY29tbXVuaWNhdGlv biByYW5nZSBvZiBuMCwgZ2V0cyBjb25uZWN0ZWQgdG8gbjAsIGFuZCBuMiBsZWF2ZXMgbjAgY29t bXVuaWNhdGlvbiByYW5nZSwgZ2V0cyBkaXNjb25uZWN0ZWQgZnJvbSBuMCwgd2hpY2ggbGVhZHMg dG8gbmV0d29yayB0b3BvbG9neSBzaG93biBpbiBGaWcxLmIuPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzE7YmFja2dyb3VuZDp3aGl0ZSIgaWQ9Inl1aV8zXzE2XzBfMV8xNDU3NDU3MjMxOTk4XzE0 NTM2Ij4NCm4wLCB3aGljaCBoYXNu4oCZdCByZWNlaXZlZCBhbiDigJxycmVw4oCdIHlldCwgcmVz ZW5kIHRoZSDigJxycmVx4oCdIG1lc3NhZ2UgYWZ0ZXIgaW5jcmVhc2luZyBpdHMgc2VxdWVuY2Ug bnVtYmVyIHRvIDMuPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSIg aWQ9Inl1aV8zXzE2XzBfMV8xNDU3NDU3MjMxOTk4XzE0NTM4Ij4NCm4xIHJlY2VpdmVzIHRoZSBu ZXcg4oCccnJlceKAnSBtZXNzYWdlLCB3aXRoIHNxPTMsIG5leHQtaG9wPTAgYW5kIGhvcC1jb3Vu dD0xLCBzaW5jZSBpdOKAmXMgYSBiZXR0ZXIgcm91dGUgaXQgd291bGQgYmUgYWRkZWQgdG8gdGhl IHJvdXRpbmcgdGFibGUuIFRoZW4gbjEgbXVsdGljYXN0IHRoZSDigJxycmVx4oCdIG1lc3NhZ2Ug dG8gaXRzIG5laWdoYm9ycywgbjIgYW5kIG4zLjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xO2Jh Y2tncm91bmQ6d2hpdGUiIGlkPSJ5dWlfM18xNl8wXzFfMTQ1NzQ1NzIzMTk5OF8xNDUzNCI+DQpu MiBldmFsdWF0ZSB0aGUgcmVjZWl2ZWQgbWVzc2FnZSBzZW50IGJ5IG4xIGFuZCBhZGRzIGEgbmV3 IHJvdXRlIHRvIGl0cyByb3V0aW5nIHRhYmxlIHdpdGggc3E9MywgbmV4dC1ob3A9MSBhbmQgaG9w LWNvdW50PTIgc2luY2UgdGhlIHNlcXVlbmNlIG51bWJlciBvZiB0aGUgcmVjZWl2ZWQgbWVzc2Fn ZSBpcyBncmVhdGVyIHRoYW4gdGhlIHN0b3JlZCBvbmUuPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGln bjpqdXN0aWZ5O2JhY2tncm91bmQ6d2hpdGUiPkF0IHRoaXMgcG9pbnQgYSBsb29wIGhhcyBiZWVu IGZvcm1lZCBiZXR3ZWVuIG5vZGVzIG4xIGFuZCBuMi48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+U2luY2Ugd2XigJl2ZSBtb3ZlZCB0byBkaXNhbGxvd2luZyBtdWx0aXBsZSBVbmNvbmZp cm1lZCByb3V0ZXMgKGluIC0xNCwgd2hpY2ggaXNu4oCZdCBwdWJsaXNoZWQgeWV0KSwgdGhpcyBv bmUgaXMgcmVzb2x2ZWQgYWxyZWFkeSBhcyB3ZWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZWFzb24gd2UgZGlkbuKAmXQgZGlz Y3VzcyB0aGlzIGVhcmxpZXIgb24gW21hbmV0XSB3YXMgdGhhdCB0aGUgYXV0aG9ycyBoYWRu4oCZ dCBzdWJtaXR0ZWQgdGhlaXIgcGFwZXIgeWV0IChhbmQgSSBkaWRu4oCZdCB3YW50IHRvIGxlYWsg dGhlaXIgd29yaykuIFRoZXnigJl2ZSBkb25lIHNvIG5vdywgYW5kIHdpbGwgc2VuZCB1cyBhIGxp bmsgdG8gdGhlaXIgcGFwZXIgb25jZSBpdOKAmXMgYXZhaWxhYmxlLiBJ4oCZbSBndWVzc2luZw0K IGl04oCZbGwgdGFrZSBhIHdoaWxlIHRvIGJlIHB1Ymxpc2hlZCBwcm9wZXJseSwgYnV0IGl0IHNo b3VsZCBiZSBlbm91Z2ggZm9yIGZvciBvdXIgcHVycG9zZXMgZm9yIHRoZSBwYXBlciB0byBhcHBl YXIgb24NCjxhIGhyZWY9Imh0dHA6Ly9hcnhpdi5vcmcvIj5hcnhpdi5vcmc8L2E+IGZvciBub3fi gKY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TG90dGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDdFN0UiPi0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJs b3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7JiM0Mzs0 NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVh cmxvdmVAYmFlc3lzdGVtcy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Us IENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVz c2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48 L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNB OEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lz dGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZv cmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5DaGFybGllDQogUGVya2lucyBbPGEgaHJlZj0ibWFpbHRvOmNoYXJsZXMu cGVya2luc0BlYXJ0aGxpbmsubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86 Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjAxIE1hcmNoIDIwMTYg MDE6MDg8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBtYW5ldDxicj4NCjxiPlN1 YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5SZTogW21hbmV0XSBBT0RWdjIgcmVzcG9uc2VzIHRvIHJlY2VudCBjb21tZW50czwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIu MHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5H ICoqKjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4 dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp ZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0 aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVy IHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciBy ZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdh cmRpbmc8L3NwYW4+PC9lbT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz Mzk3MiI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzMzMzk3MiI+dGhhdA0KIHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5 b3UgcmVjZWl2ZSwgY2xpY2s8L3NwYW4+PC9lbT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiZuYnNw Ozwvc3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz MzM5NzIiPjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3 b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVyZTwvc3Bhbj48L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J ZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdzwvc3Bhbj48 L2VtPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48ZW0+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93 d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3Vz cGljaW91cyUyMEVtYWlscy5wZGYiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRoaXMNCiBw cm9jZXNzPC9zcGFuPjwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+SGVsbG8gQ2hyaXMsPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij5PbiAxLzE5LzIwMTYgNTozNyBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BbmQgb3V0c2lkZSB0aG9zZSAz MSwgdGhhdCB3ZeKAmXJlIGF0IHRoaXMgcG9zaXRpb24gd2l0aCBhIHN1Z2dlc3Rpb24gdGhlcmXi gJlzIHBvc3NpYmxlIGxvb3BpbmcgKGFib3V0IHdoaWNoIEkgaGF2ZSBubyBpZGVhKSBpc27igJl0 IHRoYXQgY29tZm9ydGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxicj4NCkkgaG9wZSB5b3VyIGNvbmNlcm5zIGhhdmUgYmVlbiByZXNvbHZlZCBvbiB0aGlz IG1hdHRlci4mbmJzcDsgVGhlIHBhcGVyIG1lbnRpb25lZCBvbiB0aGUgbWFpbGluZyBsaXN0IHBv aW50ZWQgb3V0IHZhcmlvdXMgYW1iaWd1aXRpZXMgaW4gUkZDIDM1NjEgZGVzY3JpYmVkIGhvdyB0 aGUgYW1iaWd1aXRpZXMgbWlnaHQgYmUgY29uc3RydWVkIHRvIGluc3RhbGwgc2VsZi1yb3V0ZXMg YW5kLCBjb21iaW5lZCB3aXRoIHBvc3NpYmxlIGluY29uc2lzdGVudCBjaG9pY2VzDQogZm9yIHNl cXVlbmNlIG51bWJlciwgbG9vcHMgY291bGQgcmVzdWx0LiZuYnNwOyBCdXQgdGhlIGVtYWlsIHRv IHRoZSBsaXN0IHNldmVyYWwgd2Vla3MgYWdvIGluZGljYXRlZCB0aGF0IHRoZXNlIGFtYmlndWl0 aWVzIGRvIG5vdCBleGlzdCBpbiBBT0RWdjIuJm5ic3A7IFRoZSBhdXRob3JzIG9mIHRoYXQgcGFw ZXIgaGF2ZSBleHByZXNzZWQgaW50ZXJlc3QgaW4gZG9pbmcgYSBzaW1pbGFyIGFuYWx5c2lzIG9u IEFPRFZ2Mi48YnI+DQo8YnI+DQpPdGhlciBkaXNjdXNzaW9uIGFib3V0IHJvdXRpbmcgbG9vcHMg aGFzIG5vdCBpZGVudGlmaWVkIHJvdXRpbmcgbG9vcCBwcm9ibGVtcyBpbiB0aGUgZXhpc3Rpbmcg c3BlY2lmaWNhdGlvbi4mbmJzcDsgVXNlIG9mIHVuY29uZmlybWVkIG9yIGludmFsaWQgcm91dGVz IGZvciByb3V0aW5nIG1pZ2h0IGxlYWQgdG8gZXJyb3JzLCBidXQgdGhhdCBkb2Vzbid0IGNhcnJ5 IG92ZXIgdG8gcHJvZHVjZSBsb29wcyBpbiB0aGUgcm91dGUgdGFibGUuPGJyPg0KPGJyPg0KSSdt IGxvb2tpbmcgZm9yIGFueSBvdGhlciBvcGVuIGlzc3VlcyBvdXRzaWRlIG9mIHRoZSBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyB3aGljaCBpcyBiZWluZyByZXdvcmtlZCBhY2NvcmRpbmcgdG8gcmVj ZW50IGNvbW1lbnRzIGJ1dCBzaG91bGQgYmUgc3VibWl0dGVkIHNvb24uPGJyPg0KPGJyPg0KUmVn YXJkcyw8YnI+DQpDaGFybGllIFAuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoZXJl4oCZ cyBhbHNvIGEgbG90IG9mIGRvY3VtZW50IHRvIHJldmlldy4gV2hpY2ggb2YgY291cnNlIEkgaGF2 ZW7igJl0IGRvbmUgYXQgdGhpcyB0aW1lLiBCdXQgbXkgYXR0ZW50aW9uIGRpZCBhbGlnaHQgb24g dGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiwgYW5kIEkgbm90ZWQgdGhlcmUgdGhhdDo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4tIE5vdCBzdXJlIHdoeSB0aGUganVtcCB0byAxMCBmb3IgbWVz c2FnZSB0eXBlcywgdGhvdWdoIEnigJltIG5vdCBvcHBvc2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi Pi0gVGhlIFBBVEhfTUVUUklDIFRMViBjYW7igJl0IGJlIHR5cGUgMTAsIHRoYXTigJlzIGFscmVh ZHkgdGFrZW4uIFNlZSBJQU5BIHJlZ2lzdGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPi0gV2UgcHJl dmlvdXNseSBwb2ludGVkIG91dCB0aGF0IENPTlRfU0VRX05VTSAoQ09NUExFVEUpIGFscmVhZHkg ZXhpc3RzIGFuZCBkb2VzIHRoZSBqb2IgdGhhdCBTRVFfTlVNIGlzIGRvaW5nLCBzbyB3aHkgYWxs b2NhdGUgYW5vdGhlciBUTFY/IChZb3UgY291bGQgYXZvaWQgdGhlIG5lY2Vzc2l0eSBvZiByZXBl YXRpbmcgKENPTVBMRVRFKSBieSBzaW1wbHkgY29tbWVudGluZw0KIG9uY2UgYW5kIHRoZXJlYWZ0 ZXIgb21pdHRpbmcuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPi0gV2h5IHRoZSBzdWdnZXN0ZWQgc2tp cHBpbmcgb2YgdHlwZXMgMTIgdG8gMTQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PGI+LS08L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+Q2hyaXN0b3Bo ZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3Rl bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQo8L2I+PGJyPg0KPGI+VDwvYj46ICZuYnNwOyYjNDM7NDQgKDApMTI0NSAyNDIxOTQg Jm5ic3A7fCAmbmJzcDs8Yj5FOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z LmNvbTwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQs IEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9h aSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j ZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMz NzQ1MTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFy Y2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5tYW5ldCBbPGEgaHJl Zj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPm1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uDQogQmVoYWxmIE9mPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5WaWN0b3Jp YSBNZXJjaWVjYTxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj4xOCBKYW51YXJ5IDIwMTYgMjE6NDU8YnI+DQo8Yj5Ubzo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm1hbmV0PGJy Pg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlttYW5ldF0gQU9EVnYyIHJlc3BvbnNlcyB0byByZWNlbnQgY29tbWVudHM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj4qKiogV0FSTklORyAqKio8L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGVtPlRoaXMgbWVzc2FnZSBvcmln aW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRl cm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L2VtPjxpPjxicj4NCjxlbT5Db25zaWRlciBj YXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkg YXR0YWNobWVudHMgb3IgcmVwbHkuPC9lbT48YnI+DQo8ZW0+Rm9yIGluZm9ybWF0aW9uIHJlZ2Fy ZGluZzwvZW0+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxzdHJvbmc+UmVkIEZsYWdzPC9zdHJvbmc+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxlbT50aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWls cyB5b3UgcmVjZWl2ZSwgY2xpY2s8L2VtPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48ZW0+PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0 ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxh Z3MucGRmIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5oZXJlPC9zcGFuPjwvYT4uPC9lbT48 YnI+DQo8ZW0+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xs b3c8L2VtPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 ZW0+PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3Vz JTIwRW1haWxzLnBkZiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGhpcw0KIHByb2Nlc3M8 L3NwYW4+PC9hPi48L2VtPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4qPHN0cm9uZz4qKiBXQVJOSU5HICoqKjwvc3Ryb25nPjxicj4NCkVYVEVS TkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3Jn YW5pemF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SGkgYWxsLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+V2UgaGF2ZSBqdXN0IHJlbGVhc2VkIHRoZSBuZXdlc3Qg QU9EVnYyIGRyYWZ0LiBUaGUgbWFqb3IgdXBkYXRlIGlzIHRoZSBzZXBhcmF0aW9uIG9mIHRoZSBB T0RWdjIgcm91dGUgc2V0IGZyb20gdGhlIFJJQi48YnI+DQo8YnI+DQpIZXJlIGFyZSBhbHNvIHJl c3BvbnNlcyB0byB0aGUgY29tbWVudHMgcmVjZWl2ZWQgYmVmb3JlIENocmlzdG1hcy4gVGhpcyBz aG91bGQgaW5jbHVkZSBhbGwgdGhlIHBvaW50cyBmcm9tIFRob21hcyBDbGF1c2VuIHJlZ2FyZGlu ZyB2ZXJzaW9ucyAxMSBhbmQgMTIsIGFuZCBhbHNvIGEgY291cGxlIG9mIG90aGVyIHBvaW50cyB3 aGljaCBoYXZlIGJlZW4gYnJvdWdodCB1cCBzaW5jZS4gQXBvbG9naWVzIGZvciB0aGUgaHVnZSBl bWFpbC4gRm9yIGlzc3Vlcw0KIHRoYXQgbmVlZCBmdXJ0aGVyIGRpc2N1c3Npb24sIEkgaGF2ZSB0 cmllZCB0byBpbmNsdWRlIHRoZSBtYWluIHBvaW50cyBvZiB0aGUgZGlzY3Vzc2lvbiBzbyBmYXIu IFBsZWFzZSBmZWVsIGZyZWUgdG8gY3JlYXRlIGEgc2VwYXJhdGUgdGhyZWFkIGZvciBhbnkgZnVy dGhlciBkaXNjdXNzaW9uLjxicj4NCjxicj4NCldlIGFyZSBzdGlsbCBsb29raW5nIGludG8gdGhl IGxvb3AgY29uZGl0aW9ucyByZWNlbnRseSByZXBvcnRlZCBmb3IgQU9EViwgYWxzbyBzdGlsbCB3 b3JraW5nIG9uIHRoZSB0ZXh0IGFib3V0IHNlY3VyaXR5LCBhbmQgdXNlIG9mIG1zZy1ob3AtbGlt aXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5LaW5kIHJlZ2FyZHMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj5WaWN0b3JpYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRl Ij48YnI+DQoxLiBFbmQtdG8tZW5kIC8gaG9wLWJ5LWhvcCBhY2tzIC0gaXNzdWUgd2hlbiBhIHJv dXRlIGlzIG1hcmtlZCBhcyBjb25maXJtZWQgYW5kIHZhbGlkIHdoZW4gdGhlIGxpbmsgdG8gdGhl IG5leHQgaG9wIGlzIGNvbmZpcm1lZCBhcyBiaWRpcmVjdGlvbmFsIChidXQgdGhlIGxpbmtzIGRv d25zdHJlYW0gaGF2ZSBub3QgeWV0IGJlZW4gdmVyaWZpZWQgYXMgYmlkaXJlY3Rpb25hbCkuPGJy Pg0KPGJyPg0KQU9EVnYyOiBUaGUgYXV0aG9ycyBiZWxpZXZlIHRoaXMgaXMgYW4gaXNzdWUgd2hp Y2ggd291bGQgbm90IG9jY3VyIGZyZXF1ZW50bHksIGFuZCB3b3VsZCByaWdodCBpdHNlbGYuPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4N ClRoaXMgb25seSBvY2N1cnMgZm9yIHRoZSByb3V0ZSB0byBPcmlnQWRkci4gV2hhdCBuZWVkcyB0 byBoYXBwZW4gZm9yIHRoaXMgdG8gb2NjdXIgaXMgdGhhdCBhbiBpbnRlcm1lZGlhdGUgbm9kZSB0 aGF0IHRha2VzIHBhcnQgaW4gdGhlIHJvdXRlIGRpc2NvdmVyeSBiZXR3ZWVuIE9yaWdBZGRyIGFu ZCBUYXJnQWRkciBjb2luY2lkZW50YWxseSBoYXMgcGFja2V0cyB0byBzZW5kIHRvIE9yaWdBZGRy IGluIHRoZSB0aW1lIGJldHdlZW4gY29uZmlybWluZw0KIHRoZSBsaW5rIHRvIGl0cyBvd24gbmV4 dCBob3AgdG93YXJkIE9yaWdBZGRyIGlzIGJpZGlyZWN0aW9uYWwsIGFuZCB0aGUgdGltZSB0YWtl biBmb3IgYWxsIG90aGVyIHJvdXRlcnMgb24gdGhlIHBhdGggdG8gY29uZmlybSB0aGVpciBuZXh0 IGhvcHMgdG9vLiBJZiB0aGUgcm91dGUgaXMgdXNlZCB0byBmb3J3YXJkIHBhY2tldHMgYmVmb3Jl IGV2ZXJ5IG90aGVyIGxpbmsgaW4gdGhlIHBhdGggaXMgY29uZmlybWVkIGFzIGJpZGlyZWN0aW9u YWwsIGFuZA0KIHRoZSBkYXRhIHBhY2tldHMgYXJlIGZvcndhcmRlZCBmYXN0ZXIgdGhhbiB0aGUg UlJFUCBhbmQgYW55IFJSRVBfQWNrcywgdGhlbiB5ZXMgdGhleSBjb3VsZCBiZSBkZWxpdmVyZWQg dG8gYSByb3V0ZXIgd2l0aG91dCBhIHZhbGlkIHJvdXRlIHRvIE9yaWdBZGRyLiBBbHRlcm5hdGl2 ZWx5IGlmIG9uZSBvZiB0aGUgbGlua3MgdHVybnMgb3V0IHRvIGJlIHVuaWRpcmVjdGlvbmFsIHRo ZW4gdGhlIGRhdGEgcGFja2V0cyB3aWxsIGFsc28gYXJyaXZlIGF0DQogYSByb3V0ZXIgd2l0aG91 dCBhIHZhbGlkIHJvdXRlLiBJbiB0aGVzZSBjYXNlcywgUkVSUiBtZXNzYWdlcyB3aWxsIGJlIGdl bmVyYXRlZCB0b3dhcmQgdGhlIHNvdXJjZSBvZiB0aGUgdHJhZmZpYywgdGhlIHJvdXRlIHRvIE9y aWdBZGRyIHdpbGwgYmUgZGVsZXRlZCBhdCByb3V0ZXJzIGJhY2sgdG93YXJkIFRhcmdBZGRyLCBi dXQgaWYgZGF0YSBwYWNrZXRzIGFyZSBzdGlsbCBmbG93aW5nIGZyb20gYW55IHNvdXJjZSB0byBP cmlnQWRkciwgdGhlDQogcm91dGUgd2lsbCBiZSByZS1yZXF1ZXN0ZWQgYnkgdGhlIHJvdXRlciBy ZXNwb25zaWJsZSBmb3IgZGlzY292ZXJpbmcgcm91dGVzIGZvciB0aGUgc291cmNlIG9mIHRoZSBk YXRhLjxicj4NCjxicj4NClRoZSBjaGFuZ2VzIHJlcXVpcmVkIHRvIG1ha2UgYWNrbm93bGVkZ2Vt ZW50cyBlbmQtdG8tZW5kIHdvdWxkIHJlcXVpcmUgYSBsb3QgbW9yZSBjb250cm9sIHRyYWZmaWMg YW5kIGJlIG5lY2Vzc2FyeSBmb3IgZXZlcnkgcm91dGUgZGlzY292ZXJ5IGFuZCBpbiBhbG1vc3Qg YWxsIGNhc2VzIHdvdWxkIGJlIHVubmVjZXNzYXJ5Ljxicj4NCjxicj4NClRleHQgaGFzIGJlZW4g YWRkZWQgdG8gdGhlIGRyYWZ0IGluIOKAnExvY2FsIFJvdXRlIFN0YXRlIENoYW5nZXPigJ0gdG8g ZGVzY3JpYmUgdGhpcy48YnI+DQo8YnI+DQoyLiBCdWZmZXJpbmc8YnI+DQrvu79UaG9tYXM6PGJy Pg0K4oCcSXQgd291bGQgc2VlbSB0aGF0IGJ1ZmZlcmluZywgYXMgc3BlY2lmaWVkLCBkb2VzIG5v dCBhY2NvbXBsaXNoIHdoYXQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyPg0KaXQgc3RhdGVzIHRoYXQgaXQgYWNjb21wbGlzaGVzOiBwYWNrZXRzIGFy ZSAoYXMgeW91IGRlc2NyaWJlKSBzdGlsbCBiZWluZzxicj4NCnNlbnQgd2hpbGUgbm8gcm91dGUg aXMgYXZhaWxhYmxlLCBhbmQgdGhlcmVmb3JlIHdpbGwgYmUgZHJvcHBlZCBsYXRlci48YnI+DQo9 Jmd0OyBDb25zZXF1ZW50bHksIGl0IHNlZW1zIHRoYXQgYnVmZmVyaW5nIGlzIGEgZnV0aWxlIGV4 ZXJjaXNlP+KAnTxicj4NCjxicj4NCkFPRFZ2Mjog77u/UGFja2V0cyBhcmUgYnVmZmVyZWQgYmVm b3JlIGEgcm91dGUgZXhpc3RzLiBBIHJvdXRlciBvbmx5IGJlZ2lucyBzZW5kaW5nIHRoZW0gd2hl biBpdCBkZWVtcyB0aGUgcm91dGUgdG8gYmUgdmFsaWQuIEluIGdlbmVyYWwsIGJ1ZmZlcmluZyBp cyBub3QgZnV0aWxlLjxicj4NCjxicj4NClRydWUsIHRoZXJlIGlzIHRoaXMgY2FzZSBvdXRsaW5l ZCBhYm92ZSB3aGVyZSB0aGUgcm91dGVyIGNvdWxkIGRlZW0gdGhlIHJvdXRlIHZhbGlkIGJlZm9y ZSB0aGUgYmlkaXJlY3Rpb25hbGl0eSBjaGVjayBoYXMgaGFwcGVuZWQgZm9yIGVhY2ggYW5kIGV2 ZXJ5IGhvcC4gSWYgdGhlIGxpbmtzIGNob3NlbiBmb3IgdGhlIHJvdXRlIGFyZSBub3QgYWxsIGJp ZGlyZWN0aW9uYWwsIHRoZW4geWVzLCBhbnkgZGF0YSBwYWNrZXRzIGZvcndhcmRlZCBhbG9uZw0K IHRoaXMgcm91dGUgd2lsbCBlbmQgdXAgYmVpbmcgZHJvcHBlZCBhdCBzb21lIHBvaW50IG9uIHRo YXQgcGF0aC48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyPg0KVGhpcyBjYXNlIGlzIGNhdXNlZCBieSB0aGUgUlJFUF9BY2sgYmVpbmcgaG9wLWJ5LWhv cCwgYW5kIG5vdCBjYXVzZWQgYnkgYnVmZmVyaW5nLjxicj4NCjxicj4NClRob21hczog77u/PGJy Pg0K4oCcQnVmZmVycyBoYXZlIGh1Z2UgaW1wYWN0cyBvbiBUQ1AgcGVyZm9ybWFuY2UsIGFuZCBJ IGRvdWJ0IGlmIHRoZSBpc3N1ZXMgb24gZS5nLiBUQ1AgYXJlIHdlbGwgZW5vdWdoIHVuZGVyc3Rv b2QgYnkgdGhpcyBXRyAoQnVmZmVyYmxvYXQgd2FzIGFuIGV4YW1wbGUgb2Ygd2hlcmUgcGVvcGxl IGdvdCBpdCB3cm9uZywgZGVzcGl0ZSBoYXZpbmcgZXh0ZW5zaXZlIGV4cGVyaWVuY2UpLuKAnTxi cj4NCjxicj4NCkFPRFZ2MjogUGFja2V0cyB3aWxsIG9ubHkgYmUgYnVmZmVyZWQgd2hpbGUgYSBy b3V0ZSBpcyByZXF1ZXN0ZWQuIFRoZSBUQ1AgcGFja2V0cyBidWZmZXJlZCB3aWxsIGJlIHBhY2tl dHMgZm9yIHNlc3Npb24gaW5pdGlhbGlzYXRpb24uIFRoZSBhdXRob3JzIGJlbGlldmUgdGhhdCBi dWZmZXJpbmcgdGhlc2Ugd2lsbCBoYXZlIGEgcG9zaXRpdmUgZWZmZWN0LiBTb21lIHJlZmVyZW5j ZXMgaGF2ZSBiZWVuIHN1Z2dlc3RlZCwgbGlzdGVkIGhlcmUsIHRoZQ0KIGZpcnN0IG9mIHdoaWNo IGhhcyBiZWVuIGluY2x1ZGVkIGluIHRoZSBkcmFmdDo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3 LmllZWU4MDIub3JnLzIxL2FyY2hpdmVkX2RvY3MvMjAwMy0wOV9pbmNvbWluZy9jY3ItMjAwMTA5 LWtvb2RsaS5wZGYiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly93d3cuaWVlZTgw Mi5vcmcvMjEvYXJjaGl2ZWRfZG9jcy8yMDAzLTA5X2luY29taW5nL2Njci0yMDAxMDkta29vZGxp LnBkZjwvc3Bhbj48L2E+PGJyPg0KTW9iaWxlIEludGVybmV0d29ya2luZyB3aXRoIElQdjY6IENv bmNlcHRzLCBQcmluY2lwbGVzIGFuZCBQcmFjdGljZXMge0tvb2RsaSwgUGVya2luc308YnI+DQo8 YSBocmVmPSJodHRwOi8vZGlzYy5lY2UuaWxsaW5vaXMuZWR1L3NlbWluYXJzX3R1dG9yaWFscy90 Y3Atd2lyZWxlc3MtdHV0b3JpYWwucHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaXNj LmVjZS5pbGxpbm9pcy5lZHUvc2VtaW5hcnNfdHV0b3JpYWxzL3RjcC13aXJlbGVzcy10dXRvcmlh bC5wcHQ8L3NwYW4+PC9hPjxicj4NCkFuYWx5c2lzIG9mIFRDUCBwZXJmb3JtYW5jZSBvdmVyIG1v YmlsZSBhZCBob2MgbmV0d29ya3M8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2RsLmFjbS5vcmcvY2l0YXRpb24uY2ZtP2lkPTMx MzU0MCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL2RsLmFjbS5vcmcvY2l0YXRp b24uY2ZtP2lkPTMxMzU0MDwvc3Bhbj48L2E+PGJyPg0KQWx0ZXJuYXRpdmVseSwgd2UgY291bGQg cmVtb3ZlIHRoZSBtZW50aW9uIG9mIFRDUCwgYW5kIGluc3RlYWQgc3RhdGUgdGhhdCBidWZmZXJp bmcgTUFZIGJlIHVzZWQgZm9yIHBhY2tldHMgYXdhaXRpbmcgYSByb3V0ZSwgYnV0IHRoYXQgaW1w bGVtZW50YXRpb24gYW5kIGltcGxpY2F0aW9ucyBvZiB0aGlzIGFyZSBvdXQgb2Ygc2NvcGUgZm9y IEFPRFZ2Mi48YnI+DQo8YnI+DQo8YnI+DQozLiBVc2Ugb2YgbXNnLWhvcC1saW1pdCBhbmQgbXNn LWhvcC1jb3VudDo8YnI+DQpUaG9tYXM6PGJyPg0KQnV0LCBlaXRoZXIgd2F5LCBhcyBhY2NvcmRp bmcgdG8geW91ciBtb2RlbCBtZXNzYWdlcyBhcmUgbmV2ZXIgZm9yd2FyZGVkLCBidXQgYWx3YXlz IGFyZSBpbnRlbmRlZCBmb3IgcmVjZWlwdCBieSBhIHJvdXRlciB3aGljaCBpcyBhIGRpcmVjdCBu ZWlnaGJvciwgdGhlbiBhICZsdDttc2ctaG9wLWxpbWl0Jmd0OyAmZ3Q7MSAod2hpY2ggYXBwbGll cyB0byB0aGUgbWVzc2FnZSkgc2VlbXMgaW5hcHByb3ByaWF0ZS48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KQWN0dWFsbHksIGFjY29yZGluZyB0 byB0aGF0IG1vZGVsLCBJIHdvdWxkIGV2ZW4gc2F5IHRoYXQgcmVjZWlwdCBvZiBhIG1lc3NhZ2Ug d2l0aCBhICZsdDttc2ctaG9wLWNvdW50Jmd0OyAmZ3Q7MSBzaG91bGQgYmUgaW50ZXJwcmV0ZWQg YXMgYSBtYWxmdW5jdGlvbi48YnI+DQpBcyB5b3UgcmVmZXIgdG8gUkZDNTQ0NCBhcHBlbmRpeCBC LCBkbyBub3RlIHRoYXQgQXBwZW5kaXggQiBvZiBSRkM1NDQ0IChhbmQsIG5vdGUgdGhlIGVycmF0 YSA0MDAzKSB0YWxrcyBhYm91dDo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmx0O21zZy1ob3AtbGltaXQmZ3Q7IGZpZWxkLCBpZiBwcmVzZW50LCBjb250YWlucyB0aGUgbnVt YmVyIG9mIGhvcHMgb24gd2hpY2ggdGhlIG1lc3NhZ2UgaXMgYWxsb3dlZCB0byB0cmF2ZWwgYmVm b3JlIGJlaW5nIGRpc2NhcmRlZCBieSBhIE1BTkVUIHJvdXRlci4mbmJzcDsgVGhlICZsdDttc2ct aG9wLWxpbWl0Jmd0OyBpcyBzZXQgYnkgdGhlIG1lc3NhZ2Ugb3JpZ2luYXRvciBhbmQgaXMgdXNl ZCB0byBwcmV2ZW50IG1lc3NhZ2VzIGZyb20gZW5kbGVzc2x5IGNpcmN1bGF0aW5nDQogaW4gYSBN QU5FVC48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KU3BlY2lmaWNhbGx5IOKAnHNldCBieSB0aGUgbWVzc2FnZSBvcmlnaW5hdG9y4oCdIGFuZCDi gJxudW1iZXIgb2YgaG9wcyBvbiB3aGljaCB0aGUgbWVzc2FnZSBpcyBhbGxvd2VkIHRvIHRyYXZl bOKAnSDigJQgd2l0aCB5b3VyIGNvbnRyb2wgbWVzc2FnZXMgdHJhdmVsaW5nIGp1c3Qgb25lIGhv cCwgSSBiZWxpZXZlIHRoYXQgc2V0dGluZyAmbHQ7bXNnLWhvcC1saW1pdCZndDsgPSAxIGlzIGNv cnJlY3QuPGJyPg0KPGJyPg0KQU9EVnYyOiBEaXNjdXNzaW9uIGlzIHN0aWxsIG5lZWRlZCBoZXJl LiBXZSB3b25kZXIgaWYgdGhlc2UgZmllbGRzIGFyZSBuZWNlc3NhcnkgYXQgYWxsIGZvciBBT0RW djIuIFdlIHdlcmUgdXNpbmcgdGhlbSB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIHJlZ2VuZXJhdGlv bnMgb2YgYSBSUkVRLiBIb3dldmVyLCB0aGUgaG9wIGxpbWl0IHZhbHVlIG5lZWRzIHRvIGJlIGxh cmdlIGVub3VnaCB0byBhbGxvdyBhIFJSRVEgZnJvbSBvbmUgc2lkZSBvZiB0aGUNCiBuZXR3b3Jr IHRvIGFub3RoZXIuIEl0IG1pZ2h0IGJlIHRoZSBjYXNlIHRoYXQgdXNpbmcgdGhlIGhvcCBsaW1p dCwgYWxtb3N0IGV2ZXJ5IHJvdXRlciBpbiB0aGUgbmV0d29yayB3b3VsZCByZWNlaXZlIHRoYXQg UlJFUSBhbnl3YXksIGFuZCBieSB1c2luZyB0aGUgcmVkdW5kYW5jeSBjaGVjaywgd2UgYWxyZWFk eSBzdG9wIFJSRVFzIGZyb20gY2lyY3VsYXRpbmcgZW5kbGVzc2x5Ljxicj4NCjxicj4NCjQuIEFi c3RyYWN0PGJyPg0KVGhvbWFzOjxicj4NCuKAnEkgbWFkZSB0aGUgZm9sbG93aW5nIGNvbW1lbnQs IHdoaWNoIHN0aWxsIGFwcGxpZXM6PGJyPg0K4oCcVGhpcyBpcyBhIGxpdHRsZSBvdmVyLXN0YXRp bmcgdGhlIGFwcGxpY2FiaWxpdHk6IHRoZXNlIHN0YXRlbWVudHMgbWF5IGJlIHRydWUgaW4gc29t ZSBzY2VuYXJpb3MgKGZvciBleGFtcGxlLCB3aGVuIHRoZXJlIGFyZSBmZXcgY29uY3VycmVudCB0 cmFmZmljIGZsb3dzLCBhbmQgdGhlcmVmb3JlIGZldyByb3V0ZXMgdG8gcmVwYWlyLCBhbmQgdGhl cmVmb3JlIGZldyBmbG9vZGluZyBvcGVyYXRpb25zIHRvIGNvbnRlbmQgZm9yIGNoYW5uZWwgYWNj ZXNzKS4NCiBBcyBhIGdlbmVyYWwgc3RhdGVtZW50LCB0aGlzIGxhc3Qgc2VudGVuY2UgaXMgaW5j b3JyZWN04oCd4oCdPGJyPg0KPGJyPg0KQU9EVnYyOiBUaGUgdGV4dCBoYXMgYmVlbiByZW1vdmVk IGFuZCB0aGUgYWJzdHJhY3Qgbm93IHN0YXRlczog4oCcIFRoZSBBZCBIb2MgT24tZGVtYW5kIERp c3RhbmNlIFZlY3RvciBWZXJzaW9uIDIgKEFPRFZ2Mikgcm91dGluZyBwcm90b2NvbCBpcyBpbnRl bmRlZCBmb3IgdXNlIGJ5IG1vYmlsZSByb3V0ZXJzIGluIHdpcmVsZXNzLCBtdWx0aWhvcCBuZXR3 b3Jrcy4mbmJzcDsgQU9EVnYyIGRldGVybWluZXMgdW5pY2FzdCByb3V0ZXMgYW1vbmcgQU9EVnYy IHJvdXRlcnMNCiB3aXRoaW4gdGhlIG5ldHdvcmsgaW4gYW4gb24tZGVtYW5kIGZhc2hpb24u4oCd PGJyPg0KPGJyPg0KNSw5LDEyLDEzLDIwLiBSb3V0ZXIgQ2xpZW50PGJyPg0KVGhvbWFzOjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQrigJxJIG1h ZGUgYSBjb21tZW50IHByZXZpb3VzbHkgdGhhdCDigJxSb3V0ZXIgY2xpZW504oCdIGlzIGEgcG9v cmx5IGNob3NlbiB0ZXJtLCBhbmQgaGF2ZSBwcm9wb3NlZCBhbHRlcm5hdGl2ZXMuIEnigJl2ZSBz ZWVuIHNvbWUgYXR0ZW1wdHMgb24gdGhlIGxpc3QgYXQgcmF0aGVyIHRoYW4gY2hhbmdlIHRoZSB0 ZXJtLCBleHBsYWluIGl0IOKAlCBzb21lIG9mIHdoaWNoIGlzIGluIHRoaXMgZG9jdW1lbnQuIFRo ZSDigJxPdmVydmlld+KAnSBzdGlsbCB0YWxrcyBhYm91dCDigJxhDQogcm91dGVy4oCmb25lIG9m IGl0cyBjbGllbnRz4oCdIC0gd2hpY2ggaXMgbm8gbGVzcyBjb25mdXNpbmcgdGhhbiBsYXN0IHRp bWUgSXcgd2VudCB0aHJvdWdoIGl0Ljxicj4NCkkgcmVpdGVyYXRlLCB3aHkgbm90IHVzZSDigJxM b2NhbCBBdHRhY2hlZCBOZXR3b3JrIFNldOKAnSwgd2hpY2ggaXMgdGhlIHRlcm0gdXNlZCBieSBv dGhlciBkb2N1bWVudHMgZnJvbSB0aGlzIFdHP+KAnTxicj4NCjxicj4NCkFPRFZ2MjogV2UgYWxy ZWFkeSBhbnN3ZXJlZCB0aGlzIHN1Z2dlc3Rpb24gb24gdGhlIE1BTkVUIGxpc3QgYW5kIGFza2Vk IGZvciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMsIGFuZCBubyByZXNwb25zZXMgd2VyZSByZWNl aXZlZC4gV2UgaGF2ZSBkZWZpbmVkIHdoYXQgd2UgbWVhbiBieSBSb3V0ZXIgQ2xpZW50LCBhbmQg dGhlIHRlcm1pbm9sb2d5IGhhcyBzbyBmYXIgbm90IGNoYW5nZWQuIEhvd2V2ZXIsIHNvbWUgYWx0 ZXJuYXRpdmVzIGhhdmUNCiBiZWVuIHN1Z2dlc3RlZCwgc28gaWYgeW91IGZlZWwgYW55IG9mIHRo ZXNlIGFyZSBtb3JlIGVmZmVjdGl2ZSwgcGxlYXNlIGxldCB1cyBrbm93Ojxicj4NCu+7v+KAoiZu YnNwOyZuYnNwOyZuYnNwOyBBZHZlcnRpc2VkIElQIEFkZHJlc3M6IHB1dHMgdGhlIGVtcGhhc2lz IG9uIGFkdmVydGlzZW1lbnQgcmF0aGVyIHRoYW4gdG9wb2xvZ2ljYWwgY29ubmVjdGlvbjxicj4N CuKAoiZuYnNwOyZuYnNwOyZuYnNwOyBBY2Nlc3NpYmxlIElQIEFkZHJlc3M6IHB1dHMgdGhlIGVt cGhhc2lzIG9uIGFjY2Vzc2liaWxpdHkgdGhyb3VnaCB0aGUgcGFydGljdWxhciByb3V0ZXIg4oCT IG5vdCBiYWQ8YnI+DQrigKImbmJzcDsmbmJzcDsmbmJzcDsgUmVkdWNlZCBGdW5jdGlvbiBEZXZp Y2UgW1JGRF06IGRvZXNu4oCZdCByb2xsIG9mZiB0aGUgdG9uZ3VlLCBidXQgdGhpcyBpcyB0ZXJt aW5vbG9neSB1c2VkIGZvciBMMlIgaW4gSUVFRSA4MDIgV2lyZWxlc3MgZm9yIGEgc2ltaWxhciBz aXR1YXRpb248YnI+DQrigKImbmJzcDsmbmJzcDsmbmJzcDsgQWNjZXNzaWJsZSBEZXZpY2UgQWRk cmVzczogYWRkcyBzb21lIGVtcGhhc2lzIGZvciB0aGUgZGV2aWNlIGFzIHdlbGwgYXMgdGhlIGFk ZHJlc3M8YnI+DQrvu7/igKImbmJzcDsmbmJzcDsmbmJzcDsgU3RhYmx5IENvbm5lY3RlZCBJUCBB ZGRyZXNzOiBub3RoaW5nIGlzIHBlcm1hbmVudCwgb2YgY291cnNlLCBidXQgdGhlIHJvdXRlciBj bGllbnQgc2V0IGlzIHRob3VnaHQgdG8gYmUgcmVsYXRpdmVseSBzdGFibGU8YnI+DQrigKImbmJz cDsmbmJzcDsmbmJzcDsgVG9wb2xvZ2ljYWxseSBDb25uZWN0ZWQgSVAgYWRkcmVzczogLi4uIHN1 Z2dlc3RzIHRoYXQgYSAmcXVvdDt0b3BvbG9naWNhbCBjb25uZWN0aW9uJnF1b3Q7IGlzIHN0YWJs ZSBjb21wYXJlZCB0byB3aXJlbGVzczxicj4NCuKAoiZuYnNwOyZuYnNwOyZuYnNwOyBBZG1pbmlz dHJhdGl2ZWx5IEFzc2lnbmVkIElQIGFkZHJlc3M6IC4uLiBzb21laG93IGRvZXMgbm90IGNvbm5v dGUgdGhlICZxdW90O290aGVybmVzcyZxdW90OyBvZiB0aGUgcm91dGVyIGNsaWVudCBkZXZpY2Vz Ljxicj4NCjxicj4NCjYuIE92ZXJ2aWV3IC0gYWRqYWNlbmN5PGJyPg0KVGhvbWFzOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpUaGUgdGVybSDi gJxjb25maXJtaW5nIGFkamFjZW5jeeKAnSBpcyBnb25lLCBhbmQgaXMgbm93IHJlcGxhY2VkIGJ5 IOKAnGNvbmZpcm1pbmcgYmlkaXJlY3Rpb25hbGl0eeKAnSAtIHdoaWNoLCBhbGFzLCBzdGlsbCBz b3VuZHMgbGlrZSB0aGVyZSBpcyBzb21lIGFjdGl2ZSBtb25pdG9yaW5nIChIRUxMTyBtZXNzYWdl IGV4Y2hhbmdlKSBnb2luZyBvbi4gVW5sZXNzIHRoYXQgaXMgdGhlIGNhc2UsIHRoZW4gcGxlYXNl IGJlIG1vcmUgc3BlY2lmaWMgaGVyZS48YnI+DQpJIG5vdGUgdGhhdCB0aGUgdGVybSBhZGphY2Vu Y3kgaXMgdXNlZCB0aHJvdWdoIGFuZCB0aHJvdWdoIHRoZSBkb2N1bWVudCwgYnR3Ljxicj4NCjxi cj4NCkFPRFZ2MjogVGhlIHRleHQgaGFzIGJlZW4gdXBkYXRlZCB0byBhdm9pZCB0aGUgd29yZCBh ZGphY2VuY3kuIFdlIGRvIG5vdCBiZWxpZXZlIHRoZSB0ZXh0IGltcGxpZXMgYWN0aXZlIG1vbml0 b3JpbmcgdGhyb3VnaCBIRUxMTyBtZXNzYWdlcy48YnI+DQo8YnI+DQo3LiBPdmVydmlldyAtIGZv cndhcmRpbmcgcGxhbmU8YnI+DQpUaG9tYXM6IEkgc3VnZ2VzdGVkIGluIG15IGxhc3QgcmV2aWV3 OiBUaGUgb3ZlcnZpZXcgbXVzdCBhbHNvIGluY2x1ZGUgYSBwYXJhZ3JhcGggb24gdGhlIGludGVy c2VjdGlvbnMgYmV0d2VlbiB0aGlzIHByb3RvY29sIGFuZCB0aGUgZm9yd2FyZGluZyBwbGFuZSDi gJQgdGhpcywgYXMgaXQgaXMgZGlmZmVyZW50IChhbmQgbW9yZSBpbnZhc2l2ZSkgZnJvbSB0aGF0 IHdoaWNoIGlzIHR5cGljYWxseSBzZWVuIGluIHJvdXRpbmcgcHJvdG9jb2xzLjxicj4NClNwZWNp ZmljYWxseSwgYXMgYSByZWFjdGl2ZSBwcm90b2NvbCwgaXQgaXMgcmVxdWlyZWQgKGF0IGxlYXN0 KSB0aGF0IHRoZSBmb3J3YXJkaW5nIHBsYW5lIGlzIG1vZGlmaWVkIDo8YnI+DQoxKSBBIOKAnG1p c3PigJ0gd2hlbiBsb29raW5nIHVwIGEgbmV4dCBob3AgZm9yIGEgZGF0YSBwYWNrZXQgdG8gYmUg Zm9yd2FyZGVkLCBpcyBzaWduYWxsZWQgdG8gdGhlIEFPRFZ2MiBwcm9jZXNzIHNvIGFzIHRvIHBl cm1pdCB0aGF0IHJvdXRlIGRpc2NvdmVyeSBiZSBsYXVuY2hlZDs8YnI+DQoyKSBBIOKAnG1pc3Pi gJ0gd2hlbiBhdHRlbXB0aW5nIHRvIGRlbGl2ZXIgYSBkYXRhIHBhY2tldCB0byBhIG5leHQgaG9w LCB3aGljaCB3YXMgcmVjb3JkZWQgaW4gdGhlIHJvdXRpbmcgdGFibGUsIGlzIHNpZ25hbGxlZCB0 byB0aGUgQU9EVnYyIHByb2Nlc3Mgc28gYXMgdG8gcGVybWl0IHRoYXQgYSByb3V0ZSByZXBhaXIg YmUgaW5pdGlhdGVkIGFuZC9vciBhIFJvdXRlIEVycm9yIGJlIGdlbmVyYXRlZC48YnI+DQozKSBB IOKAnGhpdOKAnSB3aGVuIGxvb2tpbmcgdXAgYSBuZXh0IGhvcCBmb3IgYSBkYXRhIHBhY2tldCB0 byBiZSBmb3J3YXJkZWQgdG8gYSBkZXN0aW5hdGlvbiBpcyBzaWduYWxsZWQgdG8gdGhlIEFPRFZ2 MiBwcm9jZXNzIHNvIGFzIHRvIHBlcm1pdCBtYWludGVuYW5jZSBvZiDigJxhY3RpdmUgcm91dGXi gJ0gUm91dGUgU3RhdGUsIHRpbWVycyBhbmQgc3VjaC48YnI+DQpOb3RlIHRoYXQgdGhlc2UgdGhp bmdzIGFyZSBuZWNlc3NhcnkgdG8gY2FsbCBvdXQgaW4gdGhlIOKAnG92ZXJ2aWV34oCdIGFuZCBp biB0aGUg4oCcYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnTigJ0sIGJvdGg6IGl0IGlzIG5vdCB0aGF0 IHRoZXkgYXJlIG5lZ2F0aXZlcyBwZXIgc2UsIGJ1dCB0aGF0IHRoZXkgYXJlIGltcG9ydGFudCBm YWN0b3JzIGdvdmVybmluZyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGlzIHByb3RvY29sOiB3aWxs IGEgZ2l2ZW4gcGxhdGZvcm0NCiBwZXJtaXQgc3VjaCBhY2Nlc3MgdG8gdGhlIGZvcndhcmRpbmcg cGxhbmUsIGZvciBleGFtcGxlPyBJbXBvcnRhbnQgdG8gdW5kZXJzdGFuZCBpZiBmb3IgdGhhdCBw bGF0Zm9ybSB0aGlzIHByb3RvY29sIGlzIGFwcGxlPGJyPg0KSSBzZWUgdGhhdCB0aGlzIHdhcyBu b3QgYWRkcmVzc2VkIGluIHRoZSBvdmVydmlldywgbm9yIGluIHRoZSBhcHBsaWNhYmlsaXR5IG90 aGVyIHRoYW4gYnkgYSBmb3J3YXJkIHJlZmVyZW5jZSB0byBzZWN0aW9uIDYuNC4gV2hpbGUgaXQg aXMgcG9zaXRpdmUgdGhhdCB0aGVyZSBpcyBhIHNlY3Rpb24gNi40LCB0aGlzIGRvZXMgbm90IGV4 b25lcmF0ZSB0aGUgb3ZlcnZpZXcgYW5kIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBmb3Ig YmVpbmcgaG9uZXN0DQogYWJvdXQgdGhlIHJlcXVpcmVtZW50cyAobm90YWJseSB0byB0aGUgcGxh dGZvcm0vb3MpIHRoYXQgdGhpcyBwcm90b2NvbCBoYXMgZm9yIGJlaW5nIGFwcGxpY2FibGU8YnI+ DQo8YnI+DQpBT0RWdjI6IFRoZSBPdmVydmlldyBhbmQgdGhlIEFwcGxpY2FiaWxpdHkgU3RhdGVt ZW50IG5vdyByZWZlciB0byB0aGVzZSBiYXNpYyByZXF1aXJlbWVudHMgZm9yIHRoZSBpbnRlcmFj dGlvbiB3aXRoIHRoZSBmb3J3YXJkaW5nIHBsYW5lLiBUaGUgQXBwbGljYWJpbGl0eSBTdGF0ZW1l bnQgYWxzbyBjb250YWlucyB0aGUgcmVmZXJlbmNlIHRvIHRoZSBsYXRlciBzZWN0aW9uIHdoaWNo IGRlc2NyaWJlcyB0aGlzIGluIG1vcmUgZGV0YWlsLjxicj4NCjxicj4NCjguIDcxODIgYW5kIHNl Y3VyaXR5PGJyPg0KPGJyPg0KVGhvbWFzOiBJIHN1Z2dlc3RlZCBpbiBteSBsYXN0IHJldmlldzog SXQgaXMgaW1wb3J0YW50IHRvIGRvIG1vcmUgdGhhbiB0aGlzOiA3MTgyIGRvZXMgb25seSBwcm92 aWRlIOKAnGNvbnRhaW5lcnPigJ0gZm9yIElDVnMgYW5kIHRpbWVzdGFtcHMsIGFuZCBkb2VzIG5v dCBzcGVjaWZ5IGhvdyB0byB1c2UgdGhlbSB0byBvYnRhaW4gc3BlY2lmaWMgc2VjdXJpdHkgcHJv cGVydGllcy4gUkZDNzE4MiBtYXkgYmUgYSB0b29sIHRoYXQgY2FuIGJlIHVzZWQsIGJ1dA0KIGhv dyogdGhhdCB0b29sIGlzIHVzZWQgaXMgd2hhdCBkZXRlcm1pbmVzIHRoZSBzZWN1cml0eSBwcm9w ZXJ0aWVzLjxicj4NClRoZXJlZm9yZSwgc2F5aW5nIHRoYXQg4oCcc2VjdXJpdHkgaXMgZGVhbHQg d2l0aCBieSB1c2luZyBSRkM3MTgy4oCdIGlzIGVpdGhlciBhbiBpbmNvbXBsZXRlIHN0YXRlbWVu dCwgb3IgaXMgaW5kaWNhdGl2ZSBvZiBpbnN1ZmZpY2llbnQgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMu4oCdPGJyPg0KVGhlIGFjdHVhbCBzZW50ZW5jZSBpbiB0aGUgSS1EIGhhcyBiZWVuIGNoYW5n ZWQsIG5vdyBpdCBleHBsaWNpdGx5IG5hbWVzIHRoZSB0d28gVExWcyBmcm9tIDcxODIgdGhhdCBp dCB1c2VzLiBUaGF0IGlzLCBhbGFzLCBzdGlsbCBub3Qgc3VmZmljaWVudC48YnI+DQpNYWtpbmcg dGhlIGFzaWRlIHRoYXQgd2FzIGRpc2N1c3NlZCByZWNlbnRseSBvbiB0aGUgbGlzdCwgdGhhdCAo aSkgY29udHJvbCBtZXNzYWdlcyBhcmUgbm90IGZvcndhcmRlZCwgYW5kIHRoYXQgKGlpKSB0aGV5 IGFyZSBtb2RpZmllZCBpbiB0cmFuc2l0LCB0aGUgc2VjdXJpdHkvdHJ1c3QgbW9kZWwgaXMgc29t ZXdoYXQgZGlmZmVyZW50IGZyb20gdGhhdCBvZiA3MTgxIGFuZCBjb25zZXF1ZW50bHkgZm9yIHdo YXQgNzE4MiB3YXMgaW5pdGlhbGx5DQogd3JpdHRlbiBmb3IuIEkgdGhpbmsgdGhhdCZuYnNwOyBj YWxsaW5nIG91dCB0aGUgdHJ1c3QgbW9kZWwsIGFuZCBob3cgNzE4MiBhY3R1YWxseSBpcyB1c2Vk IGhlcmUsIG1pZ2h0IGJlIHdoYXQgaXMgY2FsbGVkIGZvci48YnI+DQpDb250aW51aW5nIHdpdGgg dGhlIGFzaWRlLCB0aGlzICplc3BlY2lhbGx5KiBhcyB0aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1l bnQgc2F5czogJnF1b3Q7UHJvdmlkaW5nIHNlY3VyaXR5IGZvciBhIHJlYWN0aXZlIHJvdXRpbmcg cHJvdG9jb2wgY2FuIGJlIGRpZmZpY3VsdOKAnTxicj4NCjxicj4NClRob21hczo8YnI+DQrvu79P Sywgc28gYXNzdW1lIHRoYXQgSSB1bmRlcnN0YW5kIHJlZ2VuZXJhdGlvbiBhcyBwZXIgbXkgcHJl dmlvdXMgZW1haWwsIGFzIG1lYW5pbmcg4oCcZ2VuZXJhdGUgYSBuZXcgbWVzc2FnZSBhbmQgc2Vu ZCB0byBteSBuZWlnaGJvcnMsIGJhc2VkIG9uIHdoYXQgSSBsZWFybmVkIHdoZW4gcHJvY2Vzc2lu ZyBhIHJlY2VpdmVkIG1lc3NhZ2XigJ0g4oCUIGp1c3QgbGlrZSBhbnkgZGlzdGFuY2UgdmVjdG9y IHByb3RvY29sIGRvZXMuPGJyPg0KSW4gdGhhdCBtb2RlbCwgd2hhdCB5b3Ugd3JpdGUgbWFrZXMg c2Vuc2U6IGVhY2ggb3JpZ2luYXRvciBvZiBhIGNvbnRyb2wgbWVzc2FnZSAoaS5lLiwgd2hvZXZl ciBnZW5lcmF0ZXMgb3IgcmVnZW5lcmF0ZXMgaXQpIGlzIGZyZWUgdG8gaW5jbHVkZSB0aGUgaW5m b3JtYXRpb24gaXQgZGVzaXJlcywgc3VjaCBhcyB0aGUgNCBwb2ludHMgeW91IGxpc3QgYWJvdmUu IE5vIGlzc3VlcyB3aXRoIHRoYXQuPGJyPg0KSG93ZXZlciwgYW5kIHRoaXMgam9pbnMgd2hhdCBJ IHBvaW50ZWQgb3V0IGluIGEgcHJldmlvdXMgZW1haWwsIHlvdSB3cml0ZSBpbiB0aGUgYXBwbGlj YWJpbGl0eSBzdGF0ZW1lbnQ6ICZxdW90O1Byb3ZpZGluZyBzZWN1cml0eSBmb3IgYSByZWFjdGl2 ZSByb3V0aW5nIHByb3RvY29sIGNhbiBiZSBkaWZmaWN1bHQuJnF1b3Q7PGJyPg0KV2hpbGUgd2Ug Y2FuIGRpc2N1c3MgaWYgdGhlIG5hdHVyZSBvZiZuYnNwO+KAnHJlYWN0aXZlIHJvdXRpbmcgcHJv dG9jb2zigJ0gZ2VuZXJhdGVzIHBhcnRpY3VsYXIgZGlmZmljdWx0aWVzLCB3ZSBjZXJ0YWlubHkg Y2FuIGFncmVlIHRoYXQgdGhpcyBwcm90b2NvbCBoYXMgdGhlIHNhbWUmbmJzcDvigJxkaWZmaWN1 bHRpZXPigJ0gYXMgYSBkaXN0YW5jZSB2ZWN0b3IgcHJvdG9jb2w6IHJvdXRpbmcmbmJzcDt0b3Bv bG9neSBpbmZvcm1hdGlvbiAoYnkgZGVmaW5pdGlvbikgbm90IGJlaW5nDQogZXhjaGFuZ2VkIGVu ZC10by1lbmQsIGJ1dCBiZXR3ZWVuIG5laWdoYm9ycyAod2hvIGRvJm5ic3A7Y2FsY3VsYXRpb25z IGFuZCBnZW5lcmF0ZSB0aGVpciBvd24gYW5ub3VuY2VtZW50cyZuYnNwO+KAlCByZWdlbmVyYXRp b24sIGFzIHlvdSBjYWxsIGl0KS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KVGhpcyBtZWFucyB0aGF0IGEgc3BlY2lmaWMgc2VjdXJpdHkgbW9k ZWwgb2YgdHJhbnNpdGl2ZSB0cnVzdCBtdXN0IGJlIGFzc3VtZWQsIG5vPyBJIHRydXN0IFZpY3Rv cmlhLCZuYnNwO3RoZXJlZm9yZSB3aGVuIFZpY3RvcmlhIHNheXMmbmJzcDvigJxTdGFuIHRvbGQg bWXigJ0mbmJzcDt0aGVuIEkgdHJ1c3QgdGhhdCBzaGUmbmJzcDthY3R1YWxseSB2ZXJpZmllZCB0 aGF0ICZxdW90O2l0IHdhcyBpbmRlZWQgU3RhbiB3aG8gdG9sZCBoZXImbmJzcDvigKbigJ0mbmJz cDvigJQgYW5kIGVpdGhlciB3YXksIEkgaGF2ZSBubyB3YXkNCiBvZiB2ZXJpZnlpbmc/PGJyPg0K SSBkaWQgbm90IHNlZSB0aGUgdHJ1c3QgbW9kZWwgLyB0cnVzdCBhc3N1bXB0aW9uIGRpc2N1c3Nl ZCBpbiB0aGUgc3BlY2lmaWNhdGlvbiAoc3BlY2lmaWNhbGx5IG5vdCBpbiBhcHBsaWNhYmlsaXR5 IGFuZCBpbiBzZWN0aW9uIDEzLCBib3RoIG9mIHdoZXJlIGl0IHNob3VsZCBiZSBjYWxsZWQgb3V0 KSwgYnV0IEkgdGhpbmsgdGhhdCB0aGlzIGlzIGFjdHVhbGx5IGEgY3J1Y2lhbCBwb2ludCB0byBn ZXQgcmlnaHQsIGluIG9yZGVyIHRvIGFwcHJvYWNoDQogZGV2ZWxvcGluZyB0aGUgTVRJIHNlY3Vy aXR5IG1lY2hhbmlzbXMuPGJyPg0KQW55d2F5cywgdGhhdCBvYnNlcnZhdGlvbiBhY3R1YWxseSBj b250cmFzdHMgc3Ryb25nbHkgd2l0aCB3aGF0IHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCB0 aGVuIGdvZXMgb24gdG8gc2F5LCBuYW1lbHk6PGJyPg0KJm5ic3A7Jm5ic3A7IEFPRFZ2MiBwcm92 aWRlcyBmb3IgbWVzc2FnZSBpbnRlZ3JpdHkgYW5kIHNlY3VyaXR5IGFnYWluc3QgcmVwbGF5PGJy Pg0KJm5ic3A7Jm5ic3A7IGF0dGFja3MgYnkgdXNpbmcgaW50ZWdyaXR5IGNoZWNrIHZhbHVlcywg dGltZXN0YW1wcyBhbmQgc2VxdWVuY2U8YnI+DQombmJzcDsmbmJzcDsgbnVtYmVycywgYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gMTMuPGJyPg0KVGhpcyBpcyB0cnVlIG9ubHkgaW4gYXMgbXVjaCBh cyBtZXNzYWdlcyBhcmUgaW5kZWVkIGV4Y2hhbmdlZCBiZXR3ZWVuIG5laWdoYm9yczogd2hlbiB5 b3UmbmJzcDvigJxyZWdlbmVyYXRl4oCdIGEgbWVzc2FnZSwgaS5lLiwgZ2VuZXJhdGUgYSBuZXcm bmJzcDttZXNzYWdlIGluIHJlc3BvbnNlIHRvIHJlY2VpcHQgb2YgYSBtZXNzYWdlLCB5b3UgZ2Vu ZXJhdGUgYnJhbmQgbmV3IHBheWxvYWQgKGJ1dCBwb3NzaWJseSBpbmNsdWRpbmcgc29tZSBvZiZu YnNwO3RoZSBkYXRhIGZyb20NCiB0aGUgcmVjZWl2ZWQgbWVzc2FnZSwgb2YgY291cnNlKTogdGh1 cywgYW55IElDVnMmbmJzcDvigJxmcm9tIGZhcnRoZXIgYXdheSB0aGFuIHRoZSBuZWlnaGJvcuKA nSZuYnNwO3dpbGwgYmUgdXNlbGVzcyAob3IsIGlmIHlvdSB6ZXJvIG91dCB0aGUgcGFydHMgdGhh dCB5b3UgY2hhbmdlLCB0aGVzZSBwYXJ0cyB3aWxsIG5vdCBiZSBwcm90ZWN0ZWQpLjxicj4NClRo ZSBhYm92ZSBzZW50ZW5jZSwgcXVvdGVkIGZyb20gdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50 LCBhbmQgdGhhdCB3aGljaCB0cmFuc3BpcmVzIGZyb20gc2VjdGlvbiAxMywgc2VlbXMgLSBjZXJ0 YWlubHksIGFic2VudCB0aGUgdHJ1c3QgbW9kZWwgYXNzdW1lZCAtIHRvIHN1Z2dlc3QgdGhhdCBl bmQtdG8tZW5kIHByb3RlY3Rpb24vdmFsaWRhdGlvbiBpcyBwcm92aWRlZC4gQnV0LCB0aGlzIGlz IG5vdCB0aGUgY2FzZS48YnI+DQpGaW5hbGx5IHRvIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVu dCwgYSBxdWVzdGlvbjo8YnI+DQpJZiBzZWN1cml0eSBhc3NvY2lhdGlvbnMgY2FuIGJlIGVzdGFi bGlzaGVkLCBlbmNyeXB0aW9uIGNhbiBiZSB1c2VkIGZvciBBT0RWdjIgbWVzc2FnZXMgdG8gZW5z dXJlIHRoYXQgb25seSB0cnVzdGVkIHJvdXRlcnMgcGFydGljaXBhdGUgaW4gcm91dGluZyBvcGVy YXRpb25zLjxicj4NCldoYXQgeW91IHdhbnQgdG8gc2F5IGhlcmUgaXMgdGhhdCDigJxpZiBhbGwg dHJ1c3RlZCByb3V0ZXJzIGhhdmUgYSBzaGFyZWQgc2VjcmV0LCB0aGVuIHdl4oCZcmUgYWJsZSB0 byB1c2UgdGhhdCBzaGFyZWQgc2VjcmV0IHRvIGlnbm9yZSBub24tdHJ1c3RlZCByb3V0ZXJz4oCd LCByaWdodD88c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyPg0KV2hpbGUg4oCcc2VjdXJpdHkgYXNzb2NpYXRpb25z4oCdIHRoYXQgZG8gbm90IHBhc3Mg dGhyb3VnaCBhIHNoYXJlZCBzZWNyZXQgcHJvYmFibHkgY2FuIGJlIHRob3VnaHQgdXAsIGl04oCZ cyBub3QgdHJpdmlhbCBhbmQgSSBkaWQgbm90IGZpbmQgYW55IGRpc2N1c3Npb24gb2YgdGhhdCBp biB0aGUgZG9jdW1lbnQ/PGJyPg0KSGF2aW5nLCBvbiB0aGUgdG9waWMgb2Ygc2VjdXJpdHksIHJl LXJlYWQgU2VjdGlvbiAxMywgd2hpY2ggc3RhcnRzOjxicj4NCiZuYnNwOyZuYnNwOyBUaGlzIHNl Y3Rpb24gZGVzY3JpYmVzIHZhcmlvdXMgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYW5kIHBvdGVu dGlhbDxicj4NCiZuYnNwOyZuYnNwOyBhdmVudWVzIHRvIHNlY3VyZSBBT0RWdjIgcm91dGluZy4m bmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KV2hpbGUgdGhpcyBpcyBhbiBob25lc3QgZGVzY3JpcHRpb24gb2Ygd2hhdCBmb2xsb3dzLCBJ IHJlbWFpbiBjb252aW5jZWQgdGhhdCB0aGlzIGlzIG5vdCBzdWZmaWNpZW50LiBTbyBsZXQgbWUg YXNrIGFzIHByZWNpc2VseSBhcyBJIGNhbjo8YnI+DQpvIHdoYXQgaXMgdGhlIE1USSBzZWN1cml0 eSBtZWNoYW5pc20gdGhhdCBhIGNvbmZvcm1hbnQgaW1wbGVtZW50YXRpb24gbXVzdCBwcm92aWRl PyZuYnNwO1NwZWNpZmljYWxseTogLSB3aGljaCBhcmUgdGhlIHByb2Nlc3Npbmcgc3RlcHMgKGZv ciBleGFtcGxlIGluIHNlY3Rpb24gNy4yLjEmbmJzcDthbmQgc2VjdGlvbiA3LjIuMiBmb3IgUlJF UCAtIGFuZCBzaW1pbGFybHkgZm9yIHRoZSBvdGhlciBtZXNzYWdlJm5ic3A7dHlwZXMpIHRoYXQg ZGVmaW5lIHRoYXQgc2VjdXJpdHkNCiBtZWNoYW5pc208YnI+DQpvIHdoYXQgcHJvdGVjdGlvbiBp cyBvZmZlcmVkIGJ5IHRoYXQgTVRJIHNlY3VyaXR5IG1lY2hhbmlzbT8gQW5kIHdoYXQgcmVtYWlu cyB2dWxuZXJhYmxlLjxicj4NCklmIHRoaXMgc3BlY2lmaWNhdGlvbiB0YXJnZXRzIHN0ZC50cmFj aywgdGhlbiBpdCBzaG91bGQgaW5jbHVkZSAocmVhc29uYWJseSBzb2xpZCwgYnV0IGRlZmluaXRl bHkgd2VsbCBzcGVjaWZpZWQpIE1USSBzZWN1cml0eS48YnI+DQo8YnI+DQpDaHJpcyBEZWFybG92 ZTo8YnI+DQrvu79UaGVyZSBhcmUgdHdvIHBvdGVudGlhbCBjaG9pY2VzOjxicj4NCjxicj4NCi0g UlJFUSBoYXMgYW4gaW50ZWdyaXR5IGNoZWNrIHZhbHVlIHRvIGluZGljYXRlIHRoYXQgc29tZW9u ZSB0cnVzdGVkIGNyZWF0ZWQgaXQsIGlmIG5vdCBuZWNlc3NhcmlseSB0aGUgZGVzdGluYXRpb24u IFRoYXQgc29tZW9uZSBtaWdodCBiZSBpZGVudGlmaWFibGUgb3Igbm90Ljxicj4NCi0gUlJFUSBo YXMgYSBzaWduYXR1cmUgdGhhdCBpbmRpY2F0ZXMgdGhhdCB0aGUgZGVzdGluYXRpb24gY3JlYXRl ZCBpdC48YnI+DQo8YnI+DQpVbmZvcnR1bmF0ZWx5LCBhbiBSUkVRIHRoYXQgY2hhbmdlcyBhcyBp dCBpcyBmb3J3YXJkZWQgKGFnZ3JlZ2F0aW5nIGRhdGEgb2YgYW55IHNvcnQpIG1ha2VzIHRoZSBz ZWNvbmQgb3B0aW9uIHRyaWNreSwgdW5sZXNzIHRoZXJl4oCZcyBzb21lIHNvcnQgb2YgYWdncmVn YXRpbmcgc2lnbmF0dXJlIGFzIGl0IGlzIGZvcndhcmRlZC4gQnV0IEnigJltIG5vdCBhbiBleHBl cnQgb24gdGhlIGxhdHRlci48YnI+DQo8YnI+DQpUaGUgbW9zdCB0cml2aWFsIGNhc2Ugb2YgdGhl IGZvcm1lciBpcyBzaW1wbHkgdGhhdCBldmVyeW9uZSB0cnVzdGVkIGhhcyBhIHNpbmdsZSBzaGFy ZWQga2V5LiBUaGF0IGhhcyBvYnZpb3VzIGlzc3VlcyDigJMgYWx0aG91Z2ggaXQgd2FzIGdvb2Qg ZW5vdWdoIHRoYXQgZW1ib2RpZWQgYXMgUkZDIDcxODMgd2UgY291bGQgZ2V0IDcxODEgdGhyb3Vn aCB0aGUgc3lzdGVtIChhcyBhIOKAnG11c3QgaW1wbGVtZW50LCBkbyBub3QgbmVlZCB0byB1c2Xi gJ0gbWluaW1hbA0KIGNhc2UpLiBBbHRlcm5hdGl2ZWx5IHNvbWV0aGluZyBpZGVudGl0eS1iYXNl ZCAoZS5nLiBkcmFmdC1pZXRmLW1hbmV0LWlicykgY291bGQgYmUgdXNlZCwgc28geW91IGtub3cg d2hvIGNyZWF0ZWQgdGhlIG1lc3NhZ2UgeW91IHJlY2VpdmVkLCBidXQgeW91IGFyZSByZWx5aW5n IG9uIGEgY2hhaW4gb2YgdHJ1c3QsIGhvcCBieSBob3AuIEF0IHdoaWNoIHBvaW50IHlvdSBtaWdo dCBhcyB3ZWxsIGp1c3Qgc2lnbiBwYWNrZXRzIChzZWUgUkZDIDcxODIpLjxicj4NCjxicj4NCkJ1 dCBpbiBldmVuIHRoZSB3ZWFrZXN0IGNhc2UgKHRoZSBzaW5nbGUgc2hhcmVkIGtleSB1c2VkIGhv cCBieSBob3ApIHRoZXJlIGhhcyB0byBiZSBhIGZhaWx1cmUgZm9yIHRoaW5ncyB0byBnbyB3cm9u ZyAtIGVpdGhlciBsb3NzIG9mIGtleSAoaW4gd2hpY2ggY2FzZSBhbGwgYmV0cyBhcmUgb2ZmKSBv ciBzdWJvcm5pbmcgb25lIHJvdXRlciAod2hvIGNhbiBkbyBxdWl0ZSBhIGxvdCBvZiBkYW1hZ2Up Ljxicj4NCjxicj4NCkkgaGF2ZW4ndCByZWFkIHRoZSBsYXRlc3QgQU9EVnYyIGRyYWZ0IHlldCwg YnV0IHRoaXMgc29ydCBvZiB0aGluZyBzaG91bGQgYmUgZGVzY3JpYmVkIGluIGl0cyBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyAtIHRoZSBwcmV2aW91cyBkcmFmdCB0aG91Z2ggZGlkbid0IGRpc2N1 c3MgdGhpcyBhcyBmYXIgYXMgSSByZWNhbGwuPGJyPg0KPGJyPg0KQ2hyaXMgRGVhcmxvdmU6PGJy Pg0K77u/SWYgeW91IGdvIGRvd24gdGhpcyByb3V0ZSBvZiBhc3N1bWluZyB0cmFuc2l0aXZlIHRy dXN0LCB0aGVuIHlvdSBtaWdodCBhcyB3ZWxsIHVzZSA3MTgy4oCZcyBwYWNrZXQgSUNWIGFuZCB0 aW1lc3RhbXAgcmF0aGVyIHRoYW4gbWVzc2FnZSBJQ1YgYW5kIHRpbWVzdGFtcC48YnI+DQombmJz cDs8YnI+DQpUaGVyZSBpcyBhIGNvbXBsaWNhdGlvbiAobW9zdGx5IG9uZSBvZiBwcmVzZW50YXRp b24pIHRoYXQgdGhlIDU0NDQgbXVsdGlwbGV4ZXIgKHJhdGhlciB0aGFuIEFPRFZ2MikgbmVlZHMg dG8gZG8gdGhpcywgYXQgbGVhc3QgZm9yIHBhY2tldHMgY29udGFpbmluZyBBT0RWdjIgbWVzc2Fn ZXMgKGJ1dCBhdCB3aGljaCBwb2ludCwgcHJvYmFibHkgYWxsIDU0NDQgcGFja2V0cykuIFNvIHlv dSBlaXRoZXIsIGRlcGVuZGluZyBvbiB5b3VyIHBvaW50IG9mDQogdmlldywgbmVlZCB0byByZXF1 ZXN0IGl0IHRvIGRvIHRoYXQsIG9yIChhZG1pbmlzdHJhdGl2ZWx5KSBkZWNsaW5lIHRvIG9wZXJh dGUgZXhjZXB0IG92ZXIgYSA1NDQ0IG11bHRpcGxleGVyIHRoYXQgaXMgZG9pbmcgdGhpcy48YnI+ DQombmJzcDs8YnI+DQpUaGUgYWR2YW50YWdlIGlzIG9uZSBvZiBzYXZlZCBzcGFjZSBhbmQgdGlt ZSB3aGVuIHBhY2tldHMgY29udGFpbiBtb3JlIHRoYW4gb25lIG1lc3NhZ2UuIFBsdXMgc2xpZ2h0 bHkgYmV0dGVyIHByb3RlY3Rpb24gKGhvcCBjb3VudCBhbmQgbGltaXQgYXJlIGNvdmVyZWQpIGJ1 dCB3aGljaCBwcm9iYWJseSBkb2VzbuKAmXQgbWF0dGVyIGhlcmUuPGJyPg0KJm5ic3A7PGJyPg0K SWYgbWVzc2FnZXMgYXJlIGNoYW5nZWQvcmVwbGFjZWQgb24gYSBvbmUtdG8tb25lIGJhc2lzIGFz IGZvcndhcmRlZCwgdGhlbiB0aGUgb25seSBzb2x1dGlvbnMgSSBjYW4gc2VlIGFyZSBob3AgYnkg aG9wIHRyYW5zaXRpdmUgdHJ1c3QgKHBhY2tldHMgb3IgbWVzc2FnZXMgcGVyIGhvcCksIG9yIHNv bWV0aGluZyBjb21wbGljYXRlZCBpbnZvbHZpbmcgYWdncmVnYXRpb24gYW5kIGtub3dsZWRnZSBv ZiBjaGFuZ2VzLiBCdXQgdGhlIGxhdHRlciB3b3VsZA0KIGJlIGEgcmVzZWFyY2ggdGFzayB0byBk ZXZlbG9wLCBzbyBsZXTigJlzIG5vdCB0cnkgdGhhdC48YnI+DQo8YnI+DQpKaWF6aSBZaTo8YnI+ DQpJ77u/IGFncmVlIHdpdGggQ2hyaXMgYW5kIFRob21hcyBvbiB0aGVpciBjb25jZXJucyBvbiB0 aGUgaG9wLWJ5LWhvcCBzZWN1cml0eSBpc3N1ZS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KVGhpcyBpcyB2ZXJ5IGRpZmZlcmVudCBmcm9tIGNs YXNzaWNhbCBEViBwcm90b2NvbCwgaW4gd2hpY2ggdGhlIHZlY3RvciBpbmZvcm1hdGlvbiBpcyBk ZXNpZ25lZCB0byBiZSBleGNoYW5nZWQgYmV0d2VlbiBuZWlnaGJvdXJzLjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpJbiBBT0RWdjIsIHRoZSBS UkVRL1JSRVAvUkVSUiBhcmUgdG8gYmUgZm9yd2FyZGVkIHRocm91Z2ggbXVsdGlwbGUgaG9wcy4g QSByb3V0ZXIgY2FuIHNpZ24gYSBtZXNzYWdlIHRoYXQgaXNuJ3QgYWN0dWFsbHkgaW5pdGlhbGlz ZWQgYnkgaXRzZWxmIC0tIHRoaXMgaXMsIGF0IGxlYXN0LCBhZ2FpbnN0IGludHVpdGlvbi48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KVGhpcyBj YW4gYmUgYW4gaXNzdWUgaWYgd2UgaGF2ZSBjb21wcm9taXNlZCByb3V0ZXJzIGluIHRoZSBuZXR3 b3JrLiBPZiBjb3Vyc2UsIGEgY29tcHJvbWlzZWQgcm91dGVyIGlzIGEgcHJvYmxlbSBmb3IgZXZl cnkgcHJvdG9jb2wsIGxpa2UgT0xTUnYyLiBCdXQgaW4gT0xTUnYyLCBhIGNvbXByb21pc2VkIHJv dXRlciBjYW4gb25seSBzcGVhayBvbiBiZWhhbGYgb2YgaXRzZWxmIC0tIGhvd2V2ZXIsIGluIEFP RFZ2MiwgYSBjb21wcm9taXNlZC9taXMtY29uZmlndXJlZA0KIHJvdXRlciBjYW4gcHJldGVuZCB0 byBiZSBhbnkgb3RoZXIgcm91dGVyIChmb3IgZXhhbXBsZSwgZ2VuZXJhdGUgUlJFUSBtZXNzYWdl cyB1c2luZyBhbm90aGVyIGFkZHJlc3MgYXMgT3JpZ0FkZHIpLiZuYnNwOyBUaGUgY29uc2VxdWVu Y2Ugd2lsbCBiZSBtdWNoIG1vcmUgc2VyaW91cyBpZiB0aGF0IGhhcHBlbnMuPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCkFPRFZ2Mjog VGhpcyBpcyBub3QgeWV0IGFkZHJlc3NlZC48YnI+DQo8YnI+DQo5LiBUZXJtaW5vbG9neSAtIGhv c3QsIHJvdXRlcnMsIHJvdXRlciBjbGllbnRzOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpUaG9tYXM6IE15IGxhc3QgcmV2aWV3IHN1 Z2dlc3RlZDo8YnI+DQrigJxUaGlzIGhhcyBiZWVuIGJyb3VnaHQgdXAgb24gdGhlIGxpc3Qgc2V2 ZXJhbCB0aW1lcyBpbiB0aGUgcGFzdCwgd2l0aG91dCBoYXZpbmcgYmVlbiBhZGRyZXNzZWQuPGJy Pg0KVGhlcmUgYXJlIOKAnGhvc3Rz4oCdIGFuZCB0aGVyZSBhcmUg4oCccm91dGVyc+KAnSDigJQg d2hvc2Ugcm9sZXMgYXJlIHdlbGwgZGVmaW5lZC4gTm9kZeKAnSBub3Qgc28gbXVjaCDigJQgd2hp Y2ggaXMgY2xlYXIgZnJvbSBsb29raW5nIGF0IHRoZSBkZWZpbml0aW9uIGhlcmU6IOKAnGVpdGhl ciBBT0RWdjIgcm91dGVycyBvciByb3V0ZXIgY2xpZW50c+KAnSAod2l0aCDigJxyb3V0ZXIgY2xp ZW50c+KAnSBiZWluZyBkZWZpbmVkIGFzIOKAnGFuIEFPRFZ2MiByb3V0ZXIgaXMgYWxzbyBpdHMN CiBvd24gcm91dGVyIGNsaWVudOKAnSkuPGJyPg0KPGJyPg0KVGhpcyBpcyB2ZXJ5IG11Y2ggcmVs YXRlZCB0byB0aGUgdXNlIG9mIOKAnFJvdXRlciBDbGllbnTigJ0sIGFuZCBib3RoIHRoYXQgdGVy bSwgYW5kIOKAnG5vZGXigJ0gaW5kaWNhdGl2ZSB0aGF0IHNvbWUgY2xhcml0eSBpcyBuZWVkZWQg aGVyZS48YnI+DQo8YnI+DQpBbGwgYSByb3V0ZXIgY2FyZXMgYWJvdXQgaXMg4oCcYW4gYWRkcmVz c+KAnS4gSWYgdGhhdCBhZGRyZXNzIGlzIG9mIGEgbmV0d29yaywgb3IgYSByb3V0ZXIsIG9yIGFu IGludGVyZmFjZSAoYW5kLCBpZiBzYWlkIGludGVyZmFjZSBpcyBpbnN0YWxsZWQgaW4gYSByb3V0 ZXIgb3IgYSBob3N0KSBkb2VzbuKAmXQgbWF0dGVyLjxicj4NCjxicj4NClNvLCDigJxhbiBhZGRy ZXNz4oCdIGlzIHNvbWV0aGluZyB0aGF0IHRoZSByb3V0aW5nIHByb3RvY29sIHNob3VsZCBjYXJl IGFib3V0IGZpbmRpbmcgcGF0aHMgdG8uIFdoaWNoIG1lYW5zIHRoYXQgZWFjaCBhZGRyZXNzIHRo YXQgc2hvdWxkIGJlIG1hZGUgcmVhY2hhYmxlIGJ5IHRoZSByb3V0aW5nIHByb3RvY29sIHNob3Vs ZCBiZSBhZHZlcnRpc2VkIGJ5IChhdCBsZWFzdCkgb25lIHJvdXRlciBpbiB0aGUgbmV0d29yay48 YnI+DQo8YnI+DQpPbmUgd2F5IG9mIGRvaW5nIHRoYXQgd291bGQgYmUgdG8gc2ltcGx5IHRhbGsg YWJvdXQg4oCcQXR0YWNoZWQgTmV0d29ya3PigJ0gYXMgaXMgZG9uZSBpbiBSRkM3MTgxLCB3aGVy ZWluIGFuIGFkZHJlc3MgaW5jbHVkZWQgaW4gdGhlIOKAnEF0dGFjaGVkIE5ldHdvcmsgU2V04oCd IGlzIGFkdmVydGlzZWQgYnkgYW4gT0xTUnYyIHJvdXRlci4uLi5pbiB0aGlzIGNhc2UsIHRoZSBl cXVpdmFsZW50IHdvdWxkIGJlIOKAnGZvciBlYWNoIGFkZHJlc3MgaW4gdGhlIEF0dGFjaGVkDQog TmV0d29yayBTZXQgb2YgYW4gQU9EVnYyIHJvdXRlciB0aGUgcm91dGVyIE1VU1QgcmVzcG9uZCBh dXRob3JpdGF0aXZlbHkgdG8gYSBSUkVRLCBhbmQgTVVTVCBtYWludGFpbiB0aGUgY29ycmVzcG9u ZGluZyBzZXF1ZW5jZSBudW1iZXLigJ0uPGJyPg0KVGhlIHRleHQsIGFzIGl0IGN1cnJlbnRseSBp cywgaXMgcmVhbGx5IGhhcmQgdG8gcmVhZCwgYW5kIGEgcmUtZWRpdCBhbG9uZyB0aGVzZSBsaW5l cyB3b3VsZCBnbyBhIGxvbmcgd2F5LuKAnTxicj4NCjxicj4NCkkgbm90ZSB0aGF0IHRoZSB0ZXJt cyDigJxOb2Rl4oCdIGFuZCDigJxSb3V0ZXIgQ2xpZW504oCdIGFyZSBzdGlsbCB1c2VkLCBpbiB0 aGVpciBvcmlnaW5hbCBmb3JtLCBhbmQgdGhhdCBvdGhlciB0aGFuIHNvbWUgc2xpZ2h0IHdvcmRz bWl0aGluZyB0aGlzIGNvbW1lbnQgaGFzIG5vdCBiZWVuIGFkZHJlc3NlZCBpbiB0aGUgZG9jdW1l bnQuPGJyPg0KPGJyPg0KSSByZWl0ZXJhdGUgdGhhdCB0aGUgbmVlZCB0byB1c2Ugcm91dGVyLCBo b3N0LCBub2RlLCBhbmQgcm91dGVyIGNsaWVudCBpbiBhbmQgYnkgaXRzZWxmIHNob3VsZCBiZSBh biBpbmRpY2F0b3IgdGhhdCB0aWdodGVuaW5nIHVwIG9mIHRlcm1pbm9sb2d5IGlzIHJlcXVpcmVk Ljxicj4NCjxicj4NCkFPRFZ2MjogU2VlIDUuIFRoZSB1c2Ugb2Yg4oCcbm9kZeKAnSBoYXMgYmVl biBhZGRyZXNzZWQuPGJyPg0KPGJyPg0KMTAuIFRlcm1pbm9sb2d5IGFuZCBlbHNld2hlcmUgLSBh ZGRyZXNzPGJyPg0KVGhvbWFzOiBJIG1hZGUgdGhlIGZvbGxvd2luZyBjb21tZW50IHRvIFJvdXRh YmxlIFVuaWNhc3QgSVAgQWRkcmVzczo8YnI+DQrigJxBcmUgdGhlcmUgYW55IHRlY2huaWNhbCBy ZWFzb24gd2h5IG5vdCBzaW1wbHkgKmFueSogYWRkcmVzcyBjb3VsZCBiZSBjb25zaWRlcmVkIGJ5 IHRoZSByb3V0aW5nIHByb3RvY29sPzxicj4NCk15IHVuZGVyc3RhbmRpbmcsIGJ1dCBjb3JyZWN0 IG1lIGlmIEkgYW0gd3JvbmcsIGlzIHRoYXQgYWxsIHRoYXQgaXMgcmVxdWlyZWQgaXMgdGhhdCBh bGwgaW50ZXJmYWNlcyBpbiBhIGdpdmVuIEFPRFZ2MiByb3V0aW5nIGRvbWFpbiBoYXMgYW4gdW5p cXVlIGFkZHJlc3MuPGJyPg0KVGhhdCBzb21lIG9mIHRoZXNlIGFkZHJlc3NlcyAoYnkgYW4gSVAg YWRkcmVzc2luZyBhcmNoaXRlY3R1cmUgZG9jdW1lbnQpIGhhcyBzcGVjaWFsIHNlbWFudGljcyBh c3NvY2lhdGVkIChzdWNoIGFzIGFyZSBsaW5rIGxvY2Fscywgb3IgYXJlIGZvciBwcml2YXRlIHVz ZSwgb3IgYXJlIGZvciBleGFtcGxlIHVzZSBvbmx5LCBvciBhcmUgZm9yIG11bHRpY2FzdCkgaXMg b3V0IG9mIHNjb3BlIGhlcmU/PGJyPg0KSSBzZWUgbm90aGluZyBoYXMgY2hhbmdlZCBvbiB0aGUg YWJvdmUsIHNvIGxldCBtZSBiZSBtb3JlIGV4cGxpY2l0OiB0aGUgcm91dGluZyBwcm90b2NvbCBp dHNlbGYgcHJvYmFibHkpIHNob3VsZCBub3QgY2FyZSBhYm91dCB3aGF0IGtpbmQgb2YgYWRkcmVz c2VzIGFyZSBmaWxsZWQgaW50byBpdC4gSXMgYW4gMTkyLjE2Li8xNiBhZGRyZXNzIGFwcHJvcHJp YXRlPyBOb3QgYWNyb3NzIHRoZSBpbnRlcm5ldCwgYnV0IGl0IG1heSBiZSBpbiBzb21lYm9keeKA mXMNCiBwcml2YXRlIGRlcGxveW1lbnRzLiBTaG91bGQgdGhlIHJvdXRpbmcgcHJvdG9jb2wgYmUg 4oCcYWRkcmVzcyBwb2xpY2XigJ0gYW5kIGlzIGltcGxlbWVudGF0aW9uIG9mIGEg4oCcSSByZWZ1 c2UgdG8gcm91dGUgdGhlc2UgYWRkcmVzc2Vz4oCm4oCdIGEgcmVxdWlyZW1lbnQgZm9yIGNsYWlt aW5nIGNvbmZvcm1hbmNlPyBTdWdnZXN0IHNpbXBseSBzdGF0aW5nIHdoYXQgdGhlIHJlcXVpcmVt ZW50cyBhcmUgdW5kZXIgd2hpY2ggdGhlIHJvdXRpbmcgcHJvdG9jb2wgd2lsbA0KIHdvcmsg4oCU IGFuZCBsZWF2ZSDigJxhZGRyZXNzIGFzc2lnbm1lbnQgcG9saXRpY3PigJ0gYXNpZGUuPGJyPg0K PGJyPg0KQU9EVnYyOiBXZSBhc2sgZm9yIGNsYXJpZmljYXRpb24gb24gdGhpcyBpc3N1ZS4gV2Ug dXNlIHRoZSBwaHJhc2Ug4oCccm91dGFibGUgYW5kIHVuaWNhc3TigJ0gaW4gdGhlIGRyYWZ0IHdp dGggcmVzcGVjdCB0byBPcmlnQWRkciBhbmQgVGFyZ0FkZHIuIFdlIGRvbnQgbWVhbiB0byBleGNs dWRlIGFkZHJlc3NlcyBmcm9tIHRoZSBwcml2YXRlIGFkZHJlc3MgcmFuZ2VzLiBCdXQgd2UgZG9u dCB3YW50IHRvIHJlcXVlc3Qgcm91dGVzIGZvciBtdWx0aWNhc3QsDQogaW5kZXRlcm1pbmF0ZSwg bGluay1sb2NhbCwgb3IgbG9vcGJhY2sgYWRkcmVzc2VzLiBUaGlzIGlzIG5vdCBhYm91dCByb3V0 ZXIgaW50ZXJmYWNlIGFkZHJlc3NlcyB3aGljaCBhcmUgdXNlZCBmb3IgQU9EVnYyLjxicj4NCjxi cj4NCjExLiBNdWx0aXBsZSBpbnRlcmZhY2VzIHdpdGggdGhlIHNhbWUgSVAgYWRkcmVzcywgNjYy MSBpbXBsaWNhdGlvbnM8YnI+DQo8YnI+DQpUaG9tYXM6IEkgYWxzbyBjb250aW51ZWQ6PGJyPg0K Tm93LCB3aXRoIHRoYXQgYmVpbmcgc2FpZCBhbHNvLCB0aGUgV0cgd2FudGVkIHRoYXQgUkZDNzE4 MSBzdXBwb3J0cyBub3QganVzdCBtdWx0aXBsZSBpbnRlcmZhY2VzLCBidXQgYWxzbyB0aGUgc2Ft ZSBhZGRyZXNzIHVzZWQgb24gbXVsdGlwbGUgaW50ZXJmYWNlcyBvZiB0aGUgc2FtZSByb3V0ZXIu IFRoZXJlIHdlcmUgZ29vZCByZWFzb25zIGZvciB0aGF0LCBhbmQgd2hpbGUgaXQgd2FzIG5vdCB0 cml2aWFsIHRvIGltcGxlbWVudCwgaXQgdHVybmVkDQogb3V0IHRvIGJlIHRoZSByaWdodCB0aGlu ZyB0byBzdXBwb3J0LiBJZiB0aGVyZSBhcmUgdGVjaG5pY2FsIHJlYXNvbnMgd2h5IHRoaXMgaXMg bm90IHN1cHBvcnRlZCBpbiBBT0RWdjIgKGZvciBleGFtcGxlLCBpZiB0aGlzIGNhbm5vdCBiZSBt YWRlIHdvcmsgYmVjYXVzZSBvZiAmbHQ7cmVhc29uJmd0OykgdGhlbiB0aGF0IHNob3VsZCBiZSBj YWxsZWQgb3V0IGluIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBhbHNvPzxicj4NCkNvbnZl cnNlbHksIGlmIGl0IGlzIHBvc3NpYmxlIGluIEFPRFZ2MiwgdGhlbiBJIGRvIG5vdCBiZWxpZXZl IHRoYXQgaXQgaXMgY2xlYXJseSBzcGVjaWZpZWQgaG93IChhdCBsZWFzdCwgaW4gdGhlIOKAnG5h aXZl4oCdIG9uIHBhcGVyIGV4YW1wbGVzIEkgZHJldyB1cCwgc29tZXRoaW5nIGVuZGVkIHVwIG5v dCB3b3JraW5nKS4gU28gZWl0aGVyIHRoZSBwcm90b2NvbCBhcy1pcyBkb2VzIG5vdCBzdXBwb3J0 IGl0IChidXQgY291bGQgYmUgbWFkZSB0bz8pDQogb3IgaXQgaXMgc3VwcG9ydGVkIChidXQganVz dCBuZWVkIHRvIGJlIHNwZWxsZWQgb3V0KSwgb3IgaXMgbm90IHBvc3NpYmxlIChhbmQgbmVlZCB0 byBiZSBkaXNjbGFpbWVkIGluIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCkuPGJyPg0KU3Rh biBSYXRsaWZmIHdhcyBhIGRyaXZpbmcgZm9yY2UgaW4gaG9sZGluZyB0aGUgV0figJlzIGNvbGxl Y3RpdmUgZmVldCB0byB0aGUgZmlyZSBpbiBnZXR0aW5nIHRoaXMgc3VwcG9ydCBpbmNsdWRlZCBp biBSRkM3MTgxLCBhbmQgd291bGQgbGlrZWx5IGJlIHRoZSByaWdodCBwZXJzb24gdG8gY29uc3Vs dCBvbiB0aGlzIG1hdHRlcj88YnI+DQpJIGFjdHVhbGx5IGhhdmUgbm90IHNlZW4gY2hhbmdlcywg b3IgY29tbWVudHMsIG9uIHRoaXMuIEluIE9MU1J2MiwgdGhlIFdHIHdhcyBtYWtpbmcgaXQgYSBz dHJvbmcgcmVxdWlyZW1lbnQgdGhhdCBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gdXNlIHRoZSBz YW1lIElQIGFkZHJlc3Mgb24gZGlmZmVyZW50IGludGVyZmFjZXMgb2YgYSByb3V0ZXIuIEl0IHdh cyBzb21ld2hhdCB0ZWRpb3VzIHRvIGRlc2lnbiBhcm91bmQsIGJ1dCBpdCB3YXMgd29ya2VkDQog b3V0LCBhbmQgdGhlIGNvbmRpdGlvbnMgdW5kZXIgd2hpY2ggdGhhdCB3YXMgcG9zc2libGUgd2Vy ZSBkZWZpbmVkIGFuZCBkb2N1bWVudGVkLjxicj4NCkkgd291bGQgbGlrZSB0byBzZWUgdGhlIHNh bWUgZG9uZSBmb3IgdGhpcyBwcm90b2NvbC48YnI+DQpJIGFsc28gbm90ZSB0aGF0IHRoaXMgaXMg bm90IHVucmVsYXRlZCB0byBSRkM2NjIxLWRpc2N1c3Npb25zLiBGb3IgZXhhbXBsZSwgd2hlbiBz ZWxlY3RpbmcgUy1NUFJzIG9uIGEgbXVsdGktaW50ZXJmYWNlIGFuZCBtdWx0aS1hZGRyZXNzLXBl ci1pbnRlcmZhY2Ugcm91dGVyLCBjYXJlIG11c3QgYmUgdGFrZW4gbGVhc3QgdGhpbmdzIHdvbuKA mXQgd29yay4gU28sIGlmIChhbmQgdGhpcyBsaW5rcyBiYWNrIHRvIHByZXZpb3VzIG1haWxzKSBS RkM2NjIxDQogaXMgYSByZXF1aXJlbWVudCBvciBkZXNpcmUgZm9yIHRoaXMgcHJvdG9jb2wsIHRo ZW4gdGhlcmUgYXJlIHNvbWUgY29uc2lkZXJhdGlvbnMgcmVxdWlyZWQgaGVyZS48YnI+DQo8YnI+ DQpBT0RWdjI6IFdlIGhhdmUgcmVtb3ZlZCByZWZlcmVuY2VzIHRvIFJGQyA2NjIxLjxicj4NCklu aXRpYWwgdGhvdWdodHMgb24gdGhpcyB0b3BpYyBvZiBtdWx0aXBsZSBpbnRlcmZhY2VzIHVzaW5n IHRoZSBzYW1lIElQIGFkZHJlc3MsIGlzIHRoYXQgdGhpcyB3b3VsZG7igJl0IGNhdXNlIGEgcHJv YmxlbSwgaWYgdGhlIHJvdXRlciBoYXMgb25seSBvbmUgc2VxdWVuY2UgbnVtYmVyLiBIb3dldmVy LCB0aGlzIGlzIHVwIGZvciBmdXJ0aGVyIGRpc2N1c3Npb24uPGJyPg0KPGJyPg0KMTIuIEludGVy ZmFjZXMgY29uZmlndXJlZCBhcyByb3V0ZXIgY2xpZW50czxicj4NCjxicj4NClRob21hczogSSBz ZWUgdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiDigJxSb3V0ZXIgQ2xpZW504oCdIGhhcyBjaGFuZ2Vk IHRvIGJlPGJyPg0K4oCcQW4gYWRkcmVzcyBvciBhZGRyZXNzIHJhbmdl4oCmdGhlIEFPRFZ2MiBy b3V0ZXLigJlzIGludGVyZmFjZSBhZGRyZXNzZXMgYXJlIGFsc28gY29uZmlndXJlZCBhcyByb3V0 ZXIgY2xpZW50c+KAnTxicj4NCkJldHRlciB0aGFuIGJlZm9yZSwgYnV0IHN0aWxsIG1pc3Npbmcg dGhlIHRhcmdldC4gVGhlIHRlcm0g4oCcUm91dGVyIENsaWVudOKAnSBpcywgYXMgSSBpbmRpY2F0 ZWQgbnVtZXJvdXMgdGltZXMgYmVmb3JlLCBvZGQuPGJyPg0KQnV0IHRoZSBzZWNvbmQgcGFydCBv ZiB0aGUgc2VudGVuY2UsIGRvZXMgdGhhdCBtZWFuICh3aGF0IGl0IHNheXMpIHRoYXQgdGhlIGlu dGVyZmFjZXMgbXVzdCBiZSBjb25maWd1cmVkIHNwZWNpYWxseSwgc28gYXMgdG8gYmUgYWJsZSB0 byBiZSDigJxyb3V0ZXIgY2xpZW50c+KAnT8gVGhhdCBjYW7igJl0IGJlIHRydWUuPGJyPg0KV2hh dCB5b3UgbGlrZWx5IG1lYW4gaXM6PGJyPg0KQW4gQU9EVnYyIHJvdXRlciBpcyBjb25maWd1cmVk IHNvIGFzIHRvIGNvbnNpZGVyIGl0cyBvd24gaW50ZXJmYWNlcyBhcyBwYXJ0IG9mIHRoZSBsb2Nh bGx5IGF0dGFjaGVkIG5ldHdvcmsgc2V04oCdID88YnI+DQpZb3UgY29uZmlndXJlIHRoZSByb3V0 ZXIsIHJpZ2h0PyBObyBzcGVjaWFsIOKAnGludGVyZmFjZSBjb25maWd1cmF0aW9uIHByb3BlcnRp ZXPigJ0gYXJlIHJlcXVpcmVkIGZvciBhbiBpbnRlcmZhY2UgdG8gYmUgYW5ub3VuY2FibGUgYnkm bmJzcDsgYW4gQU9EVnYyIHJvdXRlcj8gKEFuZCwgZ2V0dGluZyByaWQgb2Ygbm9kZSB3b3VsZCBh Y3R1YWxseSBtYWtlIHRoZSBkZWZpbml0aW9uIHNob3J0ZXIgYW5kIG5pY2VyKTxicj4NCjxicj4N CkFPRFZ2MjogVGhlIHdvcmRpbmcgd2UgdXNlIHNheXM6ICZxdW90O1RoZSBJUCBBZGRyZXNzZXMg b2YgdGhlIHJvdXRlcidzIGludGVyZmFjZXMgd2lsbCBhcHBlYXIgaW4gdGhlIFJvdXRlciBDbGll bnQgVGFibGUuJnF1b3Q7IGFuZCBpbiB0aGUgVGVybWlub2xvZ3k6ICZxdW90O1RoZSBBT0RWdjIg cm91dGVyJ3MgaW50ZXJmYWNlIGFkZHJlc3NlcyBhcmUgYWxzbyBjb25maWd1cmVkIGFzIFJvdXRl ciBDbGllbnRzLiZxdW90OyBCb3RoIHN0YXRlbWVudHMgc2F5IHRoYXQg4oCYaW50ZXJmYWNlDQog YWRkcmVzc2VzIGFyZSBjb25maWd1cmVkIGFzIHJvdXRlciBjbGllbnRz4oCZIC4uLndlIGFyZSBu b3Qgc3VyZSB3aHkgdGhpcyBpcyBtaXN1bmRlcnN0b29kLiBXZSBoYXZlIGEgcm91dGVyIGNsaWVu dCBsaXN0LCBhbmQgdGhlIEFPRFZ2MiByb3V0ZXLigJlzIGludGVyZmFjZSBhZGRyZXNzZXMgYXJl IGluY2x1ZGVkIGluIHRoaXMgbGlzdC4gVGhlIGludGVyZmFjZSBpdHNlbGYgZG9lc27igJl0IGhh dmUgc3BlY2lhbCDigJxpbnRlcmZhY2UgY29uZmlndXJhdGlvbg0KIHByb3BlcnRpZXPigJ0uPGJy Pg0KPGJyPg0KMTMgLSBtb3JlIG9uIHJvdXRlciBjbGllbnRzPGJyPg0KVGhvbWFzOiBOb3csIHNu aXBwaW5nIG91dCBmcm9tIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudDo8YnI+DQomcXVvdDtN dWx0aS1ob21pbmcgb2YgYW4gSVAgYWRkcmVzcyBpcyBub3Qgc3VwcG9ydGVkIGJ5IEFPRFZ2Miwg YW5kIHRoZXJlZm9yZSBhIFJvdXRlciBDbGllbnQsIGkuZS4gYW4gSVAgQWRkcmVzcywmbmJzcDsg 4oCmICZxdW90Ozxicj4NCuKApmV2aWRlbmNlIHRvIHRoZXJlIGJlaW5nIHNvbWUgcmVkdW5kYW50 IHRlcm1pbm9sb2d5IGhlcmUgdG8gd2VlZCBhd2F5Ljxicj4NCjxicj4NCkFPRFZ2MjogVGhhdCB3 YXMgdGhlcmUgYXMgYSByZW1pbmRlciB0aGF0IGEgcm91dGVyIGNsaWVudCBpcyBiYXNlZCBvbiBJ UCBhZGRyZXNzLCBldmVuIHRob3VnaCB0aGUgZGV2aWNlIHdpdGggdGhhdCBJUCBhZGRyZXNzIG1h eSBoYXZlIG90aGVyIElQIGFkZHJlc3NlcyB0b28uIEl04oCZcyB0aGUgSVAgYWRkcmVzcyB0aGF0 IGlzIHRoZSByb3V0ZXIgY2xpZW50LCBub3QgdGhlIGRldmljZSBhcyBhIHdob2xlIHdpdGggaXRz IGVudGlyZSBjb2xsZWN0aW9uDQogb2YgY29uZmlndXJlZCBJUCBhZGRyZXNzZXMuIE9uZSBJUCBh ZGRyZXNzIG9mIHRoYXQgZGV2aWNlIG1pZ2h0IGJlIGNvbmZpZ3VyZWQgYXMgYSByb3V0ZXIgY2xp ZW50IG9uIG9uZSByb3V0ZXIsIGFuZCBhIGRpZmZlcmVudCBJUCBhZGRyZXNzIG9mIHRoYXQgZGV2 aWNlIGNvdWxkIGJlIGNvbmZpZ3VyZWQgYXMgYSByb3V0ZXIgY2xpZW50IG9uIGFub3RoZXIgcm91 dGVyLiBUaGUgSVAgYWRkcmVzc2VzIHdvdWxkIHNlZW0gdG8gQU9EVnYyIHRvIGJlDQogb24gZGlm ZmVyZW50IGRldmljZXMuPGJyPg0KPGJyPg0KPGJyPg0KMTQuIGRhdGEgZWxlbWVudHM8YnI+DQo8 YnI+DQpUaG9tYXM6IFRoZSBiZWxvdyBpcyBhIGxpdHRsZSBiaXQgb2YgYSBtZXRhLWNvbW1lbnQs IEkgYW0gbm90IHF1aXRlIHN1cmUgd2hhdCBJIHRoaW5rIGhlcmUuIFRoZSBkZWZpbml0aW9ucyBm b3IgVGFyZ2V0IE5vZGUgYW5kIHN1Y2ggd2VyZSBjb25mdXNpbmcgYmVmb3JlLiBUaGV5IHN0aWxs IGFyZSwgc29tZXdoYXQuPGJyPg0KSSB0aGluayB0aGF0IGl0IG1heSBiZSBiZWNhdXNlIHRoZSBk ZWZpbml0aW9ucyBub3cgdXNlZCBhcmUgc2ltcGx5IGNvcHktcGFzdGVkIG91dCBmcm9tIHRoZSB0 YWJsZXMgaW4gdGhlIHByZXZpb3VzIHZlcnNpb24sIGZvciBleGFtcGxlOjxicj4NCiZuYnNwOyZu YnNwOyDigJxBbiBBT0RWdjIgRGF0YSBFbGVtZW50IGNvbnRhaW5pbmcgdGhlIGRlc3RpbmF0aW9u IGFkZHJlc3Mgb2YgdGhlIElQIHBhY2tldCB0cmlnZ2VyaW5nIHJvdXRlIGRpc2NvdmVyeS7igJ08 YnI+DQpPSywgSSBjYW4gdHJhY2UgYmFjayBhbmQgc2VlIHRoYXQgYSBEYXRhIEVsZW1lbnQgaXMg c29tZXRoaW5nIHRoYXQgZXhpc3RzIGluc2lkZSBhIHByb3RvY29sIG1lc3NhZ2UuIFRvIG1lLCBo b3dldmVyLCB0aGF04oCZcyBub3QgcmVhbGx5IGdlbmVyYWwgdGVybWlub2xvZ3kgYXMgc3VjaCwg YnV0IHBhcnQgb2YgdGhlIHNwZWNpZmljYXRpb24gb2YgYSBwYWNrZXQgZm9ybWF0IC0gb3IgcmF0 aGVyLCBpdCBpcyB0aGUgbm90YXRpb24gdGhhdCB5b3UgdXNlDQogd2hlbiBkZXNjcmliaW5nIGFu IGFsZ29yaXRobS4gQnkgdGhlIHdheSwgd2h5IGFyZSBzb21lIG5vdGF0aW9ucyBpbiBDYW1lbENh c2Ugd2hlcmVhcyBvdGhlcnMgaGF2ZSBhIHNwYWNlIGluIHRoZW0sIGUuZy4g4oCcVGFyZ2V0IE5v ZGXigJ0gYW5kIOKAnFRhcmdNZXRyaWPigJ0sIGJvdGggb2Ygd2hpY2ggYXJlIERhdGEgRWxlbWVu dHM/IFdvdWxkIGJlIGdvb2Qgd2l0aCBhIGNvbnNpc3RlbnQgYXBwcm9hY2ggaGVyZS48YnI+DQpJ ICp0aGluayogdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gdGFrZSBhbGwgdGhvc2Ug4oCcRGF0 YSBFbGVtZW504oCdIGJpdHMgYW5kIG1vdmUgdG8gYSBzZXBhcmF0ZSBzZWN0aW9uIChvciBzdWJz ZWN0aW9uKSB0byB0aGUgdGVybWlub2xvZ3ksIGFuZCB0aGVuIGtlZXAgYWxsIHRoZSDigJxvdGhl ciBzdHVmZuKAnSAoTmVpZ2hib3IsIOKApikgaW4gaXRzIG93biBzZWN0aW9uLjxicj4NCjxicj4N CkFPRFZ2MjogWW91ciBjb21tZW50IGZyb20gZHJhZnQgMTEgd2hlcmUgd2UgYWxyZWFkeSBoYWQg ZGF0YSBlbGVtZW50cyBpbiBhIHNlcGFyYXRlIHRhYmxlLCBzYXlzOjxicj4NCiZxdW90O0Fsc28g c3VnZ2VzdCBhYm9saXNoaW5nIHRoaXMgdGFibGUgYW5kIGZvbGRpbmcgdGhlIGRlZmluaXRpb25z IGluIHdpdGggdGhlIG90aGVyIGRlZmluaXRpb25zIGluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9u LiZxdW90Ozxicj4NCldlIGhhdmUgdXBkYXRlZCB0byBub3QgcmVmZXIgc28gaGVhdmlseSB0byB0 aGUgdGVybSBEYXRhIEVsZW1lbnQuIEFsbCB0aGUgdGVybXMgYXJlIGRlc2NyaWJlZCBpbiB0aGUg VGVybWlub2xvZ3kgc2VjdGlvbi4gVGhvc2UgaW4gQ2FtZWxDYXNlIGFyZSB1c2VkIGFzIG1lc3Nh Z2UgZmllbGRzLjxicj4NCjxicj4NCjxicj4NCjE1LiBSb3V0ZSDigJx0byBhIHNwZWNpZmljIGFk ZHJlc3PigJ08YnI+DQpUaG9tYXM6PGJyPg0KSSBtYWRlIGEgY29tbWVudDogU2Vjb25kLCBzaG91 bGQg4oCcdmFsaWQgcm91dGXigJ0gbm90IGJlIHF1YWxpZmllZCBieSDigJx0byBhIHNwZWNpZmlj IGFkZHJlc3PigJ0/4oCdPGJyPg0KV2hpY2ggd2FzIG5vdCBhZGRyZXNzZWQuPGJyPg0KPGJyPg0K QU9EVnYyOiBFdmVyeSByb3V0ZSBpcyB0byBhIHNwZWNpZmljIGFkZHJlc3MuLi50aGUgYWRkcmVz cyBpcyBzcGVjaWZpZWQgYnkgUm91dGUuQWRkcmVzcyBhbmQgUm91dGUuUHJlZml4TGVuZ3RoLjxi cj4NCkRvIHlvdSBtZWFuIHRoYXQgcm91dGVzIGFyZSB0byB0aGUgYWRkcmVzcyBUYXJnQWRkciBv ciBPcmlnQWRkciBhbmQgdGhlcmVmb3JlIHRvIGEgc3BlY2lmaWMgaG9zdCBhZGRyZXNzIHJhdGhl ciB0aGFuIHRvIGEgbmV0d29yayBwcmVmaXg/IFRoaXMgaXMgbm90IHRoZSBjYXNlLiBQcmVmaXgg TGVuZ3RoIGlzIGluY2x1ZGVkIGluIEFPRFZ2MiBtZXNzYWdlcyBzbyB0aGF0IHRoZSByb3V0ZSBs ZWFybmVkIGZyb20gdGhlIG1lc3NhZ2UgcmVwcmVzZW50cw0KIHRoZSBwcmVmaXggd2hpY2ggT3Jp Z0FkZHIgb3IgVGFyZ0FkZHIgcmVzaWRlcyBvbiAoaWYgdGhlIHJvdXRlciBjbGllbnQgZW50cnkg Y29ycmVzcG9uZGluZyB0byBPcmlnQWRkciBhdCBSUkVRX0dlbiBvciBUYXJnQWRkciBhdCBSUkVQ X0dlbiBpcyBjb25maWd1cmVkIHdpdGggYSBwcmVmaXggbGVuZ3RoKS4gZS5nLiBPcmlnQWRkciBp cyAxMC4wLjAuMSBidXQgdGhlIGNvcnJlc3BvbmRpbmcgcm91dGVyIGNsaWVudCBlbnRyeSBhdCBS UkVRX0dlbg0KIGNvdWxkIGJlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly8xMC4wLjAuMC84Ij48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj4xMC4wLjAuMC84PC9zcGFuPjwvYT4uIFNvIHdoZW4gY29uc3RydWN0aW5nIHRoZSBS UkVRIHlvdSBpbmNsdWRlIGEgcHJlZml4IGxlbmd0aCBvZiA4LCBhbmQgd2hlbiByZWNlaXZpbmcg dGhlIFJSRVEgYW5kIGxlYXJuaW5nIHRoZSByb3V0ZSB0byBPcmlnQWRkciwNCiB5b3UgY2FuIGlu c3RhbGwgYSByb3V0ZSB0bzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJodHRwOi8vMTAuMC4wLjAvOCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+MTAuMC4wLjAvODwvc3Bhbj48L2E+LiZuYnNwOyBUZXh0IGhhcyBiZWVuIHVwZGF0ZWQg dG8gbWFrZSB0aGlzIG1vcmUgb2J2aW91cy48YnI+DQo8YnI+DQoxNi4gdW5yZWFjaGFibGUgYWRk cmVzczxicj4NCjxicj4NClRob21hczogSSBhbHNvIG1hZGUgYSBjb21tZW50IG9uICZxdW90O1Vu cmVhY2hhYmxlIEFkZHJlc3PigJ0gLSBJIGFtIGdsYWQgSSBkaWQsIGJlY2F1c2UgSSBhcHBhcmVu dGx5IGhhZCBhIGRpZmZlcmVudCB1bmRlcnN0YW5kaW5nIHRoYW4gd2hhdCB3YXMgaW50ZW5kZWQu IEkgbm93IHNlZSB0aGF0IGFuIFVucmVhY2hhYmxlIEFkZHJlc3MgYnkgZGVmaW5pdGlvbiBpcyBh biBhZGRyZXNzIGxpc3RlZCBpbiBhIFJFUlIgbWVzc2FnZSwgYW5kIG5vdCB0aGUgc2FtZQ0KIGFz IGFuIGFkZHJlc3MgdG8gd2hpY2ggbm8gcm91dGUgaGFzIHlldCZuYnNwOyBiZWVuIGRpc2NvdmVy ZWQ/IElmIHllcywgdGhlbiBwbGVhc2UgdXNlIGEgZGlmZmVyZW50IHRlcm0sIHN1Y2ggYXMgRm9y bWVybHlSZWFjaGFibGVBZGRyZXNz4oCdIG9yIHNvbWV0aGluZyBvZiB0aGUgc29ydD88YnI+DQo8 YnI+DQpBT0RWdjI6ICZxdW90O0Zvcm1lcmx5IHJlYWNoYWJsZSZxdW90OyBpcyBpbmFjY3VyYXRl Li4uIHdlIHNlbmQgYSBSRVJSIGlmIGFub3RoZXIgcm91dGVyIGZvcndhcmRzIGEgcGFja2V0IHZp YSB1cywgYW5kIHdlIGRvbnQgaGF2ZSBhIHJvdXRlLCBub3QganVzdCB3aGVuIHdlIGxvc2UgYSBy b3V0ZS4gV2UgbWlnaHQgbmV2ZXIgaGF2ZSBoYWQgYSByb3V0ZSwgb3IgbWlnaHQgbmV2ZXIgaGF2 ZSBoYWQgYSB2YWxpZCByb3V0ZSwgc28gdGhlIGFkZHJlc3MgbWF5IG5vdA0KIGhhdmUgYmVlbiAm cXVvdDtmb3JtZXJseSByZWFjaGFibGUmcXVvdDsuIEFsc28sIEkgdGhpbmsgJnF1b3Q7Rm9ybWVy bHlSZWFjaGFibGVBZGRyZXNzJnF1b3Q7IGlzIGEgcmVhbGx5IHVnbHkgdGVybS4gVW5yZWFjaGFi bGUgbWVhbnMgJnF1b3Q7d2UgZG9u4oCZdCBoYXZlIGEgcm91dGUgYW5kIHdlIGFyZW7igJl0IGdv aW5nIHRvIHJlcXVlc3Qgb25lJnF1b3Q7IG9yICZxdW90O3dlIGxvc3QgdGhpcyByb3V0ZSZxdW90 OyAoZGVwZW5kaW5nIG9uIHdoeSB0aGUgUkVSUiBpcyBiZWluZyBzZW50KS4gSXQgZG9lc27igJl0 IG1lYW4NCiAmcXVvdDt3ZSBkaWRu4oCZdCByZXF1ZXN0IG9uZSB5ZXQmcXVvdDssIGFuZCBpdCB3 b3VsZCBiZSB3cm9uZyB0byBjbGFzcyBhbiBhZGRyZXNzIGFzIHVucmVhY2hhYmxlIGJlY2F1c2Ug d2UgaGFkbuKAmXQgcmVxdWVzdGVkIGEgcm91dGUgZm9yIGl0IHlldCwgdGhhdCBpcywgYXNzdW1p bmcgaXTigJlzIGNvbmZpZ3VyZWQgYXMgYSByb3V0ZXIgY2xpZW50LjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpJZiBhIGJldHRlciB0 ZXJtIGlzIHN1Z2dlc3RlZCB3ZSBjb3VsZCBjb25zaWRlciBjaGFuZ2luZyBidXQgYXQgdGhlIG1v bWVudCB3ZSBoYXZlIGtlcHQg4oCcVW5yZWFjaGFibGUgQWRkcmVzc+KAnS48YnI+DQo8YnI+DQo8 YnI+DQoxNy4gQXBwbGljYWJpbGl0eSAtIG11bHRpcGxlIGludGVyZmFjZXMgc2FtZSBhZGRyZXNz LCA2NjIxIGFnYWluPGJyPg0KPGJyPg0KVGhvbWFzOiBBcHBsaWNhYmlsaXR5IHN0YXRlbWVudDog Rmlyc3QsIEkgd291bGQgbGlrZSB0byByZWNvZ25pemUgdGhlIGVmZm9ydHMgbWFkZSB0byBpbXBy b3ZlIHRoaXMgc2luY2UgbGFzdCByZXZpZXcuIFRoYW5rczxicj4NClNlY29uZCwgdGhlIGRvY3Vt ZW50IHN0YXRlczogJnF1b3Q7QU9EVnYyIHN1cHBvcnRzIHJvdXRlcnMgd2l0aCBtdWx0aXBsZSBp bnRlcmZhY2VzLCBhcyBsb25nIGFzIGVhY2ggaW50ZXJmYWNlIGNvbmZpZ3VyZWQgZm9yIEFPRFZ2 MiBoYXMgYSB1bmljYXN0IElQIGFkZHJlc3MuJm5ic3A7IEEgcm91dGVyIG1heSB1c2UgdGhlIHNh bWUgSVAgYWRkcmVzcyBvbiBtdWx0aXBsZSBpbnRlcmZhY2VzLiZuYnNwOyBBZGRyZXNzIGFzc2ln bm1lbnQgcHJvY2VkdXJlcyBhcmUgb3V0IG9mDQogc2NvcGUgZm9yIEFPRFZ2Mi7igJ08YnI+DQpJ cyB0aGF0IHRydWU/IEdyYW50ZWQsIEkgaGF2ZSBub3Qgd29ya2VkIHRoaXMgdGhyb3VnaCBpbiBk ZXRhaWwsIGJ1dCBJIGNhbiBwcmVzZW50IGEgY291bnRlci1leGFtcGxlOiB0aGUgdXNlIG9mIFJG QzY2MjEgbWVhbnMgdGhhdCB0aGVyZSBjZXJ0YWlubHkgYXJlIHNvbWUgY29uc3RyYWludHMgdGhh dCBtdXN0IGJlIHJlc3BlY3RlZCBsZWFzdCB2YXJpb3VzIGZsb29kaW5nIG9wdGltaXphdGlvbnMg bWF5IG5vdCB3b3JrLjxicj4NClNlY29uZGx5LCBpZiB0aGUgbXVsdGlwbGUtaW50ZXJmYWNlcy13 aXRoLXNhbWUtYWRkcmVzcyBhcmUgb24gdGhlIHNhbWUgTDIsIGFuZCB0aGlzIGlzIHdoYXQgSSBo YXZlIG5vdCB3b3JrZWQgdGhyb3VnaCwgYXJlIHRoZXJlIGFueSBzaXR1YXRpb25zIHRoYXQgd2ls bCBub3Qgd29yaz88YnI+DQpUaGUgaW1tZWRpYXRlbHkgcHJldmlvdXMgdmVyc2lvbiBvZiB0aGlz IHNwZWNpZmljYXRpb24gcmVhZDo8YnI+DQomcXVvdDtBT0RWdjIgc3VwcG9ydHMgcm91dGVycyB3 aXRoIG11bHRpcGxlIGludGVyZmFjZXMsIGFzIGxvbmcgYXMgZWFjaCBpbnRlcmZhY2UgY29uZmln dXJlZCBmb3IgQU9EVnYyIGhhcyBpdHMgb3duIHVuaWNhc3Qgcm91dGFibGUgSVAgYWRkcmVzcyZx dW90Ozxicj4NClNvIHdoYXQgY2hhbmdlZCB0aGF0IG1lYW5zIHRoYXQgZWFjaCBpbnRlcmZhY2Ug bm8gbG9uZ2VyIG5lZWRzIGl0cyAqb3duKiB1bmljYXN0IGFkZHJlc3M/PGJyPg0KPGJyPg0KQU9E VnYyOiBXZWxsLCBiYXNlZCBvbiBwcmV2aW91cyBxdWVzdGlvbnMgb24gdGhpcywgd2UgdGFsa2Vk IGl0IHRocm91Z2ggYW5kIGRlY2lkZWQgdGhlcmUgc2hvdWxkbuKAmXQgYmUgYW4gaXNzdWUgaWYg ZGlmZmVyZW50IGludGVyZmFjZXMgb2YgYSByb3V0ZXIgdXNlZCB0aGUgc2FtZSBJUCBhZGRyZXNz LiBOb3RlIHRoYXQgd2UgY2hhbmdlZCBBT0RWdjIgc28gdGhhdCB0aGVyZSBpcyBvbmUgc2VxdWVu Y2UgbnVtYmVyIHBlciByb3V0ZXIuIE5vIGxvbmdlcg0KIGNhbiBhIHJvdXRlciB1c2UgZGlmZmVy ZW50IHNlcXVlbmNlIG51bWJlcnMgb24gZGlmZmVyZW50IGludGVyZmFjZXMuIElmIGFuIFJSRVEg d2VudCBvdXQgb2YgdHdvIGludGVyZmFjZXMgdXNpbmcgdGhlIHNhbWUgYWRkcmVzcywgd2Ugd29y a2VkIGl0IHRocm91Z2ggYW5kIGRlY2lkZWQgdGhlIHJlcXVlc3Qgd291bGQgYmUgcHJvY2Vzc2Vk IGNvcnJlY3RseS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyPg0KQWxzbywgdGV4dCByZWZlcnJpbmcgdG8gUkZDIDY2MjEgaGFzIGJlZW4gcmVtb3Zl ZC48YnI+DQo8YnI+DQoxOC4gQXBwbGljYWJpbGl0eSBhbmQgYXBwZW5kaXggLSBtdWx0aWhvbWlu Zzxicj4NCjxicj4NClRob21hczogSSBwb2ludGVkIG91dCB0byB0aGUgQXBwbGljYWJpbGl0eSBT dGF0ZW1lbnQ6PGJyPg0KSSB0aGluayB0aGF0IGFwcGVuZGl4IEIgbmVlZHMgdG8gYmUgcmVtb3Zl ZC4gRXNzZW50aWFsbHksIGl0IG1ha2VzIGNsYWltcyB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIGRv IG11bHRpLWhvbWluZyDigJQgYnV0IG5laXRoZXIgc3BlY2lmaWVzIGhvdyBpdCBpcyBkb25lLCBu b3IgZ2l2ZXMgcG9pbnRlcnMgdG8gZG9jdW1lbnRzIHRoYXQganVzdGlmeSB0aGUgY2xhaW0uPGJy Pg0KQU9EVnYyIGRvZXMgbm90IHN1cHBvcnQgbXVsdGktaG9taW5nIOKAlCB0aGF04oCZcyBjbGVh ciwgYW5kIGl0IGlzIGZpbmUgdGhhdCBpdCBpcyBjYWxsZWQgb3V0IGhlcmUuIFRoYW5rIHlvdSBm b3IgdGhhdC48YnI+DQpOb3csIHdpdGggdGhhdCBiZWluZyBzYWlkLCBJIGFtIHRvcm4gYmV0d2Vl biBiZWluZyBzYXRpc2ZpZWQgdGhhdCBpdCBpcyBjYWxsZWQgb3V0IG9uIG9uZSBoYW5kLCBhbmQg d2FudGluZyB0byBoYXZlIOKAnG11bHRpIGhvbWluZ+KAnSBvbiB0aGUgb3RoZXIgaGFuZC4gUkZD NzE4MSBzdXBwb3J0cyBtdWx0aS1ob21pbmcsIEZXSVcuPGJyPg0KSSBiZWxpZXZlIHRoYXQgdGhp cyBhbHNvIHdvdWxkIG1lcml0IHNvbWUgZXhwbGljaXQgZGlzY3Vzc2lvbiBieSB0aGUgV0csIGlu IG9yZGVyIHRvIHVuZGVyc3RhbmQgaWYgdGhpcyBkZXNpZ24gZGVjaXNpb24gaXMgYWNjZXB0YWJs ZT88YnI+DQpJIHNlZSB0aGF0IEFwcGVuZGl4IEIgc3RpbGwgaXMgaW4gdGhlIGRvY3VtZW50LCBh bmQgSSBkbyBub3QgcmVjYWxsIGhhdmluZyBzZWVuIHRoaXMgZGlzY3Vzc2VkIG9uIHRoZSBtYWls aW5nIGxpc3QuIFNpbXBseSByZW1vdmluZyB0aGUgcmVmZXJlbmNlIGZyb20gdGhlIEFwcGxpY2Fi aWxpdHkgU3RhdGVtZW50IHRvIEFwcGVuZGl4IEIgZG9lcyBub3QgYWRkcmVzcyB0aGUgaXNzdWUg dGhhdCBJIHJhaXNlZCBpbiBteSBwcmV2aW91cyByZXZpZXcuPGJyPg0KPGJyPg0KQU9EVnYyOiBB cHBlbmRpeCBoYXMgYmVlbiByZW1vdmVkIGFuZCBtYXkgYXBwZWFyIGluIGEgZnV0dXJlIGluZm9y bWF0aW9uYWwgZG9jdW1lbnQuPGJyPg0KPGJyPg0KMTkuIGludGVyZmFjZXMgbGlzdCAtIHVzZSBv ZiDigJxTSE9VTETigJ08YnI+DQo8YnI+DQpUaG9tYXM6IFRvIDQuMSwgSSBtYWRlIHRoZSBmb2xs b3dpbmcgY29tbWVudDo8YnI+DQomcXVvdDtJcyB0aGlzIGEgc2hvdWxkLCBvciBhIFNIT1VMRD8g SWYgdGhlIGxhdHRlciwgc2hvdWxkIGl0IGJlIGEgTVVTVD88YnI+DQpJbiBnZW5lcmFsLCB0aGVy ZSBhcmUgYSBsb3Qgb2Ygc3VjaCDigJxtYXliZSBub3JtYXRpdmUgbGFuZ3VhZ2XigJ0gdGhyb3Vn aCB0aGUgZG9jdW1lbnQsIGFuZCBJIHdvdWxkIG11Y2ggbGlrZSB0byBzZWUgYW4gZWRpdG9yaWFs IHBhc3Mg4oCUIGVzc2VudGlhbGx5IGFsbCBtYXkvc2hvdWxkLyBtdXN0IGFuZCBmcmllbmRzIGNh cmVmdWxseSBldmFsdWF0ZWQgYXMgaWYgdGhleSBzaG91bGQgYmVjb21lIDIxMTktdGVybXMsIGFu ZCAuLi4gbW9yZSBpbXBvcnRhbnRseQ0KIChpdCBoYXMgYmVlbiBjYWxsZWQgb3V0IGJlZm9yZSwg ZndpdykgcXVpdGUgYSBiaXQgb2Ygc2hvdWxkL1NIT1VMRCB3aGljaCBvdWdodCB0byBiZSB0cmFu c2Zvcm1lZCBpbnRvIE1VU1QuPGJyPg0KR2VuZXJhbGx5LCBhaW1pbmcgZm9yIGEgdmVyeSBhIGxv dyBudW1iZXIgb2YgU0hPVUxEIGlzIGEgZ29vZCBkZXNpZ24gbWV0cmljIGZvciBhIGRvY3VtZW50 4oCdPGJyPg0KQXNpZGUgZnJvbSB0aGUgZ2VuZXJhbCBjb21tZW50IG9uIDIxMTktbGFuZ3VhZ2Us IHdoeSBpcyB0aGlzIGEgU0hPVUxEPzxicj4NCjxicj4NCkFPRFZ2MjogV2UgY2hhbmdlZCB0aGlz IGluc3RhbmNlIHRvIGEgTVVTVCBhbmQgd2lsbCBiZSBjaGVja2luZyBmb3Ig4oCcbWF5YmUgbm9y bWF0aXZlIGxhbmd1YWdl4oCdLjxicj4NCjxicj4NCjxicj4NCjIwLiBSb3V0ZXIgY2xpZW50IC0g TG9jYWwgQXR0YWNoZWQgTmV0d29yayBTZXQ8YnI+DQo8YnI+DQpUaG9tYXM6IFRvIDQuMiwgSSBt YWRlIHRoZSBmb2xsb3dpbmcgY29tbWVudDo8YnI+DQpBcyBpbmRpY2F0ZWQgZWFybGllciwgSSBi ZWxpZXZlIHRoYXQgdGhlIHRlcm0g4oCcUm91dGVyIENsaWVudOKAnSBpcyBpbGwgY2hvc2VuLiBJ IGJlbGlldmUgdGhhdCBpdCBpcyBtb3JlIGFwcHJvcHJpYXRlbHkgYW4g4oCcQXR0YWNoZWQgTmV0 d29yayBTZXTigJ0gc2luY2Ug4oCUIGFzIGluZGljYXRlZCBwcmV2aW91c2x5IOKAlCB0aGUgdGVy bSDigJxSb3V0ZXIgQ2xpZW504oCdIGlzIGFtYmlndW91cy4gSSBhbSBwbGVhc2VkIHRvIHNlZSwg dGhvdWdoLCB0aGF0IHRoaXMg4oCcUm91dGVyDQogQ2xpZW50IExpc3TigJ0gaW4gcmVhbGl0eSBp cyBhbiDigJxBdHRhY2hlZCBOZXR3b3JrIFNldOKAnSBhbmQgc28gdGhhdCBjaGFuZ2Ugc2hvdWxk IGJlIChyZWxhdGl2ZWx5KSBlYXN5Ljxicj4NClRoZSBhYm92ZSBjb21tZW50IHN0aWxsIGlzIGFw cGxpY2FibGUgdG8gdGhpcyByZXZpc2lvbiw8YnI+DQo8YnI+DQpBT0RWdjI6IFNlZSA1LDksMTIs MTMuPGJyPg0KPGJyPg0KPGJyPg0KMjEuIFN1Ym5ldDxicj4NClRob21hczogVG8gNC4yLCBJIG1h ZGUgdGhlIGZvbGxvd2luZyBjb21tZW50Ojxicj4NCkFsc28sIEkgcmVjb21tZW5kIHRvIG5vdCBz YXkg4oCcc3VibmV04oCdIOKAlCBob3cgYWJvdXQgcmVwaHJhc2luZyB0byDigJxJZiBhIHByZWZp eCBpcyBpbmNsdWRlZCBpbiB0aGUgYXR0YWNoZWQgbmV0d29yayBzZXQgb2YgYW4gQU9EVnYyIHJv dXRlciwgdGhlbiB0aGF0IEFPRFZ2MiByb3V0ZXIgTVVTVCBwcm92aWRlIGNvbm5lY3Rpdml0eSBm b3IsIGkuZS4gYW5zd2VyIHRvIFJSRVFzIGFuZCBtYWludGFpbiBzZXF1ZW5jZSBudW1iZXJzIGZv ciwgYWxsIGFkZHJlc3Nlcw0KIGZyb20gd2l0aGluIHRoYXQgcHJlZml4LuKAnTxicj4NCkkgbm90 ZSB0aGF0IHdoaWxlIHRoZSB0ZXJtIGhhcyBiZWVuIHJlbW92ZWQgZnJvbSBzZWN0aW9uIDQsIHRo ZXJl4oCZcmUgNCBsaW5nZXJpbmcgaW5zdGFuY2VzIG9mIHRoaXMgdGVybSBpbiB0aGUgZG9jdW1l bnQsIHRoYXQgY291bGQgZWFzaWx5IGJlIHJlbW92ZWQuPGJyPg0KPGJyPg0KQU9EVnYyOiBBbGwg bWVudGlvbnMgb2YgJnF1b3Q7c3VibmV0JnF1b3Q7IHdlcmUgaW4gdGhlIEVOQVIgc2VjdGlvbi4g VGhleSBoYXZlIGJlZW4gdXBkYXRlZCB0byBzYXkgbmV0d29yaywgb3IgJnF1b3Q7bmV0d29ya3Mg YXR0YWNoZWQgdG8gdGhlIHJvdXRlcnMmcXVvdDs8YnI+DQo8YnI+DQo8YnI+DQoyMi4gcmVsb2Nh dGluZyByb3V0ZXIgY2xpZW50PGJyPg0KPGJyPg0KVGhvbWFzOiBJIEFsc28gbWFkZSBhIGNvbW1l bnQgYWJvdXQgQXBwZW5kaXggQiBpbiBteSBwcmV2aW91cyByZXZpZXcsIHdoaWNoIGlzIHJlZmVy ZW5jZWQgaGVyZS4gVGhhdCBjb21tZW50IHN0aWxsIGFwcGxpZXMuPGJyPg0KPGJyPg0KQU9EVnYy OiBNb3ZlZCBpbnRvIG1haW4gZHJhZnQuPGJyPg0KPGJyPg0KPGJyPg0KMjMuIE5laWdoYm9yIE1v bml0b3Jpbmc8YnI+DQo8YnI+DQpUaG9tYXM6IFRvIFNlY3Rpb24gNC4zLCBJIG5vdGljZWQ6PGJy Pg0KRG9lcyBzZWN0aW9uIDYuMiBkZXNjcmliZSBob3cgdG8gbW9uaXRvciBhbiBlc3RhYmxpc2hl ZCBhZGphY2VuY3kgb25seSwgb3IgaG93IHRvIGRpc2NvdmVyIG5laWdoYm91cmluZyBBT0RWdjIg cm91dGVycz8gTG9va2luZyBpbiA2LjIsIEkgc2VlPGJyPg0K4oCcTm90IGV2ZXJ5IHBhaXIgb2Yg bmVpZ2hib3Jpbmcgcm91dGVycyB3aWxsIG5lY2Vzc2FyaWx5IGZvcm0gYW4gYWRqYWNlbmN5LOKA nSDigJQgc28gaXQgbGlrZWx5IGlzbuKAmXQgNi4yIHRoYXQgdGVsbHMgbWUgaG93IHRvIG1haW50 YWluIHRoaXMgdGFibGU/PGJyPg0KSW4gc2hvcnQsIOKAnEEgbmVpZ2hib3VyIHRhYmxlIE1VU1Qg YmUgbWFpbnRhaW5lZOKAnSDigJQgd2hlcmUgY2FuIEkgZmluZCBpbmZvcm1hdGlvbiBvbiBob3cg dG8gZG8gdGhpcz88YnI+DQpTZWN0aW9uIDYuMiBzdGF0ZXM6PGJyPg0K4oCcVGhlIGRlZmF1bHQg YXBwcm9hY2ggZm9yIG1vbml0b3JpbmcgYmlkaXJlY3Rpb25hbCBjb25uZWN0aXZpdHkgdG8gdGhl IG5leHQgaG9wIHRvd2FyZCBPcmlnQWRkciBpcyB0byByZXF1ZXN0IGFja25vd2xlZGdlbWVudCBv ZiBSb3V0ZSBSZXBseSBtZXNzYWdlcy7igJ08YnI+DQpUaGF0IGNlcnRhaW5seSB3aWxsIHRlbGwg bWUgaWYgYSBsaW5rIG92ZXIgd2hpY2ggYW4gUlJFUCBpcyBzZW50IGlzIGJpLWRpcmVjdGlvbmFs LCBidXQgd2lsbCBub3QgbWFpbnRhaW4gYSDigJxuZWlnaGJvciB0YWJsZeKAnS48YnI+DQpTbyBo b3cgaXMgdGhpcyBkb25lPyBPciwgaXMgdGhlIOKAnE5laWdoYm9yIFRhYmxl4oCdIG5vdCBzdXBw b3NlZCB0byBjb250YWluIHRoZSBjb21wbGV0ZSBzZXQgb2YgbmVpZ2hib3Vycz8gV2hhdCBpbmZv cm1hdGlvbiDigJwuLi5NVVNUIGJlIG1haW50YWluZWTigJ0gdGhlbiwgaW4gdGhpcyB0YWJsZT88 YnI+DQpUaGlzIGlzIHZlcnkgdW5jbGVhciwgSSB3b3VsZCBub3Qga25vdyBob3cgdG8gaW1wbGVt ZW50IGEgbWVjaGFuaXNtIHRoYXQgcG9wdWxhdGVzIHRoaXMg4oCcTmVpZ2hib3IgVGFibGXigJ0g d2l0aCB0aGUgbmVlZGVkIGluZm9ybWF0aW9uIGhlcmUuPGJyPg0KSSBzZWUgbm8gKHJlbGV2YW50 KSBjaGFuZ2VzIHRvIDYuMiBub3IgdG8gNC4zIHNvIEkgYXNzdW1lIHRoYXQgdGhpcyBjb21tZW50 IGhhcyBub3QgYmVlbiBhZGRyZXNzZWQ8YnI+DQo8YnI+DQpBT0RWdjI6IEEgbmV3IHNlY3Rpb24g d2FzIGFkZGVkIHRvIHNob3cgaG93IHRvIHVwZGF0ZSB0aGUgbmVpZ2hib3VyIHRhYmxlLiBUaGVy ZSBoYXZlIGFsc28gYmVlbiB1cGRhdGVzIHRvIHRoaXMgZW50aXJlIHNlY3Rpb24gc2luY2UgdmVy c2lvbiAxMi48YnI+DQo8YnI+DQoyNC4gJm5ic3A7Jm5ic3A7Jm5ic3A7IHBzZXVkby1jb2RlPGJy Pg0KPGJyPg0KVGhvbWFzOjxicj4NCkkgYW0gdGhyb3dpbmcgdGhpcyBpbiBoZXJlLCBhcyBJIGFt IHN1cmUgdGhhdCBJIGNvbW1lbnRlZCBvbiB0aGF0IGluIHRoZSBwcmV2aW91cyByZXZpZXcsIGJ1 dCBJIGRvIG5vdCBzZWUgdGhhdCBhZGRyZXNzZWQ6IGlzIEFwcGVuZGl4IEMgbm9ybWF0aXZlLCBv ciBub3Q/IEl0IHJlcHJlc2VudHMg4oCcIGEgc2Vjb25kIHNwZWNpZmljYXRpb24gb2YgdGhlIHBy b3RvY29sLCBpbiBhIGRpZmZlcmVudCBsYW5ndWFnZeKAnSBmcm9tIHRoZSBtYWluIHBhcnQgb2YN CiB0aGUgc3BlY2lmaWNhdGlvbi4gSSBoYXZlIG5vdCB3YWxrZWQgdGhyb3VnaCBhbmQgbWFkZSAy MDAlIHN1cmUgdGhhdCBib3RoIGFyZSBwZXJmZWN0bHkgYWxpZ25lZCBhbmQgdGhhdCB0aGVyZSBh cmUgbm8gYW1iaWd1aXRpZXMsIGJ1dCBoYXZpbmcgdHdvIGRpZmZlcmVudCBzcGVjaWZpY2F0aW9u cyBvZiBhIHByb3RvY29sIGlzIGEgcmVjaXBlIGZvciBkaXNhc3Rlci4mbmJzcDsgUGxlYXNlIGVp dGhlciBtYWtlIDIwMDAlIHN1cmUgdGhhdCB0aGV5IGFyZQ0KIHNwZWNpZnlpbmcgdGhlIHNhbWUg dGhpbmcgd2l0aG91dCBhbWJpZ3VpdGllcywgb3IgcmVtb3ZlIG9uZS48YnI+DQo8YnI+DQpBT0RW djI6IFJlbW92ZWQgLSBtYXliZSB0byBpbmNsdWRlIGluIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1l bnQgaW4gZnV0dXJlLjxicj4NCjxicj4NCjxicj4NCjI1LiBzZXFudW0gYXMgMTYgYml0IHVuc2ln bmVkIGludGVnZXI8YnI+DQo8YnI+DQpUaG9tYXM6IFRvIHNlY3Rpb24gNC40LCBJIHdyb3RlOjxi cj4NCiZxdW90O3dvdWxkIGxpa2UgdG8gbml0LXBpY2sgdGhhdDogdGhlIHJvdXRlciBjYW4gbWFp bnRhaW4gdGhpcyBzZXF1ZW5jZSBudW1iZXIgaW4gd2hhdGV2ZXIgZm9ybWF0IGl0IHBsZWFzZXMg 4oCUIGJ1dCwgd2hlbiBpdCBpbmNsdWRlcyBpdCBpbiBjb250cm9sIG1lc3NhZ2VzLCBpdCBtdXN0 IGJlIHJlcHJlc2VudGFibGUgaW4gYSBzcGVjaWZpZWQgZm9ybWF0LCByZXNwZWN0aW5nIGNlcnRh aW4gcnVsZXMu4oCdPGJyPg0KSSBzZWUgdGhhdCB0aGVyZSB3ZXJlIG5vIGNoYW5nZXMgZm9sbG93 aW5nIHRoaXMgY29tbWVudC48YnI+DQo8YnI+DQpBT0RWdjI6IFdoeSBzdG9yZSBpdCBhcyBhbnl0 aGluZyBvdGhlciB0aGFuIHdoYXQgaXQgbmVlZHMgdG8gYmUgd2hlbiBpdCBnb2VzIGludG8gYSBt ZXNzYWdlPyBIb3dldmVyLCB3ZSBub3cgc3RhdGUgJnF1b3Q7TVVTVCByZXBvcnQgaXRzIG93biBz ZXF1ZW5jZSBudW1iZXIgYXMgYSAxNiBiaXQuLi4ud2hlbmV2ZXIgaXQgY3JlYXRlcyBhIFJSRVEg b3IgUlJFUCBtZXNzYWdlJnF1b3Q7Ljxicj4NCjxicj4NCjxicj4NCjI2LiBtdWx0aXBsZSBzZXFu dW1zPzxicj4NCjxicj4NClRob21hczo8YnI+DQpUbyBzZWN0aW9uIDQuNCBJIGFza2VkIGZvciBj bGFyaWZpY2F0aW9uIGFzIHRvIGlmIHNlcXVlbmNlIG51bWJlcnMgd2VyZSBwZXIgaW50ZXJmYWNl IG9yIHBlciByb3V0ZXIsIGFzIHRoZSBzcGVjaWZpY2F0aW9uIHdhcyB1bmNsZWFyIG9uIHRoYXQu IFRoZSB3b3JkcyBoYXMgY2hhbmdlZCwgYnV0IGl0IHN0aWxsIGlzIHVuY2xlYXI6IGhvdyBtYW55 IHNlcXVlbmNlIG51bWJlcnMgZG9lcyBhIHJvdXRlciBtYWludGFpbj8gT25lPyBPbmUgcGVyIGlu dGVyZmFjZT88YnI+DQo8YnI+DQpBT0RWdjI6IFdlIHRyaWVkIHRvIHN0YXJ0IGRpc2N1c3Npb24g b24gdGhhdCBwb2ludCwgYW5kIGluIHRoZSBtZWFudGltZSB3ZSByZXZlcnRlZCB0byBoYXZpbmcg MSBzZXFudW0gcGVyIHJvdXRlci4gV2UgdGhpbmsgdGhlIHRleHQgaXMgY2xlYXIuLi4gd2UgcmVm ZXIgdG8gJnF1b3Q7dGhlIHJvdXRlcnMgc2VxdWVuY2UgbnVtYmVyJnF1b3Q7IG9yICZxdW90O2l0 cyBzZXF1ZW5jZSBudW1iZXImcXVvdDsgLSBuZXZlciBoaW50aW5nIHRoYXQgdGhlcmUgY291bGQg YmUgbXVsdGlwbGUNCiBzZXFudW1zIHBlciByb3V0ZXIgKGFzIGZhciBhcyBJJ20gYXdhcmUpLjxi cj4NCjxicj4NCjxicj4NCjI3LiBzZXRzL2xpc3RzL3RhYmxlczxicj4NCjxicj4NClRob21hczo8 YnI+DQpJbiBteSBwcmV2aW91cyByZXZpZXcsIEkgZXhwcmVzc2VkIHRoYXQgaXQgd291bGQgYmUg cHJlZmVyZW50aWFsIHRvIHVzZSDigJxhIG5vdGF0aW9uIG9mIFNldHPigJ0gcmF0aGVyIHRoYW4g dGFibGVzLiBJIHNlZSB0aGF0IHRoaXMgaGFzIG5vdCBjaGFuZ2VkLjxicj4NCjxicj4NCkFPRFZ2 MjogWW91IHByZWZlcnJlZCBzZXRzIHJhdGhlciB0aGFuIGxpc3RzIGluIHlvdXIgcHJldmlvdXMg cmV2aWV3Li4uYW5kIGV4cGxhaW5lZCBvdXIgcmVhc29uaW5nIGZvciB0aGlzIGluIHJlc3BvbnNl cyB0byB0aGUgTUFORVQgbGlzdCwgYW5kIHdlIGRpZCBub3QgcmVjZWl2ZSBmdXJ0aGVyIGNvbW1l bnRzLjxicj4NCjxicj4NCjxicj4NCjI4LiB1c2Ugb2Yg4oCcbm9kZeKAnTxicj4NCjxicj4NClRo b21hczo8YnI+DQpJIG1hZGUgYSBjb21tZW50IG9uIG5vZGUgYW5kIGFkZHJlc3MsIGxldCBtZSBw aWNrIHRoaXMgdXAgYWdhaW4uIFRoZSBmb2xsb3dpbmc6PGJyPg0KUnRlTXNnLk9yaWdBZGRyPGJy Pg0KQW4gSVAgYWRkcmVzcyBvZiB0aGUgbm9kZSB3aGljaCByZXF1aXJlcyB0aGUgcm91dGUsIGku ZS4sIHRoZSBzb3VyY2UgYWRkcmVzcyBvZiB0aGUgSVAgcGFja2V0IHRyaWdnZXJpbmcgdGhlIHJv dXRlIHJlcXVlc3QuPGJyPg0Kd291bGQgYmUgbW9yZSBjb21wYWN0IGFuZCBjbGVhciBpZiBnZXR0 aW5nIHJpZCBvZiB0aGUgdGVybSDigJxub2Rl4oCdIGFuZCBzYWlkOjxicj4NClJ0ZU1zZy5Pcmln QWRkcjxicj4NClRoZSBzb3VyY2UgYWRkcmVzcyBvZiB0aGUgSVAgcGFja2V0IHRyaWdnZXJpbmcg dGhlIHJvdXRlIHJlcXVlc3QuPGJyPg0KPGJyPg0KQU9EVnYyOiBDaGFuZ2UgbWFkZSBhcyBzdWdn ZXN0ZWQuPGJyPg0KPGJyPg0KMjkuIHJvdXRlIHRhYmxlL3JpYi9yb3V0aW5nIHNldDxicj4NCjxi cj4NClRob21hczogVG8gc2VjdGlvbiA0LjYsIGFuZCBJIChhbmQgb3RoZXJzKSBoYXZlIGNvbW1l bnRlZCBvbiB0aGlzIGJlZm9yZTo8YnI+DQpBbGwgQU9EVnYyIHJvdXRlcnMgTVVTVCBtYWludGFp biBhIHJvdXRlIHRhYmxlLiZuYnNwOyBUaGUgcm91dGUgdGFibGUgZW50cnkgaXMgYSBjb25jZXB0 dWFsIGRhdGEgc3RydWN0dXJlLiZuYnNwOyBJbXBsZW1lbnRhdGlvbnMgTUFZIHVzZSBhbnkgaW50 ZXJuYWwgcmVwcmVzZW50YXRpb24gYnV0IE1VU1QgY29udGFpbiB0aGUgZm9sbG93aW5nIGluZm9y bWF0aW9uOjxicj4NCkluIG9yZGVyIHRvIGF2b2lkIGNvbmZ1c2lvbiwgcmVuYW1lIHRoaXMgdG8g 4oCcUm91dGluZyBJbmZvcm1hdGlvbiBCYXNl4oCdIG9yIOKAnFJvdXRpbmcgU2V04oCdIOKAlCBh IFJvdXRpbmcgVGFibGUgaXMgYW4gb3BlcmF0aW5nIHN5c3RlbSBjb25zdHJ1Y3QsIHdoZXJlb24g b3BlcmF0aW9ucyBkaXJlY3RseSBpbmZsdWVuY2UgcGFja2V0IGZvcndhcmRpbmcuIFdoYXQgeW91 IGFyZSBkZWZpbmluZyBoZXJlIGlzIGEgUklCL2FuIFJTLjxicj4NCjxicj4NCkFPRFZ2MjogRG9u ZSBpbiB2ZXJzaW9uIDEzLjxicj4NCjxicj4NCjxicj4NCjMwLiBycmVxIGZvciBwcmVmaXgsIHVz ZSBvZiDigJxpcCBhZGRyZXNz4oCdIGFuZCDigJxhZGRyZXNzJnF1b3Q7PGJyPg0KPGJyPg0KVGhv bWFzOjxicj4NClRoZSBjb25mdXNpb24gdGhhdCBJIHBvaW50ZWQgb3V0IGluIG15IHByZXZpb3Vz IHJldmlldyBvbiDigJxJUCBhZGRyZXNz4oCdIGFuZCDigJxBZGRyZXNz4oCdIGJlaW5nIHVzZWQg YSBiaXQgaGFwaGF6YXJkbHkgcGVyc2lzdHMsIGZ3aXcuIEl0IG1ha2VzIG1lIHRoaW5rLCBjYW4g YSByb3V0ZXIgc2VuZCBhbiBSUkVRIGZvciBhIHByZWZpeD88YnI+DQo8YnI+DQpBT0RWdjI6IFNl ZSBhbHNvICMxNS4gUlJFUV9HZW4gY2FuIGluY2x1ZGUgdGhlIHByZWZpeCBhc3NvY2lhdGVkIHdp dGggT3JpZ0FkZHIgYnkgYWRkaW5nIGEgcHJlZml4IGxlbmd0aCB0byB0aGUgbWVzc2FnZSwgdGhl IHByZWZpeCBsZW5ndGggYXNzb2NpYXRlZCB3aXRoIHRoZSByb3V0ZXIgY2xpZW50IGVudHJ5IGNv cnJlc3BvbmRpbmcgdG8gT3JpZ0FkZHIuIFNvIGFsbCByb3V0ZXJzIHdoaWNoIHJlY2VpdmUgaXQg Y2FuIGxlYXJuIGEgcm91dGUgdG8NCiB0aGUgcHJlZml4IG9uIHdoaWNoIE9yaWdBZGRyIHJlc2lk ZXMuIEJ1dCBmb3IgVGFyZ0FkZHIuLi4gdGhlIFJSRVEgb25seSBoYXMgb25lIHRhcmdldCBJUCBh ZGRyZXNzIC0gdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCByZXF1aXJp bmcgdGhlIHJvdXRlLi4uIHNvIHdoYXQgcHJlZml4IGxlbmd0aCB3b3VsZCBpdCB1c2U/IFRoZSBS UkVRIHJlcXVlc3RzIGEgcm91dGUgdG8gYSBzaW5nbGUgSVAgYWRkcmVzcy4gSG93ZXZlciwNCiB3 aGVuIHRoZSBSUkVQIGlzIGNyZWF0ZWQsIFJSRVBfR2VuIHNob3VsZCBpbmNsdWRlIHRoZSBwcmVm aXggbGVuZ3RoIGFzc29jaWF0ZWQgd2l0aCB0aGUgcm91dGVyIGNsaWVudCBlbnRyeSBmb3IgVGFy Z0FkZHIuIFNvIGFsbCByb3V0ZXJzIHdoaWNoIHJlY2VpdmUgdGhpcyBSUkVQIGxlYXJuIGEgcm91 dGUgdG8gdGhlIHByZWZpeCBUYXJnQWRkciBpcyBwYXJ0IG9mIChpZiB0aGUgcm91dGVyIGNsaWVu dCBlbnRyeSBpcyBjb25maWd1cmVkIHdpdGgNCiBhIHByZWZpeCBsZW5ndGgpLiBUaGUgdGV4dCBo YXMgYmVlbiB1cGRhdGVkIHRvIG1ha2UgdGhpcyBtb3JlIG9idmlvdXMuPGJyPg0KPGJyPg0KPGJy Pg0KMzEuIG5leHQgaG9wIGlwIGFkZHJlc3Mgd29yZGluZzxicj4NCjxicj4NClRob21hczo8YnI+ DQpJIGFsc28gY2FsbGVkIHRoaXMgb3V0IGluIG15IHByZXZpb3VzIHJldmlldyBhcyBpbmNvcnJl Y3QsIGFuZCBkZXNwaXRlIHdvcmRzbWl0aGluZyBpdCBzdGlsbCBpczo8YnI+DQo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm91dGUuTmV4dEhvcDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgc291cmNlIElQIGFkZHJlc3Mgb2YgdGhlIG1lc3Nh Z2UgYWR2ZXJ0aXNpbmcgdGhlIHJvdXRlIHRvPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJv dXRlLkFkZHJlc3MsIGkuZS4gYW4gSVAgYWRkcmVzcyBvZiB0aGUgQU9EVnYyIHJvdXRlciB1c2Vk IGZvcjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgbmV4dCBob3Agb24gdGhlIHBhdGgg dG93YXJkIFJvdXRlLkFkZHJlc3MuPGJyPg0KPGJyPg0KSWYgdGhhdCDigJxtZXNzYWdl4oCdIGlz IGFuIFJGQzU0NDQgZW50aXR5LCB0aGVuIGl0IGRvZXMgdG8gaGF2ZSBhIOKAnHNvdXJjZSBJUCBB ZGRyZXNz4oCdIOKAlCB0aGUgZW5jYXBzdWxhdGluZyBJUCBkYXRhZ3JhbSBjb250YWluaW5nIHRo ZSBwYWNrZXQgY29udGFpbmluZyB0aGUgbWVzc2FnZSBkb2VzLiBBbmQgdGhlIG1lc3NhZ2UgTUFZ IGhhdmUgYW4gT3JpZ2luYXRvciBBZGRyZXNzPGJyPg0KPGJyPg0KQU9EVnYyOiBVcGRhdGVkIHRv IHNheSDigJx0aGUgc291cmNlIElQIGFkZHJlc3Mgb2YgdGhlIElQIHBhY2tldCBjb250YWluaW5n IHRoZSBtZXNzYWdlIGFkdmVydGlzaW5nLi4u4oCdPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRv IHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUg aXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPg0KWW91IHNob3Vs ZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxi cj4NCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPg0KKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKio8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPm1hbmV0IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJtYWlsdG86bWFuZXRA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1hbmV0QGlldGYub3JnPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldDwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 YmFja2dyb3VuZDp3aGl0ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPHNwYW4g c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPm1hbmV0IG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8 c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYu b3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWFuZXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PC9z cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2C5CGLKXM0002VGREEN_-- From nobody Tue May 3 07:43:02 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D82212D84D for ; Tue, 3 May 2016 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAKVCh3ZwVjK for ; Tue, 3 May 2016 07:42:59 -0700 (PDT) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC69B12D82A for ; Tue, 3 May 2016 07:42:56 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,572,1454976000"; d="scan'208,217"; a="34617965" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 03 May 2016 15:42:56 +0100 X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208,217";a="116495142" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 03 May 2016 15:42:55 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Tue, 3 May 2016 15:42:52 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: AODVv2 Thread-Index: AdGlRJcnXW1kj6Q5Q5qvnbUSlv3IZA== Date: Tue, 3 May 2016 14:42:51 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2C7DGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: [manet] AODVv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:43:02 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2C7DGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Note: I haven't been able to do a proper read of this draft. At best I'm go= ing to be able to take a look at a few key issues to check that they match = up with what's below. But confirming it is the best scenario, I'm not going= to say better than this. Fortunately at least two people (Ulrich and Jiazi) have, plus some other co= mments. And the status on some matters has been discussed on list. I think that AODVv2 could make it to Experimental status. But not to the qu= ality I think it should be in the impossibly short timescale to even review= it properly, let alone update it. I wouldn't like to try to estimate the t= ime required, but it's not just days. That's based on that there have been significant changes that haven't been = discussed, fed back into document, reviewed, and that there are significant= issues that are still in flux - directionality of metrics, mutability of m= essages and associated security to name two. Ulrich and Jiazi have raised m= ultiple points, and a few, plus the volume of the rest (even if not all acc= epted) makes for real time required. Under normal circumstances I'd say, making progress, not yet at Experimenta= l state, but that's within the foreseeable future. Just not the timescale o= n offer. Fortunately for me, I don't have to decide what the consequences of that as= sessment - combined with those of other people, who may put the bar higher = or lower, or just see things differently - are. I can see several possibili= ties, but I don't think my speculation would help. -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2C7DGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Note: I haven’t been able to do a proper read = of this draft. At best I’m going to be able to take a look at a few k= ey issues to check that they match up with what’s below. But confirmi= ng it is the best scenario, I’m not going to say better than this.

 

Fortunately at least two people (Ulrich and Jiazi) h= ave, plus some other comments. And the status on some matters has been disc= ussed on list.

 

I think that AODVv2 could make it to Experimental st= atus. But not to the quality I think it should be in the impossibly short t= imescale to even review it properly, let alone update it. I wouldn’t = like to try to estimate the time required, but it’s not just days.

 

That’s based on that there have been significa= nt changes that haven’t been discussed, fed back into document, revie= wed, and that there are significant issues that are still in flux - directi= onality of metrics, mutability of messages and associated security to name two. Ulrich and Jiazi have raised multiple poi= nts, and a few, plus the volume of the rest (even if not all accepted) make= s for real time required.

 

Under normal circumstances I’d say, making pro= gress, not yet at Experimental state, but that’s within the foreseeab= le future. Just not the timescale on offer.

 

Fortunately for me, I don’t have to decide wha= t the consequences of that assessment - combined with those of other people= , who may put the bar higher or lower, or just see things differently - are= . I can see several possibilities, but I don’t think my speculation would help.

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________= ________________________________________________

T:  +44 (0)1245 24= 2194  |  E: chris.dearlove@baesystems.com

BAE Systems Appli= ed Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Esse= x CM2 8HN.
www.= baesystems.com/ai

B= AE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guil= dford, Surrey, GU2 7YP

 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2C7DGLKXM0002VGREEN_-- From nobody Tue May 3 08:40:17 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E937D12D956 for ; Tue, 3 May 2016 08:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baP98-9QPFuo for ; Tue, 3 May 2016 08:40:13 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F012D973 for ; Tue, 3 May 2016 08:40:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KyvYoiIg7JZRu/W7o4CPHuU9LRxHudrMLpf9p5zYfH+sxPMAlem83kXVVH+tiBWZ; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.67]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1axcQF-0006Ka-AJ; Tue, 03 May 2016 11:39:39 -0400 To: "Dearlove, Christopher (UK)" , Jiazi YI , manet References: <0e7fb67e-2711-9912-7e97-e2a54d0bf8ed@earthlink.net> From: Charlie Perkins Message-ID: <351b6e17-e4a0-c497-2336-2f4ba75877c8@earthlink.net> Date: Tue, 3 May 2016 08:39:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7e8bf4ccd2e86bafc372e0717ac526bff350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [manet] draft-ietf-manet-aodvv2-15 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:40:16 -0000 Hello Chris, Yes, you are right. I was misunderstanding what Jiazi said, thinking "metric value" when he meant "metric type". Regards, Charlie P. On 5/3/2016 1:55 AM, Dearlove, Christopher (UK) wrote: > Just one comment for now. > > Jiazi: >> It's OK, but maybe some rules must be specified and followed. For example, the metric used must be the same: if a packet is forwarded using metric A at router X, and then metric B at router Y, it's a obvious source of loops. > Charlie: >> I don't think this is possible for monotonically increasing metrics. > Simple case, A, B, C all connected. Metrics are symmetric. For metric X: AB=3, AC=BC=1. For metric Y: BC=3, AB=AC=1. > > Packet source A, destination B. A uses metric X. It sees the best route as A-C-B and forwards to C. However C is using metric Y, and sees the best route as C-A-B and forwards to A. Loop. > > That I think is what Jiazi is meaning. Of course the metrics don't have to be the same in that, for example, if when accumulating the route metric A -B-C if A-B is a delay metric and B-C is a reliability metric, adding them together makes no sense and won't produce great routes, but won't loop. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Tue May 3 08:52:42 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C0012D565 for ; Tue, 3 May 2016 08:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Luw1vwdlPiH6 for ; Tue, 3 May 2016 08:52:39 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD8112D9A0 for ; Tue, 3 May 2016 08:52:39 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.67]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1axccj-0007rY-Ib for manet@ietf.org; Tue, 03 May 2016 11:52:33 -0400 References: <20160503145248.8264.43392.idtracker@ietfa.amsl.com> To: Mobile Ad Hoc Networks mailing list From: "Charles E. Perkins" Organization: Blue Skies X-Forwarded-Message-Id: <20160503145248.8264.43392.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 3 May 2016 08:52:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160503145248.8264.43392.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------F6D6A5F74E98AF7C3EBE740A" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac759c868f6d7a4b47d9354c00e1b8aa9c7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: [manet] Fwd: New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:52:41 -0000 This is a multi-part message in MIME format. --------------F6D6A5F74E98AF7C3EBE740A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello folks, According to my understanding of RFC 7182, it seems pretty much straightforward to do the proper end-to-end authentication for RREQ/RREP using a new new type extension. Please have a look to see whether there is any additional specification required in order to request allocation of the new type extension. I kept the RFC 4868 section as another alternative just in case the RFC 7182 specification turns out to be more difficult than my current understanding. If it is suitable, the specification for the new type extension in this draft would probably fit very comfortably with the AODVv2 draft, or it could go forward separately. Comments will be appreciated. Regards, Charlie P. -------- Forwarded Message -------- Subject: New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt Date: Tue, 03 May 2016 07:52:48 -0700 From: internet-drafts@ietf.org To: Charles E. Perkins A new version of I-D, draft-perkins-manet-aodv-e2esec-01.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-perkins-manet-aodv-e2esec Revision: 01 Title: Endpoint Message Authentication for AODV Route Messages Document date: 2016-05-03 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-perkins-manet-aodv-e2esec-01.txt Status: https://datatracker.ietf.org/doc/draft-perkins-manet-aodv-e2esec/ Htmlized: https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-perkins-manet-aodv-e2esec-01 Abstract: This document specifies a new type extension to enable RFC 7182 authentication mechanism to be used for authenticating AODVv2 route messages. The document also specifies a new message TLV for AODVv2 and, potentially, other reactive protocols. Both mechanisms allow the endpoints of a newly discovered route to be assured that they were the originator of the RREQ and responder producing the RREP respectively. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------F6D6A5F74E98AF7C3EBE740A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Hello folks,

According to my understanding of RFC 7182, it seems pretty much straightforward to do the proper end-to-end authentication for RREQ/RREP using a new new type extension.  Please have a look to see whether there is any additional specification required in order to request allocation of the new type extension.

I kept the RFC 4868 section as another alternative just in case the RFC 7182 specification turns out to be more difficult than my current understanding.

If it is suitable, the specification for the new type extension in this draft would probably fit very comfortably with the AODVv2 draft, or it could go forward separately.

Comments will be appreciated.

Regards,
Charlie P.




-------- Forwarded Message --------
Subject: New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt
Date: Tue, 03 May 2016 07:52:48 -0700
From: internet-drafts@ietf.org
To: Charles E. Perkins <charliep@computer.org> 


A new version of I-D, draft-perkins-manet-aodv-e2esec-01.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Name:		draft-perkins-manet-aodv-e2esec
Revision:	01
Title:		Endpoint Message Authentication for AODV Route Messages
Document date:	2016-05-03
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/internet-drafts/draft-perkins-manet-aodv-e2esec-01.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-manet-aodv-e2esec/
Htmlized:       https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-perkins-manet-aodv-e2esec-01

Abstract:
   This document specifies a new type extension to enable RFC 7182
   authentication mechanism to be used for authenticating AODVv2 route
   messages.  The document also specifies a new message TLV for AODVv2
   and, potentially, other reactive protocols.  Both mechanisms allow
   the endpoints of a newly discovered route to be assured that they
   were the originator of the RREQ and responder producing the RREP
   respectively.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------F6D6A5F74E98AF7C3EBE740A-- From nobody Tue May 3 09:06:57 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8447912D55A for ; Tue, 3 May 2016 09:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Phb12ksE1cmp for ; Tue, 3 May 2016 09:06:53 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 13DFC12D9C4 for ; Tue, 3 May 2016 09:06:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=eI3i6stE7KRYzhj3AoPxIZq1MprsStXu/AFrdTSNeCclfukqDCFj5bDHcbMavQYs; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.67]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1axcqQ-0005b5-HT; Tue, 03 May 2016 12:06:42 -0400 To: Jiazi YI References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org> <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org> <60BD2E9C-64D7-4444-B3A9-8D207EB4A86F@gmail.com> <144C7397-F19E-4FB0-959A-B5A030BD7A8A@fu-berlin.de> <883f2cf1-ffc7-9910-d80b-e3b610353273@earthlink.net> From: Charlie Perkins Message-ID: Date: Tue, 3 May 2016 09:06:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7b9e664ead5de227537de7b27e635a7bb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] On Forwarding-and-regeneration X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 16:06:55 -0000 Hello Jiazi, Follow-up below... On 4/28/2016 5:14 AM, Jiazi YI wrote: > I think it will make the specification complex, and hard to extend. > > What about if I need to define a new TLV field for my extension? The > field would either be unprotected, or the extension won't be > interoperable with old implementations. RFC 7182 has the following language: > The rationale for removing any ICV Message TLVs already present prior > to calculating the ICV is that several ICV TLVs may be added to the > same message, e.g., using different ICV cryptographic and/or hash > functions. So you could use another ICV for the new purpose, and handling for previous ICVs is already specified. I don't think it's necessary to discourage mutable fields in reactive route discovery. There have been many variations on AODV route discovery, and I can't think of any that didn't change the control messages as they were passed hop by hop from source to destination and back. Regards, Charlie P. From nobody Tue May 3 09:07:15 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BA112D9D3 for ; Tue, 3 May 2016 09:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.905 X-Spam-Level: X-Spam-Status: No, score=-7.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_Ebpmv0bxoQ for ; Tue, 3 May 2016 09:07:11 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C1512D9D8 for ; Tue, 3 May 2016 09:07:06 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,573,1454976000"; d="scan'208,217"; a="66418116" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 03 May 2016 17:07:02 +0100 X-IronPort-AV: E=Sophos;i="5.24,573,1454976000"; d="scan'208,217";a="116513624" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 03 May 2016 17:07:02 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Tue, 3 May 2016 17:07:02 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "Mobile Ad Hoc Networks mailing list" Thread-Topic: [manet] Fwd: New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt Thread-Index: AQHRpVPmqApiikjTM0GmTK2Ozji/wJ+nXloA Date: Tue, 3 May 2016 16:07:01 +0000 Message-ID: References: <20160503145248.8264.43392.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2CC7GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Fwd: New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 16:07:14 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2CC7GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSB0aGluayB0aGlzIGlzIHRoZSB3cm9uZyBhcHByb2FjaCwgdG8gY3JlYXRlIGEgc3BlY2lhbGlz ZWQgc3RydWN0dXJlIGNvbnRhaW5pbmcganVzdCB3aGF0IHlvdSBrbm93IHlvdSBjdXJyZW50bHkg d2FudCBpbiBBT0RWdjIgYW5kIHByb3RlY3QgdGhhdCwgYXMgYSB0eXBlIGV4dGVuc2lvbiB0byBh IGdlbmVyYWwgcHVycG9zZSBUTFYuIEFuZCBhbiBhcHByb2FjaCB0aGF0IGRvZXNu4oCZdCBnZW5l cmFsaXNlIHRvIGFueSBwb3NzaWJsZSBBT0RWdjIgZXh0ZW5zaW9ucy4gT2YgY291cnNlIGFzIGFu IGV4cGVyaW1lbnRhbCBub24tYWxsb2NhdGlvbiB0aGF0IGhhbmRsZXMgdGhlIGZvcm1lciBwb2lu dCwgYnV0IG5vdCB0aGUgbGF0dGVyLg0KDQpJIHRoaW5rIHRoZSBkaXNjdXNzaW9ucyB0aGF0IGhh dmUgdGFrZW4gcGxhY2Ugb24gd2hhdCBvbmUgbWlnaHQgY2FsbCBhIHN1YnRyYWN0aXZlIGFwcHJv YWNoIGlzIG1vcmUgYXBwcm9wcmlhdGUsIGNvdmVyaW5nIGV2ZXJ5dGhpbmcgKHBsdXMgcG9zc2li bHkgYWRkcmVzcyhlcykpIGV4Y2VwdCBleHBsaWNpdGx5IGV4Y2x1ZGVkIHBhcnRzIG9mIHRoZSBt ZXNzYWdlLiBBbmQgdHJ5aW5nIGhhcmQgdG8gbWFrZSB0aG9zZSBwYXJ0cyBhYnNvbHV0ZWx5IG1p bmltYWwsIGlkZWFsbHkganVzdCBvbmUgYmxvY2sgb2YgZGF0YSB0aGF0IGNhcnJpZXMgb25lIChv ciBwb3NzaWJseSB0d28gaWYgYXN5bW1ldHJpYykgbWV0cmljIHZhbHVlcy4gQmVjYXVzZSBhcyBJ IHVuZGVyc3RhbmQgaXQgb25lIGJsb2NrIG1ha2VzIHNvbWUgZnV0dXJlIGNvbmNlcHRzIHN1Y2gg YXMgYWdncmVnYXRpb24gbW9yZSBwcmFjdGljYWwsIGJ1dCBpbiB0aGUgbWVhbndoaWxlIGlzIGp1 c3Qgb25lIGJsb2NrIHRvIHplcm8gb3V0LCB3aXRoIG1pbmltYWwgaW5mb3JtYXRpb24uDQoNClRo YXQgZG9lcyByZXF1aXJlIHNlcGFyYXRpbmcgb3V0IFJSRVAtQUNLcywgd2hpY2ggbWF5IGJlIGEg Z29vZCBpZGVhIGFueXdheS4NCg0KSeKAmWQgc3Ryb25nbHkgc3VnZ2VzdCBpZiBnb2luZyBkb3du IHRoaXMgcm91dGUgKGEpIGRlc2lnbmluZyBpdCBjYXJlZnVsbHksIChiKSBzcGVjaWZ5aW5nIGJ5 IHBvc2l0aW9uLCAoYykgb25seSBwZXJtaXR0aW5nIHRoZSBleGNsdXNpb24gKG9yIGVhY2ggZXhj bHVzaW9uIGlmIG1vcmUgdGhhbiBvbmUgaXMgbmVlZGVkIC0gdGhvdWdoIGF2b2lkaW5nIHRoYXQg aXMgYW5vdGhlciBzdHJvbmcgc3VnZ2VzdGlvbikgdG8gYmUgYWxsIG9yIHBhcnQgb2YgYSBzaW5n bGUgbWVzc2FnZSBUTFYgdmFsdWUuDQoNClRoaXMsIGluY2x1ZGluZyAoYSksIGlzIG9mIGNvdXJz ZSBhIHJlYXNvbiBmb3IgbXkgbGFzdCBwb3N0aW5nLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxv dmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxs aWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1 IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlz LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9y ZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5 c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0K UmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9m ZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoN CkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IENoYXJsZXMgRS4gUGVya2lucw0KU2VudDogMDMgTWF5IDIwMTYgMTY6NTINClRvOiBNb2JpbGUg QWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdA0KU3ViamVjdDogW21hbmV0XSBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0w MS50eHQNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20g b3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVy IG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQg Y2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBp bmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3Ig aW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFl c3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUy MEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNl IGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBT dXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQoqKiogV0FSTklORyAqKioNCkVYVEVSTkFMIEVNQUlM IC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9u Lg0KDQoNCg0KDQpIZWxsbyBmb2xrcywNCg0KQWNjb3JkaW5nIHRvIG15IHVuZGVyc3RhbmRpbmcg b2YgUkZDIDcxODIsIGl0IHNlZW1zIHByZXR0eSBtdWNoIHN0cmFpZ2h0Zm9yd2FyZCB0byBkbyB0 aGUgcHJvcGVyIGVuZC10by1lbmQgYXV0aGVudGljYXRpb24gZm9yIFJSRVEvUlJFUCB1c2luZyBh IG5ldyBuZXcgdHlwZSBleHRlbnNpb24uICBQbGVhc2UgaGF2ZSBhIGxvb2sgdG8gc2VlIHdoZXRo ZXIgdGhlcmUgaXMgYW55IGFkZGl0aW9uYWwgc3BlY2lmaWNhdGlvbiByZXF1aXJlZCBpbiBvcmRl ciB0byByZXF1ZXN0IGFsbG9jYXRpb24gb2YgdGhlIG5ldyB0eXBlIGV4dGVuc2lvbi4NCg0KSSBr ZXB0IHRoZSBSRkMgNDg2OCBzZWN0aW9uIGFzIGFub3RoZXIgYWx0ZXJuYXRpdmUganVzdCBpbiBj YXNlIHRoZSBSRkMgNzE4MiBzcGVjaWZpY2F0aW9uIHR1cm5zIG91dCB0byBiZSBtb3JlIGRpZmZp Y3VsdCB0aGFuIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZy4NCg0KSWYgaXQgaXMgc3VpdGFibGUs IHRoZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgbmV3IHR5cGUgZXh0ZW5zaW9uIGluIHRoaXMgZHJh ZnQgd291bGQgcHJvYmFibHkgZml0IHZlcnkgY29tZm9ydGFibHkgd2l0aCB0aGUgQU9EVnYyIGRy YWZ0LCBvciBpdCBjb3VsZCBnbyBmb3J3YXJkIHNlcGFyYXRlbHkuDQoNCkNvbW1lbnRzIHdpbGwg YmUgYXBwcmVjaWF0ZWQuDQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCg0KDQoNCi0tLS0tLS0t IEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDEudHh0DQoNCkRh dGU6DQoNClR1ZSwgMDMgTWF5IDIwMTYgMDc6NTI6NDggLTA3MDANCg0KRnJvbToNCg0KaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQoNClRv Og0KDQpDaGFybGVzIEUuIFBlcmtpbnMgPGNoYXJsaWVwQGNvbXB1dGVyLm9yZz48bWFpbHRvOmNo YXJsaWVwQGNvbXB1dGVyLm9yZz4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1w ZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLTAxLnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IENoYXJsZXMgRS4gUGVya2lucyBhbmQgcG9zdGVkIHRvIHRoZQ0KDQpJRVRG IHJlcG9zaXRvcnkuDQoNCg0KDQpOYW1lOiAgICAgICAgICBkcmFmdC1wZXJraW5zLW1hbmV0LWFv ZHYtZTJlc2VjDQoNClJldmlzaW9uOiAgICAgIDAxDQoNClRpdGxlOiAgICAgICAgIEVuZHBvaW50 IE1lc3NhZ2UgQXV0aGVudGljYXRpb24gZm9yIEFPRFYgUm91dGUgTWVzc2FnZXMNCg0KRG9jdW1l bnQgZGF0ZTogMjAxNi0wNS0wMw0KDQpHcm91cDogICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCg0KUGFnZXM6ICAgICAgICAgNQ0KDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDEu dHh0DQoNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1wZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLw0KDQpIdG1saXplZDogICAgICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDEN Cg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1wZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLTAxDQoNCg0KDQpBYnN0cmFjdDoNCg0KICAgVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgYSBuZXcgdHlwZSBleHRlbnNpb24gdG8gZW5hYmxlIFJGQyA3 MTgyDQoNCiAgIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB0byBiZSB1c2VkIGZvciBhdXRoZW50 aWNhdGluZyBBT0RWdjIgcm91dGUNCg0KICAgbWVzc2FnZXMuICBUaGUgZG9jdW1lbnQgYWxzbyBz cGVjaWZpZXMgYSBuZXcgbWVzc2FnZSBUTFYgZm9yIEFPRFZ2Mg0KDQogICBhbmQsIHBvdGVudGlh bGx5LCBvdGhlciByZWFjdGl2ZSBwcm90b2NvbHMuICBCb3RoIG1lY2hhbmlzbXMgYWxsb3cNCg0K ICAgdGhlIGVuZHBvaW50cyBvZiBhIG5ld2x5IGRpc2NvdmVyZWQgcm91dGUgdG8gYmUgYXNzdXJl ZCB0aGF0IHRoZXkNCg0KICAgd2VyZSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgUlJFUSBhbmQgcmVz cG9uZGVyIHByb2R1Y2luZyB0aGUgUlJFUA0KDQogICByZXNwZWN0aXZlbHkuDQoNCg0KDQoNCg0K DQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBp ZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5k ZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3Ig ZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioK --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2CC7GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxT dHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSB0aGluayB0aGlzIGlzIHRoZSB3cm9uZyBhcHByb2FjaCwgdG8gY3JlYXRlIGEgc3BlY2lh bGlzZWQgc3RydWN0dXJlIGNvbnRhaW5pbmcganVzdCB3aGF0IHlvdSBrbm93IHlvdSBjdXJyZW50 bHkgd2FudCBpbiBBT0RWdjIgYW5kIHByb3RlY3QgdGhhdCwgYXMgYSB0eXBlDQogZXh0ZW5zaW9u IHRvIGEgZ2VuZXJhbCBwdXJwb3NlIFRMVi4gQW5kIGFuIGFwcHJvYWNoIHRoYXQgZG9lc27igJl0 IGdlbmVyYWxpc2UgdG8gYW55IHBvc3NpYmxlIEFPRFZ2MiBleHRlbnNpb25zLiBPZiBjb3Vyc2Ug YXMgYW4gZXhwZXJpbWVudGFsIG5vbi1hbGxvY2F0aW9uIHRoYXQgaGFuZGxlcyB0aGUgZm9ybWVy IHBvaW50LCBidXQgbm90IHRoZSBsYXR0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZSBkaXNjdXNz aW9ucyB0aGF0IGhhdmUgdGFrZW4gcGxhY2Ugb24gd2hhdCBvbmUgbWlnaHQgY2FsbCBhIHN1YnRy YWN0aXZlIGFwcHJvYWNoIGlzIG1vcmUgYXBwcm9wcmlhdGUsIGNvdmVyaW5nIGV2ZXJ5dGhpbmcg KHBsdXMgcG9zc2libHkgYWRkcmVzcyhlcykpDQogZXhjZXB0IGV4cGxpY2l0bHkgZXhjbHVkZWQg cGFydHMgb2YgdGhlIG1lc3NhZ2UuIEFuZCB0cnlpbmcgaGFyZCB0byBtYWtlIHRob3NlIHBhcnRz IGFic29sdXRlbHkgbWluaW1hbCwgaWRlYWxseSBqdXN0IG9uZSBibG9jayBvZiBkYXRhIHRoYXQg Y2FycmllcyBvbmUgKG9yIHBvc3NpYmx5IHR3byBpZiBhc3ltbWV0cmljKSBtZXRyaWMgdmFsdWVz LiBCZWNhdXNlIGFzIEkgdW5kZXJzdGFuZCBpdCBvbmUgYmxvY2sgbWFrZXMgc29tZSBmdXR1cmUg Y29uY2VwdHMNCiBzdWNoIGFzIGFnZ3JlZ2F0aW9uIG1vcmUgcHJhY3RpY2FsLCBidXQgaW4gdGhl IG1lYW53aGlsZSBpcyBqdXN0IG9uZSBibG9jayB0byB6ZXJvIG91dCwgd2l0aCBtaW5pbWFsIGlu Zm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdCBkb2VzIHJlcXVpcmUgc2VwYXJhdGluZyBvdXQgUlJF UC1BQ0tzLCB3aGljaCBtYXkgYmUgYSBnb29kIGlkZWEgYW55d2F5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWQg c3Ryb25nbHkgc3VnZ2VzdCBpZiBnb2luZyBkb3duIHRoaXMgcm91dGUgKGEpIGRlc2lnbmluZyBp dCBjYXJlZnVsbHksIChiKSBzcGVjaWZ5aW5nIGJ5IHBvc2l0aW9uLCAoYykgb25seSBwZXJtaXR0 aW5nIHRoZSBleGNsdXNpb24gKG9yIGVhY2ggZXhjbHVzaW9uIGlmDQogbW9yZSB0aGFuIG9uZSBp cyBuZWVkZWQgLSB0aG91Z2ggYXZvaWRpbmcgdGhhdCBpcyBhbm90aGVyIHN0cm9uZyBzdWdnZXN0 aW9uKSB0byBiZSBhbGwgb3IgcGFydCBvZiBhIHNpbmdsZSBtZXNzYWdlIFRMViB2YWx1ZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoaXMsIGluY2x1ZGluZyAoYSksIGlzIG9mIGNvdXJzZSBhIHJlYXNvbiBmb3IgbXkg bGFzdCBwb3N0aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdF N0UiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBh bCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRv cmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj QkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8 ICZuYnNwOzxiPkU6DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl bGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxt c2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1z LmNvbS9haSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9h aTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsg V2FsZXMgTm86IDAxMzM3NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJr LCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0 Ij4gbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5DaGFybGVzIEUuIFBlcmtpbnM8YnI+DQo8Yj5TZW50OjwvYj4gMDMgTWF5IDIwMTYgMTY6 NTI8YnI+DQo8Yj5Ubzo8L2I+IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFttYW5ldF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDEudHh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6 Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hp dGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5J TkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0 ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0 c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9y IHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRo ZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9y IHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJl Z2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxv b2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDov L2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0 cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEg aHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJp dHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1h aWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MS4wcHQgNC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4q PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+KioNCjwvc3Bhbj48L3N0cm9uZz48L3NwYW4+PHN0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XQVJOSU5HDQo8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+KioqPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJy Pg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkVYVEVSTkFMIEVNQUlMIC0tIFRo aXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SGVsbG8gZm9sa3MsPG86cD48L286cD48L3A+DQo8 cD5BY2NvcmRpbmcgdG8gbXkgdW5kZXJzdGFuZGluZyBvZiBSRkMgNzE4MiwgaXQgc2VlbXMgcHJl dHR5IG11Y2ggc3RyYWlnaHRmb3J3YXJkIHRvIGRvIHRoZSBwcm9wZXIgZW5kLXRvLWVuZCBhdXRo ZW50aWNhdGlvbiBmb3IgUlJFUS9SUkVQIHVzaW5nIGEgbmV3IG5ldyB0eXBlIGV4dGVuc2lvbi4m bmJzcDsgUGxlYXNlIGhhdmUgYSBsb29rIHRvIHNlZSB3aGV0aGVyIHRoZXJlIGlzIGFueSBhZGRp dGlvbmFsIHNwZWNpZmljYXRpb24gcmVxdWlyZWQgaW4NCiBvcmRlciB0byByZXF1ZXN0IGFsbG9j YXRpb24gb2YgdGhlIG5ldyB0eXBlIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwPkkga2Vw dCB0aGUgUkZDIDQ4Njggc2VjdGlvbiBhcyBhbm90aGVyIGFsdGVybmF0aXZlIGp1c3QgaW4gY2Fz ZSB0aGUgUkZDIDcxODIgc3BlY2lmaWNhdGlvbiB0dXJucyBvdXQgdG8gYmUgbW9yZSBkaWZmaWN1 bHQgdGhhbiBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcuPG86cD48L286cD48L3A+DQo8cD5JZiBp dCBpcyBzdWl0YWJsZSwgdGhlIHNwZWNpZmljYXRpb24gZm9yIHRoZSBuZXcgdHlwZSBleHRlbnNp b24gaW4gdGhpcyBkcmFmdCB3b3VsZCBwcm9iYWJseSBmaXQgdmVyeSBjb21mb3J0YWJseSB3aXRo IHRoZSBBT0RWdjIgZHJhZnQsIG9yIGl0IGNvdWxkIGdvIGZvcndhcmQgc2VwYXJhdGVseS48bzpw PjwvbzpwPjwvcD4NCjxwPkNvbW1lbnRzIHdpbGwgYmUgYXBwcmVjaWF0ZWQuPG86cD48L286cD48 L3A+DQo8cD5SZWdhcmRzLDxicj4NCkNoYXJsaWUgUC48bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N Ci0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9vOnA+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2Vs bHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIg c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlN1YmplY3Q6IDxvOnA+PC9v OnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt cGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMS50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNt IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9 InRleHQtYWxpZ246cmlnaHQiPjxiPkRhdGU6IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlR1ZSwgMDMgTWF5IDIwMTYgMDc6NTI6NDggLTA3MDA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNt IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9 InRleHQtYWxpZ246cmlnaHQiPjxiPkZyb206IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5v d3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQi PjxiPlRvOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBj bSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFybGVzIEUuIFBlcmtpbnMg PGEgaHJlZj0ibWFpbHRvOmNoYXJsaWVwQGNvbXB1dGVyLm9yZyI+Jmx0O2NoYXJsaWVwQGNvbXB1 dGVyLm9yZyZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDEudHh0PG86cD48L286cD48L3ByZT4NCjxwcmU+ aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaGFybGVzIEUuIFBlcmtpbnMgYW5k IHBvc3RlZCB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JRVRGIHJlcG9zaXRvcnkuPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TmFtZTom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJh ZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJldmlz aW9uOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBFbmRwb2ludCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIGZvciBBT0RWIFJvdXRlIE1lc3NhZ2Vz PG86cD48L286cD48L3ByZT4NCjxwcmU+RG9jdW1lbnQgZGF0ZTogMjAxNi0wNS0wMzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPkdyb3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5QYWdlczombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg NTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVz ZWMtMDEudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGVy a2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMS50eHQ8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+ U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZXJraW5zLW1h bmV0LWFvZHYtZTJlc2VjLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt cGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy88L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+SHRt bGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLTAx Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUy ZXNlYy0wMTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5EaWZmOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUy ZXNlYy0wMSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXBlcmtpbnMt bWFuZXQtYW9kdi1lMmVzZWMtMDE8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+QWJzdHJhY3Q6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbmV3IHR5cGUgZXh0ZW5zaW9uIHRv IGVuYWJsZSBSRkMgNzE4MjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhdXRo ZW50aWNhdGlvbiBtZWNoYW5pc20gdG8gYmUgdXNlZCBmb3IgYXV0aGVudGljYXRpbmcgQU9EVnYy IHJvdXRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG1lc3NhZ2VzLiZuYnNw OyBUaGUgZG9jdW1lbnQgYWxzbyBzcGVjaWZpZXMgYSBuZXcgbWVzc2FnZSBUTFYgZm9yIEFPRFZ2 MjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhbmQsIHBvdGVudGlhbGx5LCBv dGhlciByZWFjdGl2ZSBwcm90b2NvbHMuJm5ic3A7IEJvdGggbWVjaGFuaXNtcyBhbGxvdzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGUgZW5kcG9pbnRzIG9mIGEgbmV3bHkg ZGlzY292ZXJlZCByb3V0ZSB0byBiZSBhc3N1cmVkIHRoYXQgdGhleTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyB3ZXJlIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBSUkVRIGFuZCBy ZXNwb25kZXIgcHJvZHVjaW5nIHRoZSBSUkVQPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IHJlc3BlY3RpdmVseS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9k aXY+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPgpy ZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhl IHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24uPGJyPgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvcD48L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2CC7GLKXM0002VGREEN_-- From nobody Tue May 3 09:14:40 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB2F12D9D5 for ; Tue, 3 May 2016 09:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX3yRPP3p_Mv for ; Tue, 3 May 2016 09:14:35 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDB212DA10 for ; Tue, 3 May 2016 09:14:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4EC965E13EB; Tue, 3 May 2016 09:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1462292059; bh=U9nEZJHTAaL3ZwyUqcE0UAKpukPaacXECx05gZADVJ4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=pUnPuLObzLijqtHUfW4BxoODj8Ai0UD4sNpESaT8FLhF/TSl74stMvZxgEac8wTKn 7zEjvpqKm4IyPxERa1MrjizRF4jtvUpwTlwC8Zs1l+wjMEgfRdxoCpRA0W7bUC12b5 wGJVbfLGJWnvekJ6nUQxNAZ19MKrjKccnxExUnjI= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [129.104.89.231] (unknown [129.104.89.231]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 180E85E0FB5; Tue, 3 May 2016 09:14:17 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_BC62D79F-1DA0-494E-85B4-9E39D56CD408" From: ietf@thomasclausen.org In-Reply-To: Date: Tue, 3 May 2016 18:14:15 +0200 Sendlaterdate: Tue, 3 May 2016 18:14:15 +0200 Message-Id: References: <20160503145248.8264.43392.idtracker@ietfa.amsl.com> To: Christopher Dearlove X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Fwd: New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 16:14:38 -0000 --Apple-Mail=_BC62D79F-1DA0-494E-85B4-9E39D56CD408 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 03 May 2016, at 18:07, Dearlove, Christopher (UK) = wrote: >=20 > I think this is the wrong approach, to create a specialised structure = containing just what you know you currently want in AODVv2 and protect = that, as a type extension to a general purpose TLV. And an approach that = doesn=E2=80=99t generalise to any possible AODVv2 extensions. Of course = as an experimental non-allocation that handles the former point, but not = the latter. Yes =E2=80=94 that has been the point I have made repeatedly: that this = e2esec draft (whether done as a 7182-TLV type extension, or as something = else) simply precludes extensions.=20 Especially for an experimental protocol, where I would anticipate=E2=80=A6= you know=E2=80=A6.experiments ;), that would be unacceptable. > I think the discussions that have taken place on what one might call a = subtractive approach is more appropriate, covering everything (plus = possibly address(es)) except explicitly excluded parts of the message. = And trying hard to make those parts absolutely minimal, ideally just one = block of data that carries one (or possibly two if asymmetric) metric = values. Because as I understand it one block makes some future concepts = such as aggregation more practical, but in the meanwhile is just one = block to zero out, with minimal information. +1 > That does require separating out RREP-ACKs, which may be a good idea = anyway.=20 +1 Thomas > I=E2=80=99d strongly suggest if going down this route (a) designing it = carefully, (b) specifying by position, (c) only permitting the exclusion = (or each exclusion if more than one is needed - though avoiding that is = another strong suggestion) to be all or part of a single message TLV = value. > =20 > This, including (a), is of course a reason for my last posting. > =20 > -- >=20 > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > = __________________________________________________________________________= >=20 > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com = >=20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >=20 > =20 > From: manet [mailto:manet-bounces@ietf.org = ] On Behalf Of Charles E. Perkins > Sent: 03 May 2016 16:52 > To: Mobile Ad Hoc Networks mailing list > Subject: [manet] Fwd: New Version Notification for = draft-perkins-manet-aodv-e2esec-01.txt > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > For information regarding Red Flags that you can look out for in = emails you receive, click here = . > If you feel the email is suspicious, please follow this process = . >=20 > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our = organization. > =20 > =20 >=20 > Hello folks, >=20 > According to my understanding of RFC 7182, it seems pretty much = straightforward to do the proper end-to-end authentication for RREQ/RREP = using a new new type extension. Please have a look to see whether there = is any additional specification required in order to request allocation = of the new type extension. >=20 > I kept the RFC 4868 section as another alternative just in case the = RFC 7182 specification turns out to be more difficult than my current = understanding. >=20 > If it is suitable, the specification for the new type extension in = this draft would probably fit very comfortably with the AODVv2 draft, or = it could go forward separately. >=20 > Comments will be appreciated. >=20 > Regards, > Charlie P. >=20 > =20 >=20 >=20 >=20 > -------- Forwarded Message --------=20 > Subject:=20 > New Version Notification for draft-perkins-manet-aodv-e2esec-01.txt > Date:=20 > Tue, 03 May 2016 07:52:48 -0700 > From:=20 > internet-drafts@ietf.org > To:=20 > Charles E. Perkins = > =20 >=20 > A new version of I-D, draft-perkins-manet-aodv-e2esec-01.txt > has been successfully submitted by Charles E. Perkins and posted to = the > IETF repository. > =20 > Name: draft-perkins-manet-aodv-e2esec > Revision: 01 > Title: Endpoint Message Authentication for AODV Route Messages > Document date: 2016-05-03 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-perkins-manet-aodv-e2esec-01.tx= t = > Status: = https://datatracker.ietf.org/doc/draft-perkins-manet-aodv-e2esec/ = > Htmlized: = https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-01 = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-perkins-manet-aodv-e2esec-01 = > =20 > Abstract: > This document specifies a new type extension to enable RFC 7182 > authentication mechanism to be used for authenticating AODVv2 route > messages. The document also specifies a new message TLV for AODVv2 > and, potentially, other reactive protocols. Both mechanisms allow > the endpoints of a newly discovered route to be assured that they > were the originator of the RREQ and responder producing the RREP > respectively. > =20 > = =20 > =20 > =20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. > =20 > The IETF Secretariat > =20 > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = --Apple-Mail=_BC62D79F-1DA0-494E-85B4-9E39D56CD408 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 03 May 2016, at 18:07, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

I think this is the = wrong approach, to create a specialised structure containing just what = you know you currently want in AODVv2 and protect that, as a type = extension to a general purpose TLV. And an approach that doesn=E2=80=99t = generalise to any possible AODVv2 extensions. Of course as an = experimental non-allocation that handles the former point, but not the = latter.

Yes= =E2=80=94 that has been the point I have made repeatedly: that this = e2esec draft (whether done as a 7182-TLV type extension, or as something = else) simply precludes extensions. 

Especially for an experimental protocol, where I = would anticipate=E2=80=A6you know=E2=80=A6.experiments ;), that would be = unacceptable.


I think the discussions that have taken = place on what one might call a subtractive approach is more appropriate, = covering everything (plus possibly address(es)) except explicitly = excluded parts of the message. And trying hard to make those parts = absolutely minimal, ideally just one block of data that carries one (or = possibly two if asymmetric) metric values. Because as I understand it = one block makes some future concepts such as aggregation more practical, = but in the meanwhile is just one block to zero out, with minimal = information.

+1

 That does require separating out RREP-ACKs, = which may be a good idea anyway. 

+1

Thomas

I=E2=80=99d strongly suggest if going down = this route (a) designing it carefully, (b) specifying by position, (c) = only permitting the exclusion (or each exclusion if more than one is = needed - though avoiding that is another strong suggestion) to be all or = part of a single message TLV value.
 
This, including (a), is = of course a reason for my last posting.
 

--

Christopher Dearlove
Senior Principal = Engineer
BAE Systems Applied Intelligence Laboratories
_______________________________________________________________= ___________

T:  +44 = (0)1245 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, = Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research = Park, Guildford, Surrey, GU2 7YP

 
From: manet [mailto:manet-bounces@ietf.org] On Behalf = Of Charles E. = Perkins
Sent: 03 May 2016 16:52
To: Mobile Ad Hoc Networks = mailing list
Subject: [manet] Fwd: New Version = Notification for draft-perkins-manet-aodv-e2esec-01.txt
 
 
*** WARNING ***

This message originates from outside our organisation, either = from an external partner or the internet.
Consider carefully = whether you should click on any links, open any attachments or = reply.
For information = regarding Red = Flags that you = can look out for in emails you receive, click here.
If you feel the = email is suspicious, please follow this = process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our = organization.
 

 

Hello folks,

According to my understanding of RFC 7182, it seems = pretty much straightforward to do the proper end-to-end authentication = for RREQ/RREP using a new new type extension.  Please have a look = to see whether there is any additional specification required in order = to request allocation of the new type extension.

I = kept the RFC 4868 section as another alternative just in case the RFC = 7182 specification turns out to be more difficult than my current = understanding.

If it is suitable, the specification for the new type = extension in this draft would probably fit very comfortably with the = AODVv2 draft, or it could go forward separately.

Comments will be appreciated.

Regards,
Charlie P.

 



-------- = Forwarded Message -------- 
Subject: 
New Version = Notification for draft-perkins-manet-aodv-e2esec-01.txt
Date: 
Tue, 03 May 2016 = 07:52:48 -0700
From: 
internet-drafts@ietf.org
To: 
Charles E. = Perkins <charliep@computer.org>

 

A new version of I-D, =
draft-perkins-manet-aodv-e2esec-01.txt
has been successfully submitted by Charles E. =
Perkins and posted to the
IETF repository.
 
Name:          =
draft-perkins-manet-aodv-e2esec
Revision:      =
01
Title:         =
Endpoint Message Authentication for AODV Route Messages
Document date: =
2016-05-03
Group:         =
Individual Submission
Pages:         5
URL:          =
;  https://www.ietf.org/internet-drafts/draft-perkins-manet-aodv-e=
2esec-01.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-manet-aodv-e2ese=
c/
Htmlized:       https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-01<=
/a>
Diff:         &nbs=
p; https://www.ietf.org/rfcdiff?url2=3Ddraft-perkins-manet-aodv-e2=
esec-01
 
Abstract:
   =
This document specifies a new type extension to enable RFC 7182
   =
authentication mechanism to be used for authenticating AODVv2 route
   =
messages.  The document also specifies a new message TLV for =
AODVv2
   and, potentially, other reactive =
protocols.  Both mechanisms allow
   the endpoints of a newly =
discovered route to be assured that they
   were the originator of the RREQ =
and responder producing the RREP
   respectively.
 
          &nb=
sp;            =
;            &=
nbsp; =
            &n=
bsp;           &nbs=
p;            =
        
 
 
Please note =
that it may take a couple of minutes from the time of submission
until the =
htmlized version and diff are available at tools.ietf.org.
 
The IETF =
Secretariat
 
 

***************************************************************= *****
This email and any attachments are confidential to = the intended
recipient and may also be privileged. If you = are not the intended
recipient please delete it from your = system and notify the sender.
You should not copy it or = use it for any purpose nor disclose or
distribute its = contents to any other person.
***************************************************************= *****

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

= --Apple-Mail=_BC62D79F-1DA0-494E-85B4-9E39D56CD408-- From nobody Tue May 3 09:17:16 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20D12DA14 for ; Tue, 3 May 2016 09:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxyg8yQCa5ho for ; Tue, 3 May 2016 09:17:12 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF68312B023 for ; Tue, 3 May 2016 09:17:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BA41E5E12EA; Tue, 3 May 2016 09:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1462292232; bh=O0dst4rJIMkkw6PEaO/iVI7bIxlMjuRXQ4FRirxHYQ8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=jgZLJbgiko2z5KCNEqhAlcD+7pP3nYzjTHYGZgpUkr/tYmSeSBuigzXL1wg8LXB1T QLquDSLb4tYDkfCFbJ0uHenpscC0sIFDYuFAVOXZSXFL8bvJuLDF1R4l+sj0nTQvae YX7MpucbYEpKn71M7z63tYNGe69mM/IAVxly/3sg= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [129.104.89.231] (unknown [129.104.89.231]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 01D705E149A; Tue, 3 May 2016 09:17:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: ietf@thomasclausen.org In-Reply-To: Date: Tue, 3 May 2016 18:17:10 +0200 Content-Transfer-Encoding: quoted-printable Sendlaterdate: Tue, 3 May 2016 18:17:10 +0200 Message-Id: <7F65C247-FC30-4A01-9AD2-38A3B330A090@thomasclausen.org> References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org> <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org> <60BD2E9C-64D7-4444-B3A9-8D207EB4A86F@gmail.com> <144C7397-F19E-4FB0-959A-B5A030BD7A8A@fu-berlin.de> <883f2cf1-ffc7-9910-d80b-e3b610353273@earthlink.net> To: Charles Perkins X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] On Forwarding-and-regeneration X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 16:17:15 -0000 > On 03 May 2016, at 18:06, Charlie Perkins = wrote: >=20 > Hello Jiazi, >=20 > Follow-up below... >=20 > On 4/28/2016 5:14 AM, Jiazi YI wrote: >> I think it will make the specification complex, and hard to extend. >>=20 >> What about if I need to define a new TLV field for my extension? The = field would either be unprotected, or the extension won't be = interoperable with old implementations. >=20 > RFC 7182 has the following language: >=20 >> The rationale for removing any ICV Message TLVs already present = prior >> to calculating the ICV is that several ICV TLVs may be added to the >> same message, e.g., using different ICV cryptographic and/or hash >> functions.=20 >=20 > So you could use another ICV for the new purpose, and handling for = previous ICVs is already specified. >=20 That is not the point. The point is, that this e2e draft that you are = proposing says =E2=80=9Ccalculate ICV over these elements only=E2=80=9D = =E2=80=94 and so when Jiazi develops a extension that adds a = TLV to RREQs, that TLV is not covered by the ICV. Covering such TVLs with the ICV would require an =E2=80=9CUpdates = e2esec=E2=80=9D for each extension to be specified. Horrible source of = non-interoperability. > I don't think it's necessary to discourage mutable fields in reactive = route discovery. There have been many variations on AODV route = discovery, and I can't think of any that didn't change the control = messages as they were passed hop by hop from source to destination and = back. =E2=80=A6 but, none of those "variations on AODV route discovery=E2=80=9D = came with security =E2=80=A6 Thomas= From nobody Tue May 3 16:19:57 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4C612DA26 for ; Tue, 3 May 2016 16:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrtIaWGGGYh0 for ; Tue, 3 May 2016 16:19:52 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5886512DA20 for ; Tue, 3 May 2016 16:19:51 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id t10so52740710ywa.0 for ; Tue, 03 May 2016 16:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=l1wC9kBVplMS1ErpmBHZiRKMH9TXNvjIiWDmTWYzk6c=; b=g6uStBv5PO9rZH+OHT9rliUkNV7Yz47wTJ4ZJPbKllddP95ZUREV+HUTKyGEw9yXy4 h+Ncjt5B1QitH4gUGaPAJ7lJI4ASFXqUavafSv8mrKWKhk8Zlqa7tzWQz+ottPVYjPhV hmcyvSlBSSVs/n5hpEm+oG3ioVbDsIrKzUaObXiuRdjgYdKK57WKoPf48khvu0Jxq9Aq VFeU5Kk3jk1BSv3SZA7tYYhA0RZOEWL9wZ/mbYv0D3u0BwADcDvy8BMb79+qDyZBCXk0 uD/H8ExEOdJqfTIKGeFiDDzk0APvfWiUHdKPl8pzSaLcvXgAXm8YqfcKed6Q4UqCRpTQ AyPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=l1wC9kBVplMS1ErpmBHZiRKMH9TXNvjIiWDmTWYzk6c=; b=kbP20a6OzmG6AL4+boIDv4lHFLtV1A1tN/5JA07dLQ1AY6yuvGVAFMP5WFNKLJWpr2 WhTl7CgpnOrHVo6+YcgvB8xJ4e5VMllepYGEDdsvNgWwzd+Ig1KCs7GbWzvBepQy91Y3 JesAsyO744X72XrE1CldeDcLkbcdQLM7vb5USskp7Q4f2Z858oYlbRh4/lJlHFnZDMNS JyT0D9fnCOgtUrw0d3VlwQU+qYGURzbRjr2xlMTwUUziH5QIGVoBHFN1DxR7IW8XsHNp GgO2h2WoyoQELqsZCVyB6sPEFjOodbBtbG6x3MWHFtmECPGY68+v4I0Pom3Nk0c+sBEu WAcA== X-Gm-Message-State: AOPr4FUbWcBpUCyZz4JbCXGBQgdkSabgPHcjD0TLlAak4HdRJ2E/R1LDg+A5OevV94/hLqBgRb9C9WL5a06d7A== MIME-Version: 1.0 X-Received: by 10.159.39.33 with SMTP id a30mr2682606uaa.59.1462317590527; Tue, 03 May 2016 16:19:50 -0700 (PDT) Received: by 10.176.65.40 with HTTP; Tue, 3 May 2016 16:19:50 -0700 (PDT) In-Reply-To: <33F4027C-8E60-46CD-BBD7-DACD70A54D21@fu-berlin.de> References: <33F4027C-8E60-46CD-BBD7-DACD70A54D21@fu-berlin.de> Date: Wed, 4 May 2016 00:19:50 +0100 Message-ID: From: Victoria Mercieca To: Mobile Ad Hoc Networks mailing list , YI Jiazi Content-Type: multipart/alternative; boundary=94eb2c123cfa8846540531f858ce Archived-At: Subject: Re: [manet] draft-ietf-manet-aodvv2-15 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 23:19:56 -0000 --94eb2c123cfa8846540531f858ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jiazi, Thank you for your review. I have a few comments to add, inline marked with "VM>". On Thu, Apr 28, 2016 at 11:50 PM, Lotte Steenbrink < lotte.steenbrink@fu-berlin.de> wrote: > Hi Jiazi, > thank you for your detailed review. A few comments and questions inline. > (I wanted to get this reply out the door as soon as I could, so I/we will > follow up regarding the yet unresponded to items later) > > Am 28.04.2016 um 16:53 schrieb Jiazi YI : > > Hi, > > Here is my preliminary review on aodvv2-15. There are still some points > that I'm not sure that I have fully understood -- I will get back to them > if I had time. > > A summary of my review: > > 1. The specification lacks of a "big picture" of the protocol functioning= . > People prefer to have a general idea of the whole protocol at the very > beginning. This is particularly important for readers who are not familia= r > with reactive protocol in general. > Some of the sections can be reorganized a bit to improve the readability. > For example, with the current structure, the readers need to reach sectio= n > 6.6 (Route discovery) before they can really touch the core function of t= he > protocol. > > 2. As an experimental protocol, the part related to experiments needs to > be improved. IMO, at least the following information must be provided: > - The motivation of this experimental document > - The experiments to be conducted > - What kind of feedback is expected to reported. > > 3. There are some redundant processing procedures in the draft. On the > other hand, some connections between the sections seem to be missing. > Sometimes it's hard to build connection between the message processing an= d > related information bases. > I think this is partially due to the lack of implementation, or the > implementation experience is not reported to the author team? > > 4. The specification uses lots of multicast messages. While multicast RRE= Q > is inevitable, the necessity of multicast RREP/RERR is not clear. It brin= g > issues related to control message overhead and security. > > 5. The interaction with RIB: The route state maintenance requires "*Local= Route.State > MUST be checked before IP packet forwarding and before any operation base= d > on LocalRoute.State.*". Having such check for each data packet might be > heavy load for the system if the routing daemon runs in userspace (becaus= e > of context switch). While interaction with RIB is inevitable, we want to > reduce it as much as possible -- per data packet operation is too much. > > > Hmmm. Yeah. To me it would make more sense to say "if you have a RIB, you > MUST update it any time LocalRoute.State changes [so instead of the polli= ng > described above, you=E2=80=99d let the changes =E2=80=9Etrickle up=E2=80= =9C and avid constant > context switches]. If you don=E2=80=99t have a RIB and LocalRoute is cons= ulted > directly when forwarding a packet [this would=E2=80=99ve been the case in= RIOT a > few releases ago.. but there=E2=80=99s no kernel vs user space there eith= er, so you > wouldn=E2=80=99t have the expensive context switches], you MUST check > LocalRoute.State before you forward to make sure the route is still valid= .=E2=80=9C > ... > > VM> That statement: "*LocalRoute.State MUST be checked before IP packet forwarding * ".... I think is for the case where you don't have timers running to handle timeouts. so before you do anything which depends on route state, you need to check what the state should be. i.e., has the route gone from idle to invalid. However, we also rely on knowledge of whether a route is being used to keep it in Active state, so there's another place we might want a per-packet operation. > > 6. There are too many "MAY" and "SHOULD" in the document without > elaboration. Some of which might cause interoperability issues or even > loops. > > 8. security issues. There are discussions going on in different threads, > so I won't repeat them here. I think the current regeneration-based > approach is complex to secure and hard for future extensions. > > > We=E2=80=99ve gotten rid of that approach as of now. :) > > I haven't checked the security considerations section in detail yet. It's > important to get the big direction right first. > > Please check the details inline: > > *section 1, overview* > > The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol >> enables dynamic,* self-starting*, multihop routing > > > The term "self-starting" is very vague. It makes people think of > auto-configuration. And I didn't see such kind of feature is supported. I > would avoid using it. > > > Makes sense. I=E2=80=99ve removed the term. > > > AODVv2 is an Experimental protocol. >> ... > > > I think much more information is required here: > > 1) Because RFC 3561 has already been experimented for 13 years, as its > version 2, AODVv2 should summarize what kind of experiences have been > obtained in the past 13 years, and justify the design choices made in the > current draft (like use of RFC5444, removing some of the features, etc) > > 2) The motivation and experiments to be conducted need to be elaborated. > It's even necessary to have a separate section/subsection for it. Some > experiment points that come to my mind without much thinking: support of > multiple interfaces, support of gateways, use of different metrics, the > security model, etc.. > > > Fair enough. Thank you for the detailed pointers, I=E2=80=99ll write som= ething up > (unless my co-authors beat me to it ;) ) and get back to you, if that=E2= =80=99s > okay? > > > The basic operations of the AODVv2 protocol are route discovery and >> route maintenance... > > > It's necessary to give an overview of the basic functioning of the > protocol, rather than simply saying "use RREQ/RREP to carry information a= nd > build routes". Because after this, the draft jumps directly into the > protocol details. > It's extremely important for the readers who are not familiar with > reactive protocol. > > > Good point. we=E2=80=99ve removed =E2=80=9EThe basic operations of the AO= DVv2 protocol are > route discovery and route maintenance.=E2=80=9C, since that sentence occu= rs in the > first paragraph already, and we=E2=80=99ve substituted the =E2=80=9EAn AO= DVv2 router is > configured to perform route discovery=E2=80=A6=E2=80=9C paragraph with: > > The basic protocol mechanisms are as follows. Since AODVv2 is a > reactive protocol, route discovery is initiated only when a route to > the target is needed (i.e. when a router' client wants to send data). > AODVv2 does this with the help of a Route Request (RREQ) and Route > Reply (RREP) cycle: an RREQ is distributed across the network until > it arrives at the target. When forwarding an RREQ, all routers > across the network store the neighbor they've received the RREQ from, > memorizing a possible route back to the originator of the RREQ. When > the target receives the RREQ, it answers with an RREP, which then > travels back to the originator along the path memorized by the > intermediate routers. A metric value is included within the messages > to record the cost of the route. AODVv2 uses sequence numbers to > identify stale routing information, and compares route metric values > to determine if advertised routes could form loops. > > we=E2=80=99ve also slightly updated the language of the next pararaph: > > Route maintenance includes confirming bidirectionality of links to > next hop AODVv2 routers and issuing Route Error (RERR) messages > informing other routers of broken links. It also includes reacting > to received Route Error messages, and extending and enforcing route > timeouts. > > What do you think? > > > > *section 2, Terminology* > > Please pay attention to the style of the terms. Most of the time, style > like AckReq is used, but sometimes RERR_Gen is used. > Good to be consistent. > > > I think I=E2=80=99ve pointed out a similar issue too (in spring 2014, I t= hink?), > but I think I recall the conclusion being that while the draft should sti= ck > to CamelCase wherever it can, renaming RERR_Gen to RERRGen would have a > negative impact on readability, so there are some exceptions to the rule= =E2=80=A6 > > > Unreachable Address >> An address reported in a Route Error message, as described in >> Section 7.4.1. > > > need to explain what's the address for exactly, rather than giving a > pointer to a big section. > > > We had a longer explanation there but Justin said we should shorten it, s= o > we did that and added the pointer=E2=80=A6 :D > > > *section 3, applicability statement* > > AODVv2 handles a wide variety of mobility and traffic patterns by >> determining routes on-demand... > > > It necessary to explicitly call out what kind of traffic patterns that > reactive protocols are not suitable for, such as lots of routers send dat= a > packets to instantaneous and multiple destinations. If that happens, what= 's > the consequence (broadcasting storm, etc). > > > Good point. We=E2=80=99ve reworded the paragraph to.. > > AODVv2 handles a wide variety of mobility and traffic patterns by > determining routes on-demand. In networks with a large number of > routers, AODVv2 is best suited for relatively sparse traffic > scenarios where each router forwards IP packets to a small percentage > of other AODVv2 routers in the network. In this case fewer routes > are needed, and therefore less control traffic is produced. In large > networks with very frequent or bursty traffic, AODVv2 control > messages may cause a broadcast storm, overwhelming the network with > control messages and preventing routes from being established. This > especially applies to networks with point-to-point or point-to- > multipoint traffic. In this case, the transmission priorities > described in Section 6.5 prioritize route maintenance traffic over > route discovery traffic. > > Data packets may be buffered until a route to their destination is > available, as described in Section 6.6. > > Does that help? > > > >> AODVv2 provides for message integrity and security against replay >> attacks by using integrity check values, timestamps and sequence >> numbers, as described in Section 12. If security associations can be >> established, encryption can be used for AODVv2 messages to ensure >> that only trusted routers participate in routing operations. > > > We need to call out the hop-by-hop security model used, and the network > MUST apply necessary mechanisms to make sure that only trusted routers ca= n > participate in routing operations. > > > We=E2=80=99re currently working on getting rid of the hop by hop trust mo= del in > favor of end to end security. (I believe the thread is "Re: On > Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review -= a > couple of big ticket Items)=E2=80=9C?) > > > >> The routing algorithm in AODVv2 MAY be operated at layers other than >> the network layer, using layer-appropriate addresses. > > > Considering the deep coupling between AODVv2 and IP, I don't see how it > can work. This should be removed. > > *section 4 data structures* > > 4.1 Interface set > >> >> The InterfaceSet is a conceptual data structure which contains >> information about all interfaces available to AODVv2. >> ... >> Otherwise the InterfaceSet MAY be empty. > > > I'm not sure the sec MAY be empty -- a router contains at least one > interface, no? > > > Yes, but if it knows it only has one and it has access to this informatio= n > elsewhere and this won=E2=80=99t change, it might as well save the bytes = of stating > this again=E2=80=A6 Iirc the idea was to give implementations for constra= ined > devices a bit of leeway there. > > > 4.2 router client set > >> RouterClient.Cost >> The cost associated with reaching this address or address range. > > > Both "metric" and "cost" are used in the draft. If they are the same, > please pick a term and use it consistently. > > > Cost refers to the result of the Cost(L) function for the link to the > RouterClient. Would it make more sense it this entry was called LinkCost? > > > >> The AODVv2 router adding the Router Client MUST wait for >> any existing routing information about this Router Client to be >> purged from the network, i.e., at least MAX_SEQNUM_LIFETIME since the >> last SeqNum update on the router which is removing this Router >> Client. > > > I'm not sure that I parsed this sentence correctly, but the > adding/removing of router client seems to be more an external operation a= nd > out of the control of routing protocol itself. > > > =E2=80=A6But even when it has no influence on when/whether a router is > added/removed, shouldn=E2=80=99t it still be able to deal with the conseq= uences? So > if an AODVv2 outer is assigned a client that has previously been attached > to a different router, it should make sure it doesn=E2=80=99t confuse the= network > (which is achieved by waiting >=3D MAX_SEQNUM_LIFETIME before fully treat= ing > it as its own client)? > > > 4.3 neighbor set > >> >> Neighbor.State ... There are three possible states: Confirmed, Unknown, >> and >> Blacklisted. Unknown is the initial state. > > > I think the "Unknown" is a bit confusing here. It's actually something we > already know -- a state that "we heard from that node, but > bi-directionality is not confirmed". > I think "Heard" is a more appropriate term to be used here. > > 4.4 sequence numbers > > I think the comparison in wrap-around cases should be specified here. > > Tod determine staleness, > > > typo > > > Whoopsie, thanks > > > 4.5 Local route set > >> >> Alternatively, implementations >> MAY choose to modify the Routing Information Base directly. > > > This should be either more precise (in which condition, how we can modify > the RIB?), or be removed. > > > Isn=E2=80=99t the how really implementation specific? > > > > >> Multiple valid routes for the same address and prefix length but for >> different metric types may exist in the Local Route Set, but the >> decision of which of these routes to install in the Routing >> Information Base to use for forwarding is outside the scope of >> AODVv2. > > > It's OK, but maybe some rules must be specified and followed. For example= , > the metric used must be the same: if a packet is forwarded using metric A > at router X, and then metric B at router Y, it's a obvious source of loop= s. > > > Of course, but that=E2=80=99s an issue of properly establishing routes, w= hich > should be specified farther along in the draft, shouldn=E2=80=99t it? The= purpose > of this paragraph is to say =E2=80=9Eyou can have multiple valid routes (= each > following one metric type) to the same destination, but we won=E2=80=99t = specify > how to pick which metric type is most important to you (i.e. which route > you trust the most).=E2=80=9C > > > 4.6. Multicast Route Message Set > > Since this set is mainly for duplicate packet detection, I think some of > the fields are kind of redundant. For example, an RREQ/RREP message can b= e > identified by its originator's address and sequence number, why 6 fields > (OrigAddr, OrigFprefixLen, OrigSeqNum, TargAddr, TargPrefixLen, TargSeqNu= m) > are necessary here. > > VM> I think this is right, the "targ"-related fields might well be irrelevant, especially since we only put RREQ in that table now. Not that important to change at this stage, I dont think, but maybe if theres a tidy-up of the draft in future. > *section 5 Metrics* > > In Route Request messages, the metric describes the cost of the route >> from OrigAddr (and any other addresses included in the prefix length >> of RREQ_Gen's Router Client entry for OrigAddr) to the router sending >> the Route Request. > > > So the metric carried in the RREQ is the metric from Router Client to the > RREQ_Gen plus the metric from RREQ_Gen to the intermediate router. > In the Router Client Set, we have only one field for RouterClient.Cost. O= n > the other hand, "AODVv2 supports different metrics". > > routerClient.cost AODVv2 metric > client-----------------------RREQ_gen--------------- > > What if those two metrics are of different types? This is quite possible > because the two links might use different medium. > > VM> Good point. I guess the router client entries need a number of costs, one for each metric type that will be supported. can we do something like RouterClient.Costs =3D a number of {MetricType, Metric Value} pairs. And also maybe something like this?: "The RouterClient.Cost is the initial metric value used in a route message originated at this router. A Cost SHOULD be available for each MetricType configured for use. However, consider the case where a route with metric type MetricType is requested. If, at RREQ_Gen, there is no corresponding Cost value for this MetricType in the Router Client entry for OrigAddr, the value of OrigMetric is set to zero in the RREQ. Similarly, if the RREQ received at RREP_Gen requests a route of a MetricType for which there is no Cost value in the Router Client entry for TargAddr, the value of TargMetric is set to zero in the RREP." > > *section 6 AODVv2 protocol Operations* > > *General comments: * > > I think this section is hard to read and needs some reconstruction. > Generally speaking, people prefer begin from the important operations to > have a big picture/general idea of the protocol functioning, and then the > details. > With the current organization, one needs to read till section 6.6 (Route > discovery, retries and buffering) before he/she could reach the core > functioning of the protocol. > > I don't quite get the current organization of sections either. For exampl= e: > > section 6.2 (Next hop monitoring) and section 6.3 (Neighbor set update) > are very related. One is about the function, and one is about the > corresponding operation. The following sections don't follow this pattern > -- why not making them to one? > > section 6.7.1 (Evaluating route information) and section 6.8 (Suppressing > redundant messages using Multicast Route message set) seem to have some > overlapped operations. They all need to check the uniqueness of the > messages, compare the metrics and stop processing when duplication is > detected. Although they are applied to different information bases, they > are doing the same thing. > > section 6.9 (suppressing redundant RERR messages using the Route Error > set) should obviously a part of section 6.10.2 (reporting invalid routes)= , > but it's a separate section with higher hierarchy. > > VM> In that case the same would apply for use of the Multicast Route Message Set to stop redundant RREQs then? My opinion is that it's ok to have suppression as a protocol operation, and to refer to it within the message processing section. > more details inline: > > If such an entry does not exist, a new entry is created as described >> in Section 6.3. >> >> *While the value of Neighbor.State is Unknown, acknowledgement of RREP >> messages sent to that neighbor MUST be requested*. ... > > > I think we need to precise this is one for the case of RREP transmission. > > section 6.3 > > If an external mechanism reports a link as broken, the Neighbor Set >> entry SHOULD be removed. > > > I don't know why SHOULD, not MUST is used here. In fact, this is the only > place that I found that a Neighbor Set entry to be removed -- considering > the network is with constrained devices in a dynamic environment, isn't a > timer-based removing mechanisms is more adapted? > > >> an RREP which answers a RREQ sent within RREQ_WAIT_TIME over the >> same interface as Neighbor.Interface > > > I'm not a native English speaker, so I'm not sure about it should be "a > RREP" or "an RREP". But I think there is no reason to use them differentl= y > for RREQ/RREP? Need to check the consistency in the whole draft. > > > The =E2=80=9Ea RREQ=E2=80=9C is probably my fault, since I find that nota= tion more > intuitive as well, but we=E2=80=99ve decided that it should be =E2=80=9Ea= n RREQ=E2=80=9C, because > you=E2=80=99d pronounce it =E2=80=9Earr-reck=E2=80=9C, which warrants an = =E2=80=9Ean=E2=80=9C in front of it. > Thanks for the hint, I=E2=80=99ve checked the draft and found more of the= se errors, > all fixed now. > > > section 6.4. Interaction with the Forwarding Plane > > o A route has been updated: update the corresponding route in the >> Routing Information Base. > > > Do we need to pay attention to the "multi-metrics" issue here? To support > multi-metrics, do we need special fields in the RIB? If so, we need to ca= ll > it out in the applicability statement. > > > I=E2=80=99d guess it depends where you=E2=80=99re choosing one route over= the other? If > the RIB supports multiple metrics and can sort it out that=E2=80=99s grea= t, if not > you might want to decide which route to propagate on to the RIB based on > its metric, or you might want to =E2=80=9Etranslate=E2=80=9C metrics into= differently > prioritized routes in the RIB? (if that makes sense, it should probably b= e > mentioned in 4.5. Local Route Set though) > > > section 6.5. Message Transmission > >> >> To implement the congestion control, a queue length is set. If the >> queue is full, in order to queue a new message, a message of lower >> priority must be removed from the queue. If this is not possible, >> the new message MUST be discarded. The queue should be sorted in >> order of message priority. > > > I think it's more implementation details rather than specification. > > section 6.6 > >> >> The constants used inSection 6.7.1 this section are >> defined in Section 10. > > > misplaced reference > > > Oh, thanks. Fixed. > > > section 6.7.1 > > 4. Compare route costs >> * If AdvRte is better than all matching LocalRoutes, it SHOULD >> be used to update the Local Route Set because it offers >> improvement. >> >> *If it is not used to update the Local Route Set, the existing >> non-optimal LocalRoute will continue to be used, causing data >> traffic to use a non-optimal route.* > > > If some routers made the update, and some routers choose not updating, I'= m > afraid there will be loops in the network. > > VM> Agree, it would be stupid not to update. We've made this change. > * If AdvRte is worse and LocalRoute is valid, ignore AdvRte for >> further processing. AdvRte MUST NOT be used to update the >> Local Route Set because it does not offer any improvement. >> * If AdvRte is not better (i.e., it is worse or equal) but >> LocalRoute is Invalid, AdvRte SHOULD be used to update the >> Local Route Set because it can safely repair the existing >> Invalid LocalRoute. > > > shouldn=E2=80=99t worse AdvRte is already filtered by the LoopFree functi= on in the > previous step 3? > > section 6.7.2. Applying Route Updates > >> If there is no existing matching route, >> AdvRte allows a corresponding RREP to be sent. > > > I don't quite get why this relevant to RREP sending here. > > > Yeah=E2=80=A6 Honestly I don=E2=80=99t get this one either. I=E2=80=99d j= ust delete it? Anybody > against that? > > VM> Also happy to delete this sentence. > > >> 7. If an existing LocalRoute.State changed from Invalid or >> Unconfirmed to become Idle, any matching Unconfirmed LocalRoute >> with worse metric value SHOULD be expunged. >> 8. If an existing LocalRoute was updated with a better metric value, >> any matching Unconfirmed LocalRoute with worse metric value >> SHOULD be expunged. >> 9. If this update results in LocalRoute.State of Active or Idle, >> which matches a route request which is still in progress, the >> associated route request retry timers SHOULD be cancelled. > > > why "SHOULD", not "MUST" here? > > VM> I agree, I think this should be a MUST. > 6.8. Suppressing Redundant Messages Using the Multicast Route Message > Set > > the processes defined in this section overlap with section 6.7.1 (bullet > 1-2-3-4) > > section 6.10 Local route set maintenance > > >> During normal operation, AODVv2 does not require any explicit >> timeouts to manage the lifetime of a route. At any time, any >> LocalRoute MAY be examined and updated according to the rules below. >> If timers are not used to prompt updates of LocalRoute.State >> >> *, the LocalRoute.State MUST be checked before IP packet forwarding >> and before any operation based on LocalRoute.State*. >> > > I don't think this is an efficient approach. If the routing daemon runs i= n > user space (which is true in most cases), this normally means context > switch. This is inevitable for reactive protocols, but doing so per packe= t > seems to be expensive. > > > see above :) > > > > *section 7 AODVv2 Protocol Messages* > > general comments: > - the message regeneration, rather than the message forwarding, plus > different optional fields make the protocol hard to secure > > > fixed now > > - the tradeoff of using multicast RREP and RERR need to be carefully > considered. > - the tradeoff of using ValidityTime needs to be carefully considered > > > We=E2=80=99ve removed ValidityTime just now > > > section 7.1 > > >> PrefixLengthList >> Contains OrigPrefixLen, i.e., the length, in bits, of the prefix >> associated with the Router Client entry which includes OrigAddr. >> If omitted, the prefix length is equal to OrigAddr's address >> length in bits. > > > it seems that only one prefix length is needed, why "list"? > > > ValidityTime >> The length of time that the message sender is willing to offer a >> route toward OrigAddr (and any other addresses included in the >> given prefix length). Omitted if no time limit is imposed. > > > the necessity of using ValidityTime has been raised here > https://www.ietf.org/mail-archive/web/manet/current/msg18852.html > > >> 5. Include MetricType and set the type accordingly >> 6. Set OrigMetric :=3D RouterClient.Cost for the Router Client entry >> which includes OrigAddr > > > What if the metric type of the RouterClient.Cost is different from the > metric type to be used in the route discovery? In fact, this is quite > possible because they probably use different types of medium. > > VM> good point. I would say that the metric type requested should be one of the ones for which we have a routerclient.cost. See also my comment above about how there should be a cost per metrictype that can be used, and how to handle it if there isnt. > However, the regenerated RREQ can >> be unicast to the next hop address of the LocalRoute toward TargAddr, >> if known. > > > This can be a problem if the TargAddr is known to the routing set, but th= e > link is actually broken. Because there is no related RERR messages to > notify that, the following route discovery retries might fail also. A mor= e > careful design is required if unicast RREQ is to be used. > > VM> I think we removed this statement, and will always multicast a RREQ. > 7.2. Route Reply (RREP) Message > > I don't quite understand the purpose of multicast RREP. There are, > however, lots of disadvantages of using an optional AckReq field. > This has been discussed in another thread > https://www.ietf.org/mail-archive/web/manet/current/msg18864.html > > >> Before creating an RREP, the router SHOULD check if the corresponding >> RREQ is redundant, i.e., a Route Reply has already been generated in >> response to the RREQ, or if the limit for the rate of AODVv2 control >> message generation has been reached. If so, the RREP SHOULD NOT be >> created. > > > What about if the RREQ carries a better route? > > > Then it=E2=80=99s not redundant? Or do you mean the SHOULD NOT be created= part? > The idea of these priorities is that already established routes should be > protected before new routes are created, so even if the new RREQ is bette= r, > updating this route would strain the network even more, preventing routes > from working, which in turn triggers more RREQs.. etc etc. So I=E2=80=99d= say it=E2=80=99s > a pity but we have no other option but to drop the better RREQ? > > (I=E2=80=99ve also substituted =E2=80=9Ethe limit for the rate of AODVv2 = control message > generation=E2=80=9C for =E2=80=9E CONTROL_TRAFFIC_LIMIT=E2=80=9C in the D= raft now since that seemed > more concise ;) ) > > VM> The redundancy check is already done in RREQ reception. If the RREQ was redundant (ie stale, or cost was not better) then it would have been discarded. If it offered a better route, then we would send a new RREP. This text should just say about the limit for control message generation. > > 7.3.2 RREP_Ack Reception > > it seems that some action is missing after the step 2 Neighbour set > update. At least, we need to update the Local Route Set? > > VM> That's triggered by the Neighbor Set update (ie it's detailed in that section in the draft: When the Neighbor.State is set to Confirmed, any unconfirmed routes using that neighbor as a next hop can be marked as Idle, and therefore are valid for forwarding). I think it has also been added here though. > 7.4.1 RERR generation > > Is it necessary to generate RERR for RREP failure? > > VM> Yes, because routers back in the direction the RREP came from may hav= e installed the route to OrigAddr which is not available if the RREP failed to be forwarded, so they should be told, so that they delete it, and so that they dont use it to forward data, which would then get dropped (and a RERR would get sent then anyway). > > >> If there is no route to PktSource, the RERR SHOULD be >> multicast to LL-MANET-Routers. If the RERR is sent in response to a >> broken link, i.e., PktSource is not included, the RERR is, by >> default, multicast to LL-MANET-Routers. > > > Although I know the purpose of using RERR message is to inform as many > routers as possible about the route breakage information, it seems to be > huge overhead, and more importantly, an appealing attack vector for > hackers. > > VM> Should RERR only be sent if data is received to be forwarded along that route, in which case RERR can be an end-to-end message from the reporting router to PktSource? However, it means data packets will definitely be dropped before a route is reported as broken, whereas the one-hop RERR would help prevent dropped packets by deleting a route as soon as possible. I think the one-hop RERR is still very important. We do need to make sure the attack vector is discussed in Security Considerations. > 7.4.3 RERR regeneration > > 2. For each LocalRoute that needs to be reported as identified in >> Section 7.4.1: >> * Insert LocalRoute.Address into the AddressList. > > > The AddressList can changed on every RERR regeneration. On the other hand= , > in section 6.9 (suppressing redundant RERR), the uniqueness of RERR is > determined by AddressList and PktSource (optional). It seems to me that t= he > suppressing won't be able to work correctly? > > VM> The RERR Set might need to store the routes that have been advertised in a multicast RERR, rather than store the RERR itself? Anyway, suppression of _received_ RERR has nothing to do with this table. If we receive a RERR for a route we already deleted, we dont re-send that address in a regenerated RERR. It's suppressed by that. The table is only so that we don't send multiple RERRs if we are still receiving data packets which we no longer have a route for. VM> In {#suppressrerr} instead of "To determine if a received RERR is redundant:" it should say "To determine if a RERR should be created:" Also RERR.AddressList might be misleading: because its sent in response to an undeliverable packet, there's only one address in there. Maybe we should use RERR.UnreachableAddress in this whole section? > One more note: > > Jitter is not mentioned in the draft, which is important because the > multicast messages used. I can see RFC5148 in the reference section, but > didn't find where it is used. > > VM> We could say "The use of jitter in an implementation is RECOMMENDED b= y RFC5148" in the Message Transmission section? Kind regards, and thanks once again for your review, Victoria. > best > > Jiazi > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > Best regards, > Lotte > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --94eb2c123cfa8846540531f858ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jiazi,=C2=A0

Thank you for your revi= ew. I have a few comments to add, inline marked with "VM>".


On Thu, Apr 28, 2016 at 11:50 PM, Lotte Steenbrink <<= a href=3D"mailto:lotte.steenbrink@fu-berlin.de" target=3D"_blank">lotte.ste= enbrink@fu-berlin.de> wrote:
Hi Jiazi,
thank you for your detailed review.= A few comments and questions inline. (I wanted to get this reply out the d= oor as soon as I could, so I/we will follow up regarding the yet unresponde= d to items later)

Am 28.0= 4.2016 um 16:53 schrieb Jiazi YI <ietf@jiaziyi.com>:

Hi,=C2=A0

Here is my preliminary review on aodv= v2-15. There are still some points that I'm not sure that I have fully = understood -- I will get back to them if I had time.=C2=A0

A summary of my review:

1. The specificat= ion lacks of a "big picture" of the protocol functioning. People = prefer to have a general idea of the whole protocol at the very beginning. = This is particularly important for readers who are not familiar with reacti= ve protocol in general.=C2=A0
Some of the sections can be reorgan= ized a bit to improve the readability. For example, with the current struct= ure, the readers need to reach section 6.6 (Route discovery) before they ca= n really touch the core function of the protocol.=C2=A0

2. As an experimental protocol, the part related to experiments needs= to be improved. IMO, at least the following information must be provided:<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0- The motivation of this experimental = document=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0- The experiments to be= conducted=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0- What kind of feedba= ck is expected to reported. =C2=A0

3. There are so= me redundant processing procedures in the draft. On the other hand, some co= nnections between the sections seem to be missing. Sometimes it's hard = to build connection between the message processing and related information = bases.=C2=A0
I think this is partially due to the lack of impleme= ntation, or the implementation experience is not reported to the author tea= m?

4. The specification uses lots of multicast mes= sages. While multicast RREQ is inevitable, the necessity of multicast RREP/= RERR is not clear. It bring issues related to control message overhead and = security.=C2=A0

5. The interaction with RIB: The= =C2=A0route state maintenance=C2=A0requires "LocalRoute.State MUST = be checked before IP packet forwarding and before any operation based on Lo= calRoute.State.". Having such check for each data packet might be = heavy load for the system if the routing daemon runs in userspace (because = of context switch). While interaction with RIB is inevitable, we want to re= duce it as much as possible -- per data packet operation is too much.=C2=A0=

Hmmm. Yeah. To me it wou= ld make more sense to say "if you have a RIB, you MUST update it any t= ime LocalRoute.State changes [so instead of the polling described above, yo= u=E2=80=99d let the changes =E2=80=9Etrickle up=E2=80=9C and avid constant = context switches]. If you don=E2=80=99t have a RIB and LocalRoute is consul= ted directly when forwarding a packet [this would=E2=80=99ve been the case = in RIOT a few releases ago.. but there=E2=80=99s no kernel vs user space th= ere either, so you wouldn=E2=80=99t have the expensive context switches], y= ou MUST check LocalRoute.State before you forward to make sure the route is= still valid.=E2=80=9C ...

=C2= =A0
VM>=C2=A0That statement: = "LocalRoute.State MUST be checked= before IP packet forwarding=C2=A0=C2= =A0".... I think is for the case where you don't have timers runni= ng to handle timeouts. so before you do anything which depends on route sta= te, you need to check what the state should be. i.e., has the route gone fr= om idle to invalid. However, we also rely on knowledge of whether a route i= s being used to keep it in Active state, so there's another place we mi= ght want a per-packet operation.=C2=A0

6. There are too many "MAY" and &= quot;SHOULD" in the document without elaboration. Some of which might = cause interoperability issues or even loops.=C2=A0

8. security issues. There are discussions going on in different threads, s= o I won't repeat them here. I think the current regeneration-based appr= oach is complex to secure and hard for future extensions.=C2=A0

We=E2=80=99ve gotten rid of that ap= proach as of now. :)

I haven't checked the security considerations section in detail= yet. It's important to get the big direction right first.=C2=A0

Please check the details inline:

section 1, overview

= =C2=A0 =C2=A0The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protoc= ol
=C2=A0 =C2=A0enables dynamic, self-starting, multihop routing<= /blockquote>

The term "self-starting" is very = vague. It makes people think of auto-configuration. And I didn't see su= ch kind of feature is supported. I would avoid using it.=C2=A0
<= /div>

Makes sense. I=E2=80=99ve remov= ed the term.

=
=C2=A0 = AODVv2 is an Experimental protocol.
=C2=A0...
= =C2=A0
I think much more information is required here:

1) Because RFC 3561 has already been experimented for = 13 years, as its version 2, AODVv2 should summarize what kind of experience= s have been obtained in the past 13 years, and justify the design choices m= ade in the current draft (like use of RFC5444, removing some of the feature= s, etc)

2) The motivation and experiments to be co= nducted need to be elaborated. It's even necessary to have a separate s= ection/subsection for it. Some experiment points that come to my mind witho= ut much thinking: support of multiple interfaces, support of gateways, use = of different metrics, the security model, etc..

Fair enough.=C2=A0 Thank you for the detailed pointe= rs, I=E2=80=99ll write something up (unless my co-authors beat me to it ;) = ) and get back to you, if that=E2=80=99s okay?


=C2=A0 = =C2=A0The basic operations of the AODVv2 protocol are route discovery and=C2=A0 =C2=A0route maintenance...

I= t's necessary to give an overview of the basic functioning of the proto= col, rather than simply saying "use RREQ/RREP to carry information and= build routes". Because after this, the draft jumps directly into the = protocol details.=C2=A0
It's extremely important for the read= ers who are not familiar with reactive protocol.

Good point. we=E2=80=99ve removed =E2=80=9EThe basi= c operations of the AODVv2 protocol are route discovery and route maintenan= ce.=E2=80=9C, since that sentence occurs in the first paragraph already, an= d we=E2=80=99ve substituted the =E2=80=9EAn AODVv2 router is configured to = perform route discovery=E2=80=A6=E2=80=9C paragraph with:

=C2=A0 =C2=A0The basic protocol me= chanisms are as follows.=C2=A0 Since AODVv2 is a
=C2=A0 =C2=A0reactive protocol, route discovery is initiated = only when a route to
=C2=A0 =C2=A0t= he target is needed (i.e. when a router' client wants to send data).
=C2=A0 =C2=A0AODVv2 does this with th= e help of a Route Request (RREQ) and Route
=C2=A0 =C2=A0Reply (RREP) cycle: an RREQ is distributed across the = network until
=C2=A0 =C2=A0it arriv= es at the target.=C2=A0 When forwarding an RREQ, all routers
=C2=A0 =C2=A0across the network store the neighbo= r they've received the RREQ from,
=C2=A0 =C2=A0memorizing a possible route back to the originator of the R= REQ.=C2=A0 When
=C2=A0 =C2=A0the ta= rget receives the RREQ, it answers with an RREP, which then
=C2=A0 =C2=A0travels back to the originator along = the path memorized by the
=C2=A0 = =C2=A0intermediate routers.=C2=A0 A metric value is included within the mes= sages
=C2=A0 =C2=A0to record the co= st of the route.=C2=A0 AODVv2 uses sequence numbers to
=C2=A0 =C2=A0identify stale routing information, and co= mpares route metric values
=C2=A0 = =C2=A0to determine if advertised routes could form loops.

we=E2=80=99ve also slightly updated the language of th= e next pararaph:

=C2= =A0 =C2=A0Route maintenance includes confirming bidirectionality of links t= o
=C2=A0 =C2=A0next hop AODVv2 rout= ers and issuing Route Error (RERR) messages
=C2=A0 =C2=A0informing other routers of broken links.=C2=A0 It als= o includes reacting
=C2=A0 =C2=A0to= received Route Error messages, and extending and enforcing route
=C2=A0 =C2=A0timeouts.

What do you think?

=C2=A0

section 2, = Terminology

Please pay attention to the style = of the terms. Most of the time, style like AckReq is used, but sometimes RE= RR_Gen is used.=C2=A0
Good to be consistent.=C2=A0

I think I=E2=80=99ve pointed out a simi= lar issue too (in spring 2014, I think?), but I think I recall the conclusi= on being that while the draft should stick to CamelCase wherever it can, re= naming RERR_Gen to RERRGen would have a negative impact on readability, so = there are some exceptions to the rule=E2=80=A6


=C2=A0 = =C2=A0Unreachable Address
=C2=A0 =C2=A0 =C2=A0 An address reported in a = Route Error message, as described in
=C2=A0 =C2=A0 =C2=A0 Section 7.4.1.=

need to explain what's the addre= ss for exactly, rather than giving a pointer to a big section.=C2=A0
<= /div>

We had a longer explanation the= re but Justin said we should shorten it, so we did that and added the point= er=E2=80=A6 :D


section 3, applicability statement
=C2=A0 =C2=A0AODVv2 handles a wide variety= of mobility and traffic patterns by
=C2=A0 =C2=A0determining routes on-= demand...

It necessary to explicitly call o= ut what kind of traffic patterns that reactive protocols are not suitable f= or, such as lots of routers send data packets to instantaneous and multiple= destinations. If that happens, what's the consequence (broadcasting st= orm, etc).=C2=A0

Go= od point. We=E2=80=99ve reworded the paragraph to..

=C2=A0 =C2=A0AODVv2 handles a wide variety of= mobility and traffic patterns by
= =C2=A0 =C2=A0determining routes on-demand.=C2=A0 In networks with a large n= umber of
=C2=A0 =C2=A0routers, AODV= v2 is best suited for relatively sparse traffic
=C2=A0 =C2=A0scenarios where each router forwards IP packets t= o a small percentage
=C2=A0 =C2=A0o= f other AODVv2 routers in the network.=C2=A0 In this case fewer routes
=C2=A0 =C2=A0are needed, and therefore = less control traffic is produced.=C2=A0 In large
=C2=A0 =C2=A0networks with very frequent or bursty traffic, A= ODVv2 control
=C2=A0 =C2=A0messages= may cause a broadcast storm, overwhelming the network with
=C2=A0 =C2=A0control messages and preventing route= s from being established.=C2=A0 This
=C2=A0 =C2=A0especially applies to networks with point-to-point or point-= to-
=C2=A0 =C2=A0multipoint traffic= .=C2=A0 In this case, the transmission priorities
=C2=A0 =C2=A0described in Section 6.5 prioritize route maint= enance traffic over
=C2=A0 =C2=A0ro= ute discovery traffic.

<= /div>
=C2=A0 =C2=A0Data packets may be buffered = until a route to their destination is
=C2=A0 =C2=A0available, as described in Section 6.6.
Does that help?

=
=C2=A0
=C2=A0 =C2=A0AODVv2= provides for message integrity and security against replay
=C2=A0 =C2= =A0attacks by using integrity check values, timestamps and sequence
=C2= =A0 =C2=A0numbers, as described in Section 12.=C2=A0 If security associatio= ns can be
=C2=A0 =C2=A0established, encryption can be used for AODVv2 me= ssages to ensure
=C2=A0 =C2=A0that only trusted routers participate in r= outing operations.=C2=A0

We need to c= all out the hop-by-hop security model used, and the network MUST apply nece= ssary mechanisms to make sure that only trusted routers can participate in = routing operations.=C2=A0

We=E2=80=99re currently working on getting rid of the hop by hop trust mod= el in favor of end to end security. (I believe the thread is "Re: On F= orwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a = couple of big ticket Items)=E2=80=9C?)

<= div>
=C2=A0
=C2=A0 =C2=A0The rou= ting algorithm in AODVv2 MAY be operated at layers other than
=C2=A0 =C2= =A0the network layer, using layer-appropriate addresses.
<= br>
Considering the deep coupling between AODVv2 and IP, I don= 9;t see how it can work. This should be removed.=C2=A0

=
section 4 data structures

4.1 I= nterface set

The InterfaceSet is a conceptual dat= a structure which contains
=C2=A0 =C2=A0information about all interfaces= available to AODVv2.
...
Otherwise the InterfaceSet MAY be empty.

I'm not sure the sec MAY be empty -- a ro= uter contains at least one interface, no?=C2=A0

Yes, but if it knows it only has one and it has acce= ss to this information elsewhere and this won=E2=80=99t change, it might as= well save the bytes of stating this again=E2=80=A6 Iirc the idea was to gi= ve implementations for constrained devices a bit of leeway there.

=

4.2 rou= ter client set
=C2=A0 =C2=A0RouterClient.Cost
=C2= =A0 =C2=A0 =C2=A0 The cost associated with reaching this address or address= range.

Both "metric" and "c= ost" are used in the draft. If they are the same, please pick a term a= nd use it consistently.=C2=A0

=
Cost refers to the result of the Cost(L) function for the link to the = RouterClient. Would it make more sense it this entry was called LinkCost?
=C2=A0
The AODVv2 router adding the Router Client MUST wait for=
=C2=A0 =C2=A0any existing routing information about this Router Client = to be
=C2=A0 =C2=A0purged from the network, i.e., at least MAX_SEQNUM_LI= FETIME since the
=C2=A0 =C2=A0last SeqNum update on the router which is = removing this Router
=C2=A0 =C2=A0Client.=C2=A0

I'm not sure that I parsed this sentence correctly, but the add= ing/removing of router client seems to be more an external operation and ou= t of the control of routing protocol itself.=C2=A0

=E2=80=A6But even when it has no influence on whe= n/whether a router is added/removed, shouldn=E2=80=99t it still be able to = deal with the consequences? So if an AODVv2 outer is assigned a client that= has previously been attached to a different router, it should make sure it= doesn=E2=80=99t confuse the network (which is achieved by waiting >=3D = MAX_SEQNUM_LIFETIME before fully treating it as its own client)?

<= blockquote type=3D"cite">

4.3 neig= hbor set

=C2=A0Neighbor.State ... There are three= possible states: Confirmed, Unknown, and
=C2=A0 =C2=A0 =C2=A0 Blacklist= ed.=C2=A0 Unknown is the initial state.

I t= hink the "Unknown" is a bit confusing here. It's actually som= ething we already know -- a state that "we heard from that node, but b= i-directionality is not confirmed".=C2=A0
I think "Hear= d" is a more appropriate term to be used here.=C2=A0

4.4 sequence numbers

I think the compariso= n in wrap-around cases should be specified here.=C2=A0

=
Tod determine staleness,

t= ypo

Whoopsie, thanks

4.= 5 Local route set

Alternatively, implementations<= br>=C2=A0 =C2=A0MAY choose to modify the Routing Information Base directly.=

This should be either more precise (in whi= ch condition, how we can modify the RIB?), or be removed. =C2=A0

Isn=E2=80=99t the how really implem= entation specific?


=C2=A0
=C2=A0 =C2=A0Multiple val= id routes for the same address and prefix length but for
=C2=A0 =C2=A0di= fferent metric types may exist in the Local Route Set, but the
=C2=A0 = =C2=A0decision of which of these routes to install in the Routing
=C2=A0= =C2=A0Information Base to use for forwarding is outside the scope of
= =C2=A0 =C2=A0AODVv2.

It's OK, but maybe= some rules must be specified and followed. For example, the metric used mu= st be the same: if a packet is forwarded using metric A at router X, and th= en metric B at router Y, it's a obvious source of loops.=C2=A0

Of course, but that=E2=80=99s an = issue of properly establishing routes, which should be specified farther al= ong in the draft, shouldn=E2=80=99t it? The purpose of this paragraph is to= say =E2=80=9Eyou can have multiple valid routes (each following one metric= type) to the same destination, but we won=E2=80=99t specify how to pick wh= ich metric type is most important to you (i.e. which route you trust the mo= st).=E2=80=9C


4.6.=C2=A0 Multicast Route Message Set

Since this set is mainly for duplicate packet detection, I think s= ome of the fields are kind of redundant. For example, an RREQ/RREP message = can be identified by its originator's address and sequence number, why = 6 fields (OrigAddr, OrigFprefixLen, OrigSeqNum, TargAddr, TargPrefixLen, Ta= rgSeqNum) are necessary here.=C2=A0

= VM> I think this is right, the "targ"-related fields might wel= l be irrelevant, especially since we only put RREQ in that table now.=C2=A0= Not that important to change at this stage, I dont think, but maybe if the= res a tidy-up of the draft in future.=C2=A0
=
section 5 Metrics
=C2=A0 =C2=A0In Route Request messages, t= he metric describes the cost of the route
=C2=A0 =C2=A0from OrigAddr (an= d any other addresses included in the prefix length
=C2=A0 =C2=A0of RREQ= _Gen's Router Client entry for OrigAddr) to the router sending
=C2= =A0 =C2=A0the Route Request.=C2=A0

So= the metric carried in the RREQ is the metric from Router Client to the RRE= Q_Gen plus the metric from RREQ_Gen to the intermediate router.=C2=A0
=
In the Router Client Set, we have only one field for RouterClient.Cost= . On the other hand, "AODVv2 supports different metrics".=C2=A0

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 routerClient.cost =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 AODVv2 metric=C2=A0
client-----------------------RREQ_gen---------------
=
What if those two metrics are of different types? This is qu= ite possible because the two links might use different medium.=C2=A0
<= div>
VM> Good point. I guess the router client ent= ries need a number of costs, one for each metric type that will be supporte= d.
can we do something like=C2=A0
RouterClient.Costs =3D a number of {Metric= Type, Metric Value} pairs.

<= div style=3D"font-size:12.8px">And also maybe something like this?:
"The RouterClient.Cost is the init= ial metric value used in a route message originated at this router. A Cost = SHOULD be available for each MetricType configured for use. However, consid= er the case where a route with metric type MetricType is requested. If, at = RREQ_Gen, there is no corresponding Cost value for this MetricType in the R= outer Client entry for OrigAddr, the value of OrigMetric is set to zero=C2= =A0in the RREQ. Similarly, if the RREQ received at RREP_Gen requests a rout= e of a MetricType for which there is no Cost value in the Router Client ent= ry for TargAddr, the value of TargMetric is set to zero in the RREP."<= /span>=C2=A0

<= /div>
section 6 AODVv2 protocol Operations

=
General comments:=C2=A0

I think = this section is hard to read and needs some reconstruction. Generally speak= ing, people prefer begin from the important operations to have a big pictur= e/general idea of the protocol functioning, and then the details.=C2=A0
With the current organization, one needs to read till section 6.6 (R= oute discovery, retries and buffering) before he/she could reach the core f= unctioning of the protocol.=C2=A0

I don't quit= e get the current organization of sections either. For example:
<= br>
section 6.2 (Next hop monitoring) and section 6.3 (Neighbor s= et update) are very related. One is about the function, and one is about th= e corresponding operation. The following sections don't follow this pat= tern -- why not making them to one?

section 6.7.1 = (Evaluating route information) and section 6.8 (Suppressing redundant messa= ges using Multicast Route message set) seem to have some overlapped operati= ons. They all need to check the uniqueness of the messages, compare the met= rics and stop processing when duplication is detected. Although they are ap= plied to different information bases, they are doing the same thing.=C2=A0<= /div>

section 6.9 (suppressing redundant RERR messages u= sing the Route Error set) should obviously a part of section 6.10.2 (report= ing invalid routes), but it's a separate section with higher hierarchy.= =C2=A0

VM> In that case the same = would apply for use of the Multicast Route Message Set to stop redundant RR= EQs then? My opinion is that it's ok to have suppression as a protocol = operation, and to refer to it within the message processing section.= =C2=A0
=
more detail= s inline:

=C2=A0 =C2=A0If such a= n entry does not exist, a new entry is created as described
=C2=A0 =C2= =A0in Section 6.3. =C2=A0While the value of Neighbor.State is Unknown,=C2=A0 =C2=A0acknowledgement of RREP messages sent to that neighbor MUST = be
=C2=A0 =C2=A0requested. ...

I thi= nk we need to precise this is one for the case of RREP transmission.=C2=A0<= /div>

section 6.3

=C2=A0 =C2=A0If an external mechanism reports a link as broken, the Nei= ghbor Set
=C2=A0 =C2=A0entry SHOULD be removed.
<= br>
I don't know why SHOULD, not MUST is used here. In fact, = this is the only place that I found that a Neighbor Set entry to be removed= -- considering the network is with constrained devices in a dynamic enviro= nment, isn't a timer-based removing mechanisms is more adapted?
=C2=A0
=C2=A0 an RREP which answers a RREQ sent wi= thin RREQ_WAIT_TIME over the
=C2=A0 =C2=A0 =C2=A0 same interface as Neig= hbor.Interface

I'm not a native English= speaker, so I'm not sure about it should be "a RREP" or &quo= t;an RREP". But I think there is no reason to use them differently for= RREQ/RREP? Need to check the consistency in the whole draft.=C2=A0

The =E2=80=9Ea RREQ=E2=80= =9C is probably my fault, since I find that notation more intuitive as well= , but we=E2=80=99ve decided that it should be =E2=80=9Ean RREQ=E2=80=9C, be= cause you=E2=80=99d pronounce it =E2=80=9Earr-reck=E2=80=9C, which warrants= an =E2=80=9Ean=E2=80=9C in front of it. Thanks for the hint, I=E2=80=99ve = checked the draft and found more of these=C2=A0errors, all fixed now.
=

section 6.4.=C2=A0 Interaction with the Forwarding Plane
=

=C2=A0 =C2=A0o =C2=A0A route has been updat= ed: update the corresponding route in the
=C2=A0 =C2=A0 =C2=A0 Routing I= nformation Base.

Do we need to pay at= tention to the "multi-metrics" issue here? To support multi-metri= cs, do we need special fields in the RIB? If so, we need to call it out in = the applicability statement.=C2=A0

<= /div>
I=E2=80=99d guess it depends where you=E2=80=99re choosing one ro= ute over the other? If the RIB supports multiple metrics and can sort it ou= t that=E2=80=99s great, if not you might want to decide which route to prop= agate on to the RIB based on its metric, or you might want to =E2=80=9Etran= slate=E2=80=9C metrics into differently prioritized routes in the RIB? (if = that makes sense, it should probably be mentioned in=C2=A04.5.=C2=A0 Local = Route Set though)

=

section 6.5.=C2=A0 Message Transmission

=C2=A0 =C2=A0To implement the congestion control, a queue le= ngth is set.=C2=A0 If the
=C2=A0 =C2=A0queue is full, in order to queue = a new message, a message of lower
=C2=A0 =C2=A0priority must be removed = from the queue.=C2=A0 If this is not possible,
=C2=A0 =C2=A0the new mess= age MUST be discarded.=C2=A0 The queue should be sorted in
=C2=A0 =C2=A0= order of message priority.=C2=A0

I think it= 's more implementation details rather than specification. =C2=A0
<= div>
section 6.6=C2=A0

The constant= s used inSection 6.7.1 this section are
=C2=A0 =C2=A0defined in Section = 10.

misplaced reference

Oh, thanks. Fixed.


section 6.7.1

=C2=A0 =C2=A04.=C2=A0 Compare route costs<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0If AdvRte is better than all matching= LocalRoutes, it SHOULD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be used to up= date the Local Route Set because it offers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 improvement. =C2=A0If it is not used to update the Local Route Se= t,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the existing non-optimal LocalRout= e will continue to be used,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 causing d= ata traffic to use a non-optimal route.

If some routers made the update, and some routers choose not updatin= g, I'm afraid there will be loops in the network.=C2=A0

<= /div>
VM>=C2=A0Agree, it would be stupid not to update= . We've made this change.
=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0* =C2=A0If AdvRte is worse and LocalRoute is valid, ignore AdvRte for=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 further processing.=C2=A0 AdvRte MUS= T NOT be used to update the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Local Rou= te Set because it does not offer any improvement.
=C2=A0 =C2=A0 =C2=A0 = =C2=A0* =C2=A0If AdvRte is not better (i.e., it is worse or equal) but
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LocalRoute is Invalid, AdvRte SHOULD be = used to update the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Local Route Set be= cause it can safely repair the existing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Invalid LocalRoute.

shouldn=E2=80= =99t worse AdvRte is already filtered by the LoopFree function in the previ= ous step 3?

section 6.7.2.=C2=A0 Applying Rout= e Updates
If there is no existing matching r= oute,
=C2=A0 =C2=A0AdvRte allows a corresponding RREP to be sent.=C2=A0<= /blockquote>

I don't quite get why this releva= nt to RREP sending here.=C2=A0

Yeah=E2=80=A6 Honestly I don=E2=80=99t get this one either. I=E2=80= =99d just delete it? Anybody against that?

VM> Also happy to delete t= his sentence.=C2=A0=C2=A0
<= div>=C2=A0
=C2=A0 =C2=A07.=C2=A0 If an existing Local= Route.State changed from Invalid or
=C2=A0 =C2=A0 =C2=A0 =C2=A0Unconfirm= ed to become Idle, any matching Unconfirmed LocalRoute
=C2=A0 =C2=A0 =C2= =A0 =C2=A0with worse metric value SHOULD be expunged.
=C2=A0 =C2=A08.=C2= =A0 If an existing LocalRoute was updated with a better metric value,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0any matching Unconfirmed LocalRoute with worse m= etric value
=C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD be expunged.
=C2=A0 =C2= =A09.=C2=A0 If this update results in LocalRoute.State of Active or Idle,=C2=A0 =C2=A0 =C2=A0 =C2=A0which matches a route request which is still i= n progress, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0associated route request retr= y timers SHOULD be cancelled.

why "SHO= ULD", not "MUST" here?=C2=A0

VM> I agree, I think this should be a MUST.=C2=A0=C2=A0
6.8.=C2=A0 Sup= pressing Redundant Messages Using the Multicast Route Message
=C2= =A0 =C2=A0 =C2=A0 Set

the processes defined = in this section overlap with section 6.7.1 (bullet 1-2-3-4)

<= /div>
section 6.10 Local route set maintenance
=C2=A0
=C2=A0 =C2=A0During normal operation, AODVv2 does not requir= e any explicit
=C2=A0 =C2=A0timeouts to manage the lifetime of a route.= =C2=A0 At any time, any
=C2=A0 =C2=A0LocalRoute MAY be examined and upda= ted according to the rules below.
=C2=A0 =C2=A0If timers are not used to= prompt updates of LocalRoute.State, the
=C2=A0 =C2=A0LocalRoute.Stat= e MUST be checked before IP packet forwarding and
=C2=A0 =C2=A0before an= y operation based on LocalRoute.State.

<= div>I don't think this is an efficient approach. If the routing daemon = runs in user space (which is true in most cases), this normally means conte= xt switch. This is inevitable for reactive protocols, but doing so per pack= et seems to be expensive.=C2=A0

see above :)



section 7 AODVv2 Protocol Messages<= /b>

general comments:
=C2=A0 - the messa= ge regeneration, rather than the message forwarding, plus different optiona= l fields make the protocol hard to secure=C2=A0

fixed now

=C2=A0 - the tradeoff of using multicast RREP and RERR = need to be carefully considered.=C2=A0
=C2=A0 - the tradeoff of u= sing ValidityTime needs to be carefully considered

We=E2=80=99ve removed ValidityTime just now
=

sec= tion 7.1
=C2=A0
=C2=A0 =C2=A0PrefixLengthLi= st
=C2=A0 =C2=A0 =C2=A0 Contains OrigPrefixLen, i.e., the length, in bit= s, of the prefix
=C2=A0 =C2=A0 =C2=A0 associated with the Router Client = entry which includes OrigAddr.
=C2=A0 =C2=A0 =C2=A0 If omitted, the pref= ix length is equal to OrigAddr's address
=C2=A0 =C2=A0 =C2=A0 length= in bits.

it seems that only one prefix len= gth is needed, why "list"?


=C2=A0 =C2=A0ValidityTime
=C2=A0 =C2=A0 =C2=A0 The length = of time that the message sender is willing to offer a
=C2=A0 =C2=A0 =C2= =A0 route toward OrigAddr (and any other addresses included in the
=C2= =A0 =C2=A0 =C2=A0 given prefix length).=C2=A0 Omitted if no time limit is i= mposed.

the necessity of using ValidityTime= has been raised here=C2=A0https://www.ietf.org/mail-a= rchive/web/manet/current/msg18852.html
=C2=A0
=C2=A0 =C2=A05.=C2=A0 Include MetricType and set the type accor= dingly
=C2=A0 =C2=A06.=C2=A0 Set OrigMetric :=3D RouterClient.Cost for t= he Router Client entry
=C2=A0 =C2=A0 =C2=A0 =C2=A0which includes OrigAdd= r
=C2=A0
What if the metric type of the Ro= uterClient.Cost is different from the metric type to be used in the route d= iscovery? In fact, this is quite possible because they probably use differe= nt types of medium.=C2=A0

VM>=C2= =A0good point. I would say that the metric type requested should be one of = the ones for which we have a routerclient.cost. See also my comment above a= bout how there should be a cost per metrictype that can be used, and how to= handle it if there isnt.
=C2=A0
<= div dir=3D"ltr">
=C2=A0However, the regener= ated RREQ can
=C2=A0 =C2=A0be unicast to the next hop address of the Loc= alRoute toward TargAddr,
=C2=A0 =C2=A0if known.
<= br>
This can be a problem if the TargAddr is known to the routing= set, but the link is actually broken. Because there is no related RERR mes= sages to notify that, the following route discovery retries might fail also= . A more careful design is required if unicast RREQ is to be used.=C2=A0

<= div>VM>=C2=A0I think we removed this st= atement, and will always multicast a RREQ.=C2=A0=C2=A0
7.2.=C2=A0 Route Reply (RR= EP) Message

I don't quite understand the= purpose of multicast RREP. There are, however, lots of disadvantages of us= ing an optional AckReq field.=C2=A0
This has been discussed in an= other thread=C2=A0https://www.ietf.org/mail-archive/we= b/manet/current/msg18864.html
=C2=A0
= =C2=A0 =C2=A0Before creating an RREP, the router SHOULD check if the corres= ponding
=C2=A0 =C2=A0RREQ is redundant, i.e., a Route Reply has already = been generated in
=C2=A0 =C2=A0response to the RREQ, or if the limit for= the rate of AODVv2 control
=C2=A0 =C2=A0message generation has been rea= ched.=C2=A0 If so, the RREP SHOULD NOT be
=C2=A0 =C2=A0created.

What about if the RREQ carries a better route?

Then it=E2=80=99s not redunda= nt? Or do you mean the SHOULD NOT be created part? The idea of=C2=A0these p= riorities is that already established routes should be protected before new= routes are created, so even if the new RREQ is better, updating this route= would strain the network even more, preventing routes from working, which = in turn triggers more RREQs.. etc etc. So I=E2=80=99d say it=E2=80=99s a pi= ty but we have no other option but to drop the better RREQ?=C2=A0

(I=E2=80=99ve also substituted =E2=80=9Ethe limit for the rate o= f AODVv2 control message generation=E2=80=9C for =E2=80=9E CONTROL_TRAFFIC_= LIMIT=E2=80=9C in the Draft now since that seemed more concise ;) )

VM> The redundancy check is already done in RREQ reception. If the RREQ= was redundant (ie stale, or cost was not better) then it would have been d= iscarded. If it offered a better route, then we would send a new RREP. This= text should just say about the limit for control message generation.=C2=A0

=
7.3.2=C2=A0RREP_Ack Reception

it seems that s= ome action is missing after the step 2 Neighbour set update. At least, we n= eed to update the Local Route Set?

VM>=C2=A0That's triggered by the Neighbor Set update (ie it's= detailed in that section in the draft: When the Neighbor.State is set to C= onfirmed, any unconfirmed routes using that neighbor as a next hop can be m= arked as Idle, and therefore are valid for forwarding).=C2=A0 I thin= k it has also been added here though.
7.4.1 RERR generation

Is it ne= cessary to generate RERR for RREP failure?

=
VM>=C2=A0Yes, because routers back in the direction the RREP came= from may have installed the route to OrigAddr which is not available if th= e RREP failed to be forwarded, so they should be told, so that they delete = it, and so that they dont use it to forward data, which would then get drop= ped (and a RERR would get sent then anyway).=C2=A0
=C2=A0
= If there is no route to PktSource, the RERR SHOULD be
=C2=A0 =C2=A0multi= cast to LL-MANET-Routers.=C2=A0 If the RERR is sent in response to a
=C2= =A0 =C2=A0broken link, i.e., PktSource is not included, the RERR is, by
= =C2=A0 =C2=A0default, multicast to LL-MANET-Routers.

<= /div>
Although I know the purpose of using RERR message is to inform as= many routers as possible about the route breakage information, it seems to= be huge overhead, and more importantly, an appealing attack vector for hac= kers.=C2=A0

=
VM>=C2=A0Should RERR = only be sent if data is received to be forwarded along that route, in which= case RERR can be an end-to-end message from the reporting router to PktSou= rce? However, it means data packets will definitely be dropped before a rou= te is reported as broken, whereas the one-hop RERR would help prevent dropp= ed packets by deleting a route as soon as possible. I think the one-hop RER= R is still very important. We do need to make sure the attack vector is dis= cussed in Security Considerations.=C2=A0
7.4.3 RERR regeneration

<= div>
=C2=A0 =C2=A02.=C2=A0 For each LocalRoute that needs t= o be reported as identified in
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 7.4.1:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0Insert LocalRoute.Address into the A= ddressList.

The AddressList can chang= ed on every RERR regeneration. On the other hand, in section 6.9 (suppressi= ng redundant RERR), the uniqueness of RERR is determined by AddressList and= PktSource (optional). It seems to me that the suppressing won't be abl= e to work correctly?

VM> The RERR = Set might need to store the routes that have been advertised in a multicast= RERR, rather than store the RERR itself? Anyway,=C2=A0suppression of _rece= ived_ RERR has nothing to do with this table. If we receive a RERR for a ro= ute we already deleted, we dont re-send that address in a regenerated RERR.= It's suppressed by that. The table is only so that we don't send m= ultiple RERRs if we are still receiving data packets which we no longer hav= e a route for.

VM> In {#suppressrerr} instead of "To determine = if a received RERR is redundant:" it should say "To determine if = a RERR should be created:"
Also R= ERR.AddressList might be misleading: because its sent in response to an und= eliverable packet, there's only one address in there. Maybe we should u= se RERR.UnreachableAddress in this whole section?=C2=A0
=C2= =A0
One more note:=

Jitter is not mentioned in the draft, which is im= portant because the multicast messages used.=C2=A0 I can see RFC5148 in the= reference section, but didn't find where it is used.=C2=A0
<= br>
VM> We could say "The use of jitter in = an implementation is RECOMMENDED by RFC5148" in the Message Transmissi= on section?

Kind regards, and thanks on= ce again for your review,
Victoria.
best

Jiazi
<= br>
_______________________________________________
manet mailing list
manet@ietf.org
http= s://www.ietf.org/mailman/listinfo/manet

Best regards,
Lotte


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--94eb2c123cfa8846540531f858ce-- From nobody Tue May 3 17:30:19 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8697112D52F for ; Tue, 3 May 2016 17:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k7WgkUQs7eu for ; Tue, 3 May 2016 17:30:13 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F9B12B004 for ; Tue, 3 May 2016 17:30:13 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id u185so45204879iod.3 for ; Tue, 03 May 2016 17:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5MnkbBkXEYKGxAp6hWIt8Mhm4bA7JrBmmlVK+uD9u9s=; b=SrHd7ls7vIVzwkEHPt+VZbrFjXwoRpbrtclKzdYrRychn7RbOf2vkWu/caoGbxMK6R m460aM1sVYm7XjXJmvxNA0eacwSyrldOBgUNQK2OtpklDfgzY00dUQcqbNNw41XM1upk SaYtGTrwHtqCTlpI8C7AZJ2MDorslKabuLvg4K0UAQ9sIVqba8p64Lz0S9W6ug1MtV98 NjuuVFm1SMITEdbgAjt2iU4jYsanJwQbq2jSCMLHzNpfKNatFEmkZ3nl4vlKd3naWt4s EFhjSBkcSYRfZQH1uYEeT6nb0PuPRm7sA8VAgQJIZt9uDOp8Pl8vQWQoitngPLzqnjxo 53+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5MnkbBkXEYKGxAp6hWIt8Mhm4bA7JrBmmlVK+uD9u9s=; b=RRNyM3Jr792U272KE7l+hzZjJOgwbgVE+u9IJz0LQuh2YrLL3XviT/ZvijRGU1LYZv +C1a9cWeFaKjXQzyGMIgfgpM46L2yqqc1vaq9TqCFYze/q39uNXqqFdBKqR8eL9UkPch vPEL4ZC4xGZkX2dyXDpBaamU4VUdvmkdL5UsxAIANRBRUIo71zOGkdhxSG6zWJ6kKkNk WYU0v0eDTUMFwUS53wRXphbIdBLLyXe9SiA5MsyxnZsmtQbn3ehQnePZQJ3ggIjZIeZJ cR6jpyDb76OTy47tgvagwEcZBRclacofkvMEjvWwEdJUUK5T8N0KSEIp2qzrwUGdfpYS YaQQ== X-Gm-Message-State: AOPr4FVA0tZn77SOt5jpzpo4zbq2OAC1Cyr+jG5NMfGAmLZ7/t79WuJswtNixNGF+uOH0bDQ2p1IqS/8/h/UrA== MIME-Version: 1.0 X-Received: by 10.107.129.75 with SMTP id c72mr7104842iod.102.1462321812380; Tue, 03 May 2016 17:30:12 -0700 (PDT) Received: by 10.79.72.68 with HTTP; Tue, 3 May 2016 17:30:12 -0700 (PDT) In-Reply-To: References: <82679804-2647-4913-ACF3-18E4FFF731A8@thomasclausen.org> Date: Tue, 3 May 2016 20:30:12 -0400 Message-ID: From: Stan Ratliff To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a113f99b02cd0d60531f954bd Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Recharter Discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 00:30:17 -0000 --001a113f99b02cd0d60531f954bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christopher/All, Time to pick this discussion up again. What type of buy-in do you think is necessary? On the one hand, you discuss a "small team of authors"; on the other, you mention that we're "way short of what we really need in terms of buy-in". There has been interest expressed in addressing the MCAST issue, and volunteers (specifically, Justin, and probably Brian) to submit work. There is also a small number of potential authors interested in a few (three or so) DLEP extensions. Is there any OLSRv2 work on the horizon? Is there a definable, manageable problem space for things like cryptographic key management in ad hoc networks? We need to either come to consensus on a 12-18 month charter, or be prepared to close the WG. What is the interest level? Regards, Stan On Wed, Apr 27, 2016 at 12:35 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > OK, you know there are some people at NRL. Good. But still quite a way > short of what we really need in terms of buy-in. (I=E2=80=99m assuming th= e people > at NRL are represented by you and/or Brian, as otherwise even they aren= =E2=80=99t > showing up.) > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > *From:* Justin Dean [mailto:bebemaster@gmail.com] > *Sent:* 27 April 2016 16:45 > *To:* Dearlove, Christopher (UK) > *Cc:* Thomas Heide Clausen; manet@ietf.org > *Subject:* Re: [manet] Recharter Discussion > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > > > > > On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > The key points as I see it are: > > - We shouldn=E2=80=99t wait for telecon, and can=E2=80=99t rely on teleco= n and cut out > list. > > I agree. We shouldn't wait for the telecon. I'll continue to engage > everyone on this list about what people are willing to work on. > > > - We are very short of contributors. Many who have contributed have > dropped away. And those who have been main creators of WG RFCs (looking a= t > statistics, Clausen and Dearlove in particular, but also others - but not= a > lot of others, especially after the first batch of Experimental RFCs) may > or may not be contributing. > > We are short contributors and we may be able to get more by focusing the > group on specific issues and possibly creating new focused groups to invi= te > a larger/wider IETF involvement. Security being the one coming to mind. > Your mention on the list about security stuff that you are interested in > hasn't brought a lot of discussion on this list but it very well may brin= g > a lot of interest from the larger ietf community. > > > > - But even more importantly we need real people (preferably companies wit= h > products) using our protocols with real problems. DLEP I think has some > real adaptors, though I think most are waiting for an RFC. OLSRv2 is shor= t > on companies advertising they are using it - I wish some would (I=E2=80= =99m told > they exist, but couldn=E2=80=99t name any). AODVv2 (which may or may not = be in > scope) appears not to have even up to date experimental code (please > correct if wrong). > > - Hence although we may have some great ideas, it=E2=80=99s not yet clear= people > want them and we can deliver - DLEP maintenance being I think closest to > contradicting that, at least publicly. > > Well I KNOW that here at NRL we have the real people and prototype > products relating to the multicast issue that it can happen. The key issu= e > is making sure there are enough people willing to contribute and engineer= a > solution to an issue that needs solving. > > > > There is the horrible warning of Autoconf that went wrong in several ways= , > but at the end, had no one who would do the work (which is a lot of work, > taking longer than you expect) to create a draft and take it all the way. > And that means a small team of actual authors, plus wider input. > > > > Incidentally the autoconf problem is still real, but was too narrow. That > was considering address autoconfiguration (though the WG never actually g= ot > there). As I see it, there=E2=80=99s an inseparable (in terms of thinking= about it, > drafts may of course separate out details) issue that is of address > assignment, identity assignment/management, cryptographic key management, > and other forms of management (network management). And several chicken a= nd > egg problems that arise in them, especially in ad hoc networks. > > I think the issue with autoconf is that it was attempting to solve to > broad a problem. There were demonstratable solutions to very specific > problems (e.g. multihop DHCP) but then there were more exotic solutions t= o > more complex problems like DAD in disconnected partitioning/merging > networks. If we can focus on a specific well defined problem space I thin= k > we'll be fine. > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Thomas Heide > Clausen > *Sent:* 26 April 2016 22:01 > *To:* Justin Dean > *Cc:* manet@ietf.org > *Subject:* Re: [manet] Recharter Discussion > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > **** **WARNING ****** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > > > > On 26 avr. 2016, at 22:21, Justin Dean wrote: > > Thomas I understand your concerns but we have mostly gone over this befor= e > in previous meetings. > > > > The IETF conducts is business on mailing lists. > > > > My recollection is that the strawman charter was presented once in a WG > meeting, then the chairs did not animate any charter discussion for sever= al > IETFs, on the list (nor was the charter discussed in subsequent meetings)= - > until this present "urgency" was declared (by the chairs) to the WG. > > > > The AD will not allow us to meet at the next IETF meeting if we do not > have a new charter and new work items. > > > > That does not negate my point, however, which was that: > > > > it should be established on the list that there are *meaningful things to > do*, and there's a *meaningful critical mass of people to be doing those > things*, before a (virtual) interim is called. Brainstorming on a > teleconference is rarely a constructive way to spend time > > > > > > Thomas > > > > To your point it's imparative that the discussion continues on list about > the charter. With that in mind here is a suggested edit of the previousl= y > floated charter, with comments in () with JWD tags. > > The purpose of the MANET working group is to standardize IP routing proto= col functionality suitable for wireless routing application within both sta= tic and dynamic topologies with increased dynamics due to node motion or ot= her factors. > > > > Approaches are intended to be relatively lightweight in nature, suitable = for multiple hardware and wireless environments, and address scenarios wher= e MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh inf= rastructures (e.g., a mixture of fixed and mobile routers) should also be s= upported by MANET specifications and management features. > > > > The MANET WG is responsible for the maintenance of OLSRv2, AODVv2 (JWD TB= D), DLEP and NHPD. Of particular interest: security enhancements, and encry= ption security extensions for RFC5444. (JWD we may want to break this out o= f the WG and make a new MANET Sec working group to grab the attention of th= ose interested in security and get their participation.) > > > > The MANET WG will standardize a multicast MANET protocol framework based = on previous work and lessons learned for scoped forwarding within MANET net= works. As part of this framework the WG will produce a well defined MANET = multicast forwarding information base. > > > > The WG will produce an informational draft outlining challenges and best = practices for deploying and managing MANET networks. > > > > The MANET WG will interact with the PIM working group on issues relating = to the multicast work. The WG will also pay attention to other IETF and IR= TF work that is addressing topics related to MANET environments. > > > > In summary, the WG will develop the following drafts: > > > > MANET Management Document (Informational) > > MANET Maintenance > > - RFC5444 Security extension (Standards) (JWD possibly move this to new = working group) > > MANET Multicast > > - Multicast FIB (Standards) > > > > > > > > On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen > wrote: > > Hi, > > > > I believe that an virtual interim is premature: a teleconference is, > mechanically, less inclusive than are mailing list discussions (time-zone= s, > other commitments, requirement of synchronicity of participation, etc.). > > > > Furthermore.... > > > > Until such time that a strawman charter is proposed, *updated to reflect > the reality of the group* as stipulated by the AD and by Mr. Dean, as > well as additional charter items emerging on the list, and *with > relatively broad and deep support* for the included items by the working > group, having an interim - virtual or otherwise - is not constructive. > > > > In other words, it should be established on the list that there are *mean= ingful > things to do*, and there's a *meaningful critical mass of people to be > doing those things*, before a (virtual) interim is called. Brainstorming > on a teleconference is rarely a constructive way to spend time. > > > > Best, > > > > Thomas > > > > Sent from my iPad > > > > On 22 Apr 2016, at 17:50, Stan Ratliff wrote: > > Hello WG, > > > > Do we need to hold an interim meeting (via WebEX) to discuss? I'd like to > get opinions on the list about that. We'll need a couple of weeks to > schedule, but we can do that. > > > > One other point inline: > > > > On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > Multicast is the obvious top item. Lots of possible approaches, time to > discuss. > > > > Gateways for AODVv2 at Standard is obviously not possible since AODVv2 is > going to be Experimental at most. > > > > Management we did of course have an NHDP/OLSRv2 draft killed by AD. Which > since NHDP/OLSRv2 us all we have (SMF excepted) that was a bit tricky. > > > > I would have to make an IPR declaration to say some of what I might have > to say about encryption. Not today. > > > > Understood. But please remember - there's only about a 5-week gap now > before the charter needs to be complete in order for the WG to meet in > Berlin. > > > > Regards, > > Stan > > > > > > > > > > Missing from the list is any work on OLSRv2 (or NHDP). MT-OLSRv2 is > experimental. That would need implementation tests to advance to PS. Anyo= ne > interested in that (I=E2=80=99m not saying I can)? > > > > More broadly on OLSRv2 there are various things that could be done, but > what is really needed is people with a real application. Any that exist > were frightened away from this group. > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean > *Sent:* 22 April 2016 16:07 > *To:* manet@ietf.org > *Subject:* [manet] Recharter Discussion > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > **** **WARNING ****** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > I'll start things off by floating the draft re-charter which was presente= d > in Prague. > > The purpose of the MANET working group is to standardize IP routing proto= col functionality suitable for wireless routing application within both sta= tic and dynamic topologies with increased dynamics due to node motion or ot= her factors. > > > > Approaches are intended to be relatively lightweight in nature, suitable = for multiple hardware and wireless environments, and address scenarios wher= e MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh inf= rastructures (e.g., a mixture of fixed and mobile routers) should also be s= upported by MANET specifications and management features. > > > > The MANET WG is responsible for the maintenance of OLSRv2, AODVv2, DLEP a= nd NHPD. Of particular interest: border behavior between MANET networks and= fixed IP network infrastructures, enhance AODVv2 gateway functionality; se= curity enhancements, encryption security extensions for RFC5444. > > > > The MANET WG will standardize a multicast MANET protocol framework based = on previous work and lessons learned for scoped forwarding within MANET net= works. As part of this framework the WG will produce a well defined MANET = multicast forwarding information base. > > > > The WG will produce an informational draft outlining challenges and best = practices for deploying and managing MANET networks. > > > > The MANET WG will interact with the PIM working group on issues relating = to the multicast work. The WG will also pay attention to other IETF and IR= TF work that is addressing topics related to MANET environments. > > > > In summary, the WG will develop the following drafts: > > > > MANET Management Document (Informational) > > MANET Maintenance > > - RFC5444 Security extension (Standards) > > - Enhanced AODVv2 gateway extension (Standards) > > MANET Multicast > > - Multicast FIB (Standards) > > > > > > This will likely be considered too broad to pass. We will likely need to= cut some and focus the work. For me personally I know I have the time and= backing to work on the Multicast piece. > > > > Justin > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a113f99b02cd0d60531f954bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christopher/All,

Ti= me to pick this discussion up again. What type of buy-in do you think is ne= cessary? On the one hand, you discuss a "small team of authors"; = on the other, you mention that we're "way short of what we really = need in terms of buy-in".

There has been interest expres= sed in addressing the MCAST issue, and volunteers (specifically, Justin, an= d probably Brian) to submit work. There is also a small number of potential= authors interested in a few (three or so) DLEP extensions. Is there any OL= SRv2 work on the horizon? Is there a definable, manageable problem space fo= r things like cryptographic key management in ad hoc networks?

We need to either come to consensus on a 12-18 month charter, or be prepa= red to close the WG. What is the interest level?

Regards,
=
Stan

=
On Wed, Apr 27, 2016 at 12:35 PM, Dearlove, = Christopher (UK) <chris.dearlove@baesystems.com>= wrote:

OK, you know there are so= me people at NRL. Good. But still quite a way short of what we really need = in terms of buy-in. (I=E2=80=99m assuming the people at NRL are represented by you and/or Brian, as otherwise even they aren=E2=80=99t sho= wing up.)

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: Justin Dean [mailto:bebemaster@gmail.com]
Sent: 27 April 2016 16:45
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; manet@ietf.org
Subject: Re: [manet] Recharter Discussion

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments= or reply.
For= information regarding Red Flags that you can look out for in emails you receive, click here.
If = you feel the email is suspicious, please follow this process.<= /u>

=C2=A0

=C2=A0

On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

The key points as I see i= t are:

- We shouldn=E2=80=99t wa= it for telecon, and can=E2=80=99t rely on telecon and cut out list.<= u>

I agree.=C2=A0 We shouldn't wait for the telecon= .=C2=A0 I'll continue to engage everyone on this list about what people= are willing to work on.
=C2=A0

- We are very short of co= ntributors. Many who have contributed have dropped away. And those who have been main creators of WG RFCs (looking at statistics, Clausen and Dearlove= in particular, but also others - but not a lot of others, especially after= the first batch of Experimental RFCs) may or may not be contributing.

We are short contributors and we may be able to get = more by focusing the group on specific issues and possibly creating new foc= used groups to invite a larger/wider IETF involvement.=C2=A0 Security being= the one coming to mind.=C2=A0 Your mention on the list about security stuff that you are interested in hasn't bro= ught a lot of discussion on this list but it very well may bring a lot of i= nterest from the larger ietf community.=C2=A0

=C2=A0

- But even more important= ly we need real people (preferably companies with products) using our proto= cols with real problems. DLEP I think has some real adaptors, though I think mo= st are waiting for an RFC. OLSRv2 is short on companies advertising they ar= e using it - I wish some would (I=E2=80=99m told they exist, but couldn=E2= =80=99t name any). AODVv2 (which may or may not be in scope) appears not to have even up to date experimental code (please co= rrect if wrong).

- Hence although we may h= ave some great ideas, it=E2=80=99s not yet clear people want them and we ca= n deliver - DLEP maintenance being I think closest to contradicting that, at least p= ublicly.

Well I KNOW that here at NRL we have the real people= and prototype products relating to the multicast issue that it can happen.= The key issue is making sure there are enough people willing to contribute= and engineer a solution to an issue that needs solving.

=C2=A0=C2=A0

There is the horrible war= ning of Autoconf that went wrong in several ways, but at the end, had no one who would do the work (which is a lot of work, taking longer than you = expect) to create a draft and take it all the way. And that means a small t= eam of actual authors, plus wider input.

=C2=A0

Incidentally the autoconf= problem is still real, but was too narrow. That was considering address autoconfiguration (though the WG never actually got there). As I see it, t= here=E2=80=99s an inseparable (in terms of thinking about it, drafts may of= course separate out details) issue that is of address assignment, identity= assignment/management, cryptographic key management, and other forms of management (network management). And severa= l chicken and egg problems that arise in them, especially in ad hoc network= s.

I think the issue with autoconf is that it was attem= pting to solve to broad a problem.=C2=A0 There were demonstratable solution= s to very specific problems (e.g. multihop DHCP) but then there were more e= xotic solutions to more complex problems like DAD in disconnected partitioning/merging networks. If we can focus on= a specific well defined problem space I think we'll be fine. =C2=A0=C2= =A0

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)12= 45 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: manet [mailto:manet-= bounces@ietf.org] On Behalf Of Thomas Heide Clausen
Sent: 26 April 2016 22:01
To: Justin Dean
Cc: manet@ietf.o= rg
Subject: Re: [manet] Recharter Discussion

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments= or reply.
For= information regarding Red Flags that you can look out for in emails you receive, click here.
If = you feel the email is suspicious, please follow this process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside ou= r organization.

=C2=A0

=C2=A0<= /p>


On 26 avr. 2016, at 22:21, Justin Dean <bebemaster@gmail.com> wrote:=

Thomas I understand your concerns but we have mostly= gone over this before in previous meetings.

=C2=A0

The IETF conducts is business on mailing lists.

=C2=A0

My recollection is that the strawman charter was pre= sented once in a WG meeting, then the chairs did not animate any charter di= scussion for several IETFs, on the list (nor was the charter discussed in subsequent meetings) - until this present "urgen= cy" was declared (by the chairs) to the WG.

=C2=A0<= /p>

The AD will not allow us to meet at the next IETF me= eting if we do not have a new charter and new work items.=C2=A0

=C2=A0

That does not negate my point, however, which was th= at:

=C2=A0

it should be established= on the list that there are=C2=A0meaningful things to do, and= there's a=C2=A0meaningful critical mass of people to be doing those things, before a (virtual) interim is called. Brainsto= rming on a teleconference is rarely a constructive way to spend time=

=C2=A0

=C2=A0

Thomas

=C2=A0<= /p>

To your point it'= s imparative that the discussion continues on list about the charter.=C2=A0= With that in mind here is a suggested edit of the previously floated chart= er, with comments in () with JWD tags.

The purpose of the MANET working group is =
to standardize IP routing protocol functionality suitable for wireless rout=
ing application within both static and dynamic topologies with increased dy=
namics due to node motion or other factors.=C2=A0 

=C2=A0


Approaches are intended to be relatively l=
ightweight in nature, suitable for multiple hardware and wireless environme=
nts, and address scenarios where MANETs are deployed at the edges of an IP =
infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and m=
obile routers) should also be supported by MANET specifications and managem=
ent features.


=C2=A0


The MANET WG is responsible for the mainte=
nance of OLSRv2, AODVv2 (JWD TBD), DLEP and NHPD. Of particular interest: s=
ecurity enhancements, and encryption security extensions for RFC5444. (JWD =
we may want to break this out of the WG and make a new MANET Sec working gr=
oup to grab the attention of those interested in security and get their par=
ticipation.)


=C2=A0


The MANET WG will standardize a multicast =
MANET protocol framework based on previous work and lessons learned for sco=
ped forwarding within MANET networks.=C2=A0 As part of this framework the W=
G will produce a well defined MANET multicast forwarding information base.<=
/span>


=C2=A0


The WG will produce an informational draft=
 outlining challenges and best practices for deploying and managing MANET n=
etworks. 


=C2=A0


The MANET WG will interact with the PIM wo=
rking group on issues relating to the multicast work.=C2=A0 The WG will als=
o pay attention to other IETF and IRTF work that is addressing topics relat=
ed to MANET environments.


=C2=A0


In summary, the WG will develop the follow=
ing drafts:


=C2=A0


MANET Management Document (Informational)<=
/span>


MANET Maintenance 

=C2=A0- RFC5444 Security extension (Standa=
rds) (JWD possibly move this to new working group)

MANET Multicast


 - Multicast FIB (Standards)=





=C2=A0






=C2=A0

=C2=A0

On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen <= ietf@thomasclau= sen.org> wrote:

Hi,

=C2=A0

I believe that an virtual interim is premature: a te= leconference is, mechanically, less inclusive than are mailing list discuss= ions (time-zones, other commitments, requirement of synchronicity of participation, etc.).

=C2=A0

Furthermore....

=C2=A0

Until such time that a strawman charter is proposed, updated to reflect the reality of the group as stipulated by = the AD and by Mr. Dean, as well as additional charter items emerging on the= list, =C2=A0and with relatively broad and deep support for the included items= by the working group, having an interim - virtual or otherwise - is not co= nstructive.

=C2=A0

In other words, it should be established on the list= that there are meaningful things to do, and there's a meaningful c= ritical mass of people to be doing those things, before a (virtual)= interim is called. Brainstorming on a teleconference is rarely a construct= ive way to spend time.

=C2=A0<= /p>

Best,

=C2=A0<= /p>

Thomas

=C2=A0

Sent from my iPad

=C2=A0

On 22 Apr 2016, at 17= :50, Stan Ratliff <ratliffstan@gmail.com> wrote:

Hello WG,=C2=A0

=C2=A0

Do we need to hold an interim meeting (via WebEX) to= discuss? I'd like to get opinions on the list about that. We'll ne= ed a couple of weeks to schedule, but we can do that.=C2=A0

=C2=A0

One other point inline:=C2=A0

=C2=A0

On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christop= her (UK) <chris.dearlove@baesystems.com> wrote:

Multicast is the obvious = top item. Lots of possible approaches, time to discuss.

=C2=A0

Gateways for AODVv2 at St= andard is obviously not possible since AODVv2 is going to be Experimental at most.

=C2=A0

Management we did of cour= se have an NHDP/OLSRv2 draft killed by AD. Which since NHDP/OLSRv2 us all we have (SMF excepted) that was a bit tricky.

=C2=A0

I would have to make an I= PR declaration to say some of what I might have to say about encryption. Not today.

=C2=A0

Understood. But please remember - there's only a= bout a 5-week gap now before the charter needs to be complete in order for = the WG to meet in Berlin.=C2=A0

=C2=A0

Regards,

Stan

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Missing from the list is = any work on OLSRv2 (or NHDP). MT-OLSRv2 is experimental. That would need implementation tests to advance to PS. Anyone interested in that (I=E2=80= =99m not saying I can)?

=C2=A0

More broadly on OLSRv2 th= ere are various things that could be done, but what is really needed is people with a real application. Any that exist were frightened away from t= his group.

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)12= 45 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: manet [mailto:manet-= bounces@ietf.org] On Behalf Of Justin Dean
Sent: 22 April 2016 16:07
To: manet@ietf.o= rg
Subject: [manet] Recharter Discussion

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments= or reply.
For= information regarding Red Flags that you can look out for in emails you receive, click here.
If = you feel the email is suspicious, please follow this process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside ou= r organization.

=C2=A0

I'll start things= off by floating the draft re-charter which was presented in Prague. =C2=A0= 

The purpose of the MANET working group is =
to standardize IP routing protocol functionality suitable for wireless rout=
ing application within both static and dynamic topologies with increased dy=
namics due to node motion or other factors.=C2=A0 

=C2=A0


Approaches are intended to be relatively l=
ightweight in nature, suitable for multiple hardware and wireless environme=
nts, and address scenarios where MANETs are deployed at the edges of an IP =
infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and m=
obile routers) should also be supported by MANET specifications and managem=
ent features.


=C2=A0


The MANET WG is responsible for the mainte=
nance of OLSRv2, AODVv2, DLEP and NHPD. Of particular interest: border beha=
vior between MANET networks and fixed IP network infrastructures, enhance A=
ODVv2 gateway functionality; security enhancements, encryption security ext=
ensions for RFC5444. 


=C2=A0


The MANET WG will standardize a multicast =
MANET protocol framework based on previous work and lessons learned for sco=
ped forwarding within MANET networks.=C2=A0 As part of this framework the W=
G will produce a well defined MANET multicast forwarding information base.<=
/span>


=C2=A0


The WG will produce an informational draft=
 outlining challenges and best practices for deploying and managing MANET n=
etworks.


=C2=A0


The MANET WG will interact with the PIM wo=
rking group on issues relating to the multicast work.=C2=A0 The WG will als=
o pay attention to other IETF and IRTF work that is addressing topics relat=
ed to MANET environments.


=C2=A0


In summary, the WG will develop the follow=
ing drafts:


=C2=A0


MANET Management Document (Informational)<=
/span>


MANET Maintenance 

=C2=A0- RFC5444 Security extension (Standa=
rds)


 - Enhanced AODVv2 gateway extension (Stan=
dards)


MANET Multicast


 - Multicast FIB (Standards)=



=C2=A0


=C2=A0


This will likely be considered too broad t=
o pass.=C2=A0 We will likely need to cut some and focus the work.=C2=A0 For=
 me personally I know I have the time and backing to work on the Multicast =
piece.=C2=A0 


=C2=A0


Justin

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************=


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

=C2=A0

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


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

=C2=A0

=C2=A0


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a113f99b02cd0d60531f954bd-- From nobody Wed May 4 03:00:12 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE87A12D11D; Wed, 4 May 2016 03:00:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504100008.8315.79330.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 03:00:08 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-16.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 10:00:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing Authors : Charles E. Perkins Stan Ratliff John Dowdell Lotte Steenbrink Victoria Mercieca Filename : draft-ietf-manet-aodvv2-16.txt Pages : 84 Date : 2016-05-04 Abstract: The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-aodvv2-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 4 03:24:26 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EAB12D16D for ; Wed, 4 May 2016 03:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWvuMY1lVQw5 for ; Wed, 4 May 2016 03:24:21 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3977312D153 for ; Wed, 4 May 2016 03:24:20 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 4 May 2016 11:23:46 +0100 From: Rick Taylor To: "chris.dearlove@baesystems.com" , "ratliffstan@gmail.com" Thread-Topic: [manet] Recharter Discussion Thread-Index: AQHRnKiksGy1agZ/WUiPgMtfl0/GKp+WEeoAgAABcQCABnzxAIAAGCgAgAAK5YCAANjSgIAAYTUAgAAOIoCACfKmAIAApa6A Date: Wed, 4 May 2016 10:23:11 +0000 Message-ID: <1462357391.8100.57.camel@tropicalstormsoftware.com> References: <82679804-2647-4913-ACF3-18E4FFF731A8@thomasclausen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Recharter Discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 10:24:25 -0000 QWxsLA0KDQpUaGVyZSBhcmUgc2V2ZXJhbCBETEVQIGV4dGVuc2lvbiBkcmFmdHMgYWxyZWFkeSBp biBjaXJjdWxhdGlvbiwgc28gbm8NCm1hdHRlciB3aGF0IGhhcHBlbnMgdG8gTUFORVQsIEkgd291 bGQgbGlrZSB0aGVyZSB0byBiZSBzb21lIGhvbWUgZm9yDQpmdXJ0aGVyIERMRVAgd29yay4gIE15 IHByZWZlcmVuY2Ugd291bGQgYmUgZm9yIGEgTUFORVQgcmUtY2hhcnRlcg0KaW5jbHVkaW5nIERM RVAuDQoNCkNoZWVycywNCg0KUmljaw0KDQoNCk9uIFR1ZSwgMjAxNi0wNS0wMyBhdCAyMDozMCAt MDQwMCwgU3RhbiBSYXRsaWZmIHdyb3RlOg0KPiBDaHJpc3RvcGhlci9BbGwsDQo+DQo+IFRpbWUg dG8gcGljayB0aGlzIGRpc2N1c3Npb24gdXAgYWdhaW4uIFdoYXQgdHlwZSBvZiBidXktaW4gZG8g eW91DQo+IHRoaW5rIGlzIG5lY2Vzc2FyeT8gT24gdGhlIG9uZSBoYW5kLCB5b3UgZGlzY3VzcyBh ICJzbWFsbCB0ZWFtIG9mDQo+IGF1dGhvcnMiOyBvbiB0aGUgb3RoZXIsIHlvdSBtZW50aW9uIHRo YXQgd2UncmUgIndheSBzaG9ydCBvZiB3aGF0IHdlDQo+IHJlYWxseSBuZWVkIGluIHRlcm1zIG9m IGJ1eS1pbiIuDQo+DQo+IFRoZXJlIGhhcyBiZWVuIGludGVyZXN0IGV4cHJlc3NlZCBpbiBhZGRy ZXNzaW5nIHRoZSBNQ0FTVCBpc3N1ZSwgYW5kDQo+IHZvbHVudGVlcnMgKHNwZWNpZmljYWxseSwg SnVzdGluLCBhbmQgcHJvYmFibHkgQnJpYW4pIHRvIHN1Ym1pdCB3b3JrLg0KPiBUaGVyZSBpcyBh bHNvIGEgc21hbGwgbnVtYmVyIG9mIHBvdGVudGlhbCBhdXRob3JzIGludGVyZXN0ZWQgaW4gYSBm ZXcNCj4gKHRocmVlIG9yIHNvKSBETEVQIGV4dGVuc2lvbnMuIElzIHRoZXJlIGFueSBPTFNSdjIg d29yayBvbiB0aGUNCj4gaG9yaXpvbj8gSXMgdGhlcmUgYSBkZWZpbmFibGUsIG1hbmFnZWFibGUg cHJvYmxlbSBzcGFjZSBmb3IgdGhpbmdzDQo+IGxpa2UgY3J5cHRvZ3JhcGhpYyBrZXkgbWFuYWdl bWVudCBpbiBhZCBob2MgbmV0d29ya3M/DQo+DQo+IFdlIG5lZWQgdG8gZWl0aGVyIGNvbWUgdG8g Y29uc2Vuc3VzIG9uIGEgMTItMTggbW9udGggY2hhcnRlciwgb3IgYmUNCj4gcHJlcGFyZWQgdG8g Y2xvc2UgdGhlIFdHLiBXaGF0IGlzIHRoZSBpbnRlcmVzdCBsZXZlbD8NCj4NCj4gUmVnYXJkcywN Cj4gU3Rhbg0KPg0KPg0KPiBPbiBXZWQsIEFwciAyNywgMjAxNiBhdCAxMjozNSBQTSwgRGVhcmxv dmUsIENocmlzdG9waGVyIChVSykgPA0KPiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4g d3JvdGU6DQo+ID4gT0ssIHlvdSBrbm93IHRoZXJlIGFyZSBzb21lIHBlb3BsZSBhdCBOUkwuIEdv b2QuIEJ1dCBzdGlsbCBxdWl0ZSBhDQo+ID4gd2F5IHNob3J0IG9mIHdoYXQgd2UgcmVhbGx5IG5l ZWQgaW4gdGVybXMgb2YgYnV5LWluLiAoSeKAmW0gYXNzdW1pbmcNCj4gPiB0aGUgcGVvcGxlIGF0 IE5STCBhcmUgcmVwcmVzZW50ZWQgYnkgeW91IGFuZC9vciBCcmlhbiwgYXMgb3RoZXJ3aXNlDQo+ ID4gZXZlbiB0aGV5IGFyZW7igJl0IHNob3dpbmcgdXAuKQ0KPiA+DQo+ID4gLS0NCj4gPg0KPiA+ IENocmlzdG9waGVyIERlYXJsb3ZlDQo+ID4gU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KPiA+ IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBfX19fX19fDQo+ID4NCj4gPiBUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBF OiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbQ0KPiA+DQo+ID4gQkFFIFN5c3RlbXMgQXBw bGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdA0KPiA+ IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCj4gPiB3d3cuYmFlc3lzdGVtcy5j b20vYWkNCj4gPg0KPiA+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQN Cj4gPiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENCj4gPiBSZWdp c3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBH VTIgN1lQDQo+ID4NCj4gPg0KPiA+IEZyb206IEp1c3RpbiBEZWFuIFttYWlsdG86YmViZW1hc3Rl ckBnbWFpbC5jb21dDQo+ID4gU2VudDogMjcgQXByaWwgMjAxNiAxNjo0NQ0KPiA+IFRvOiBEZWFy bG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KPiA+IENjOiBUaG9tYXMgSGVpZGUgQ2xhdXNlbjsgbWFu ZXRAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW21hbmV0XSBSZWNoYXJ0ZXIgRGlzY3Vzc2lv bg0KPiA+DQo+ID4NCj4gPiAqKiogV0FSTklORyAqKioNCj4gPiBUaGlzIG1lc3NhZ2Ugb3JpZ2lu YXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20NCj4gPiBhbiBl eHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCj4gPiBDb25zaWRlciBjYXJlZnVsbHkg d2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkNCj4gPiBhdHRh Y2htZW50cyBvciByZXBseS4NCj4gPiBGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFn cyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluDQo+ID4gZW1haWxzIHlvdSByZWNlaXZlLCBj bGljayBoZXJlLg0KPiA+IElmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVh c2UgZm9sbG93IHRoaXMgcHJvY2Vzcy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiBXZWQsIEFwciAy NywgMjAxNiBhdCA1OjU2IEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8DQo+ID4gY2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+IHdyb3RlOg0KPiA+IFRoZSBrZXkgcG9pbnRzIGFz IEkgc2VlIGl0IGFyZToNCj4gPiAtIFdlIHNob3VsZG7igJl0IHdhaXQgZm9yIHRlbGVjb24sIGFu ZCBjYW7igJl0IHJlbHkgb24gdGVsZWNvbiBhbmQgY3V0DQo+ID4gb3V0IGxpc3QuDQo+ID4gSSBh Z3JlZS4gIFdlIHNob3VsZG4ndCB3YWl0IGZvciB0aGUgdGVsZWNvbi4gIEknbGwgY29udGludWUg dG8NCj4gPiBlbmdhZ2UgZXZlcnlvbmUgb24gdGhpcyBsaXN0IGFib3V0IHdoYXQgcGVvcGxlIGFy ZSB3aWxsaW5nIHRvIHdvcmsNCj4gPiBvbi4NCj4gPg0KPiA+IC0gV2UgYXJlIHZlcnkgc2hvcnQg b2YgY29udHJpYnV0b3JzLiBNYW55IHdobyBoYXZlIGNvbnRyaWJ1dGVkIGhhdmUNCj4gPiBkcm9w cGVkIGF3YXkuIEFuZCB0aG9zZSB3aG8gaGF2ZSBiZWVuIG1haW4gY3JlYXRvcnMgb2YgV0cgUkZD cw0KPiA+IChsb29raW5nIGF0IHN0YXRpc3RpY3MsIENsYXVzZW4gYW5kIERlYXJsb3ZlIGluIHBh cnRpY3VsYXIsIGJ1dA0KPiA+IGFsc28gb3RoZXJzIC0gYnV0IG5vdCBhIGxvdCBvZiBvdGhlcnMs IGVzcGVjaWFsbHkgYWZ0ZXIgdGhlIGZpcnN0DQo+ID4gYmF0Y2ggb2YgRXhwZXJpbWVudGFsIFJG Q3MpIG1heSBvciBtYXkgbm90IGJlIGNvbnRyaWJ1dGluZy4NCj4gPiBXZSBhcmUgc2hvcnQgY29u dHJpYnV0b3JzIGFuZCB3ZSBtYXkgYmUgYWJsZSB0byBnZXQgbW9yZSBieQ0KPiA+IGZvY3VzaW5n IHRoZSBncm91cCBvbiBzcGVjaWZpYyBpc3N1ZXMgYW5kIHBvc3NpYmx5IGNyZWF0aW5nIG5ldw0K PiA+IGZvY3VzZWQgZ3JvdXBzIHRvIGludml0ZSBhIGxhcmdlci93aWRlciBJRVRGIGludm9sdmVt ZW50LiAgU2VjdXJpdHkNCj4gPiBiZWluZyB0aGUgb25lIGNvbWluZyB0byBtaW5kLiAgWW91ciBt ZW50aW9uIG9uIHRoZSBsaXN0IGFib3V0DQo+ID4gc2VjdXJpdHkgc3R1ZmYgdGhhdCB5b3UgYXJl IGludGVyZXN0ZWQgaW4gaGFzbid0IGJyb3VnaHQgYSBsb3Qgb2YNCj4gPiBkaXNjdXNzaW9uIG9u IHRoaXMgbGlzdCBidXQgaXQgdmVyeSB3ZWxsIG1heSBicmluZyBhIGxvdCBvZg0KPiA+IGludGVy ZXN0IGZyb20gdGhlIGxhcmdlciBpZXRmIGNvbW11bml0eS4NCj4gPg0KPiA+IC0gQnV0IGV2ZW4g bW9yZSBpbXBvcnRhbnRseSB3ZSBuZWVkIHJlYWwgcGVvcGxlIChwcmVmZXJhYmx5DQo+ID4gY29t cGFuaWVzIHdpdGggcHJvZHVjdHMpIHVzaW5nIG91ciBwcm90b2NvbHMgd2l0aCByZWFsIHByb2Js ZW1zLg0KPiA+IERMRVAgSSB0aGluayBoYXMgc29tZSByZWFsIGFkYXB0b3JzLCB0aG91Z2ggSSB0 aGluayBtb3N0IGFyZQ0KPiA+IHdhaXRpbmcgZm9yIGFuIFJGQy4gT0xTUnYyIGlzIHNob3J0IG9u IGNvbXBhbmllcyBhZHZlcnRpc2luZyB0aGV5DQo+ID4gYXJlIHVzaW5nIGl0IC0gSSB3aXNoIHNv bWUgd291bGQgKEnigJltIHRvbGQgdGhleSBleGlzdCwgYnV0IGNvdWxkbuKAmXQNCj4gPiBuYW1l IGFueSkuIEFPRFZ2MiAod2hpY2ggbWF5IG9yIG1heSBub3QgYmUgaW4gc2NvcGUpIGFwcGVhcnMg bm90IHRvDQo+ID4gaGF2ZSBldmVuIHVwIHRvIGRhdGUgZXhwZXJpbWVudGFsIGNvZGUgKHBsZWFz ZSBjb3JyZWN0IGlmIHdyb25nKS4NCj4gPiAtIEhlbmNlIGFsdGhvdWdoIHdlIG1heSBoYXZlIHNv bWUgZ3JlYXQgaWRlYXMsIGl04oCZcyBub3QgeWV0IGNsZWFyDQo+ID4gcGVvcGxlIHdhbnQgdGhl bSBhbmQgd2UgY2FuIGRlbGl2ZXIgLSBETEVQIG1haW50ZW5hbmNlIGJlaW5nIEkNCj4gPiB0aGlu ayBjbG9zZXN0IHRvIGNvbnRyYWRpY3RpbmcgdGhhdCwgYXQgbGVhc3QgcHVibGljbHkuDQo+ID4g V2VsbCBJIEtOT1cgdGhhdCBoZXJlIGF0IE5STCB3ZSBoYXZlIHRoZSByZWFsIHBlb3BsZSBhbmQg cHJvdG90eXBlDQo+ID4gcHJvZHVjdHMgcmVsYXRpbmcgdG8gdGhlIG11bHRpY2FzdCBpc3N1ZSB0 aGF0IGl0IGNhbiBoYXBwZW4uIFRoZQ0KPiA+IGtleSBpc3N1ZSBpcyBtYWtpbmcgc3VyZSB0aGVy ZSBhcmUgZW5vdWdoIHBlb3BsZSB3aWxsaW5nIHRvDQo+ID4gY29udHJpYnV0ZSBhbmQgZW5naW5l ZXIgYSBzb2x1dGlvbiB0byBhbiBpc3N1ZSB0aGF0IG5lZWRzIHNvbHZpbmcuDQo+ID4NCj4gPiBU aGVyZSBpcyB0aGUgaG9ycmlibGUgd2FybmluZyBvZiBBdXRvY29uZiB0aGF0IHdlbnQgd3Jvbmcg aW4NCj4gPiBzZXZlcmFsIHdheXMsIGJ1dCBhdCB0aGUgZW5kLCBoYWQgbm8gb25lIHdobyB3b3Vs ZCBkbyB0aGUgd29yaw0KPiA+ICh3aGljaCBpcyBhIGxvdCBvZiB3b3JrLCB0YWtpbmcgbG9uZ2Vy IHRoYW4geW91IGV4cGVjdCkgdG8gY3JlYXRlIGENCj4gPiBkcmFmdCBhbmQgdGFrZSBpdCBhbGwg dGhlIHdheS4gQW5kIHRoYXQgbWVhbnMgYSBzbWFsbCB0ZWFtIG9mDQo+ID4gYWN0dWFsIGF1dGhv cnMsIHBsdXMgd2lkZXIgaW5wdXQuDQo+ID4NCj4gPiBJbmNpZGVudGFsbHkgdGhlIGF1dG9jb25m IHByb2JsZW0gaXMgc3RpbGwgcmVhbCwgYnV0IHdhcyB0b28NCj4gPiBuYXJyb3cuIFRoYXQgd2Fz IGNvbnNpZGVyaW5nIGFkZHJlc3MgYXV0b2NvbmZpZ3VyYXRpb24gKHRob3VnaCB0aGUNCj4gPiBX RyBuZXZlciBhY3R1YWxseSBnb3QgdGhlcmUpLiBBcyBJIHNlZSBpdCwgdGhlcmXigJlzIGFuIGlu c2VwYXJhYmxlDQo+ID4gKGluIHRlcm1zIG9mIHRoaW5raW5nIGFib3V0IGl0LCBkcmFmdHMgbWF5 IG9mIGNvdXJzZSBzZXBhcmF0ZSBvdXQNCj4gPiBkZXRhaWxzKSBpc3N1ZSB0aGF0IGlzIG9mIGFk ZHJlc3MgYXNzaWdubWVudCwgaWRlbnRpdHkNCj4gPiBhc3NpZ25tZW50L21hbmFnZW1lbnQsIGNy eXB0b2dyYXBoaWMga2V5IG1hbmFnZW1lbnQsIGFuZCBvdGhlcg0KPiA+IGZvcm1zIG9mIG1hbmFn ZW1lbnQgKG5ldHdvcmsgbWFuYWdlbWVudCkuIEFuZCBzZXZlcmFsIGNoaWNrZW4gYW5kDQo+ID4g ZWdnIHByb2JsZW1zIHRoYXQgYXJpc2UgaW4gdGhlbSwgZXNwZWNpYWxseSBpbiBhZCBob2MgbmV0 d29ya3MuDQo+ID4gSSB0aGluayB0aGUgaXNzdWUgd2l0aCBhdXRvY29uZiBpcyB0aGF0IGl0IHdh cyBhdHRlbXB0aW5nIHRvIHNvbHZlDQo+ID4gdG8gYnJvYWQgYSBwcm9ibGVtLiAgVGhlcmUgd2Vy ZSBkZW1vbnN0cmF0YWJsZSBzb2x1dGlvbnMgdG8gdmVyeQ0KPiA+IHNwZWNpZmljIHByb2JsZW1z IChlLmcuIG11bHRpaG9wIERIQ1ApIGJ1dCB0aGVuIHRoZXJlIHdlcmUgbW9yZQ0KPiA+IGV4b3Rp YyBzb2x1dGlvbnMgdG8gbW9yZSBjb21wbGV4IHByb2JsZW1zIGxpa2UgREFEIGluIGRpc2Nvbm5l Y3RlZA0KPiA+IHBhcnRpdGlvbmluZy9tZXJnaW5nIG5ldHdvcmtzLiBJZiB3ZSBjYW4gZm9jdXMg b24gYSBzcGVjaWZpYyB3ZWxsDQo+ID4gZGVmaW5lZCBwcm9ibGVtIHNwYWNlIEkgdGhpbmsgd2Un bGwgYmUgZmluZS4NCj4gPg0KPiA+IC0tDQo+ID4NCj4gPiBDaHJpc3RvcGhlciBEZWFybG92ZQ0K PiA+IFNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCj4gPiBCQUUgU3lzdGVtcyBBcHBsaWVkIElu dGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gX19fX19fXw0KPiA+ DQo+ID4gVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20NCj4gPg0KPiA+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVs bXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQNCj4gPiBCYWRkb3csIENoZWxtc2ZvcmQsIEVz c2V4IENNMiA4SE4uDQo+ID4gd3d3LmJhZXN5c3RlbXMuY29tL2FpDQo+ID4NCj4gPiBCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQo+ID4gUmVnaXN0ZXJlZCBpbiBFbmds YW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQo+ID4gUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBS ZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KPiA+DQo+ID4NCj4gPiBG cm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBU aG9tYXMNCj4gPiBIZWlkZSBDbGF1c2VuDQo+ID4gU2VudDogMjYgQXByaWwgMjAxNiAyMjowMQ0K PiA+IFRvOiBKdXN0aW4gRGVhbg0KPiA+IENjOiBtYW5ldEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6 IFJlOiBbbWFuZXRdIFJlY2hhcnRlciBEaXNjdXNzaW9uDQo+ID4NCj4gPg0KPiA+ICoqKiBXQVJO SU5HICoqKg0KPiA+IFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3Jn YW5pc2F0aW9uLCBlaXRoZXIgZnJvbQ0KPiA+IGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGlu dGVybmV0Lg0KPiA+IENvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sg b24gYW55IGxpbmtzLCBvcGVuIGFueQ0KPiA+IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KPiA+IEZv ciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBm b3IgaW4NCj4gPiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmUuDQo+ID4gSWYgeW91IGZl ZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzLg0K PiA+DQo+ID4gKioqIFdBUk5JTkcgKioqDQo+ID4gRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNz YWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91cg0KPiA+IG9yZ2FuaXphdGlvbi4NCj4gPg0K PiA+DQo+ID4NCj4gPg0KPiA+IE9uIDI2IGF2ci4gMjAxNiwgYXQgMjI6MjEsIEp1c3RpbiBEZWFu IDxiZWJlbWFzdGVyQGdtYWlsLmNvbT4NCj4gPiB3cm90ZToNCj4gPg0KPiA+IFRob21hcyBJIHVu ZGVyc3RhbmQgeW91ciBjb25jZXJucyBidXQgd2UgaGF2ZSBtb3N0bHkgZ29uZSBvdmVyIHRoaXMN Cj4gPiBiZWZvcmUgaW4gcHJldmlvdXMgbWVldGluZ3MuDQo+ID4NCj4gPiBUaGUgSUVURiBjb25k dWN0cyBpcyBidXNpbmVzcyBvbiBtYWlsaW5nIGxpc3RzLg0KPiA+DQo+ID4gTXkgcmVjb2xsZWN0 aW9uIGlzIHRoYXQgdGhlIHN0cmF3bWFuIGNoYXJ0ZXIgd2FzIHByZXNlbnRlZCBvbmNlIGluDQo+ ID4gYSBXRyBtZWV0aW5nLCB0aGVuIHRoZSBjaGFpcnMgZGlkIG5vdCBhbmltYXRlIGFueSBjaGFy dGVyDQo+ID4gZGlzY3Vzc2lvbiBmb3Igc2V2ZXJhbCBJRVRGcywgb24gdGhlIGxpc3QgKG5vciB3 YXMgdGhlIGNoYXJ0ZXINCj4gPiBkaXNjdXNzZWQgaW4gc3Vic2VxdWVudCBtZWV0aW5ncykgLSB1 bnRpbCB0aGlzIHByZXNlbnQgInVyZ2VuY3kiDQo+ID4gd2FzIGRlY2xhcmVkIChieSB0aGUgY2hh aXJzKSB0byB0aGUgV0cuDQo+ID4NCj4gPg0KPiA+IFRoZSBBRCB3aWxsIG5vdCBhbGxvdyB1cyB0 byBtZWV0IGF0IHRoZSBuZXh0IElFVEYgbWVldGluZyBpZiB3ZSBkbw0KPiA+IG5vdCBoYXZlIGEg bmV3IGNoYXJ0ZXIgYW5kIG5ldyB3b3JrIGl0ZW1zLg0KPiA+DQo+ID4gVGhhdCBkb2VzIG5vdCBu ZWdhdGUgbXkgcG9pbnQsIGhvd2V2ZXIsIHdoaWNoIHdhcyB0aGF0Og0KPiA+DQo+ID4gaXQgc2hv dWxkIGJlIGVzdGFibGlzaGVkIG9uIHRoZSBsaXN0IHRoYXQgdGhlcmUgYXJlIG1lYW5pbmdmdWwN Cj4gPiB0aGluZ3MgdG8gZG8sIGFuZCB0aGVyZSdzIGEgbWVhbmluZ2Z1bCBjcml0aWNhbCBtYXNz IG9mIHBlb3BsZSB0bw0KPiA+IGJlIGRvaW5nIHRob3NlIHRoaW5ncywgYmVmb3JlIGEgKHZpcnR1 YWwpIGludGVyaW0gaXMgY2FsbGVkLg0KPiA+IEJyYWluc3Rvcm1pbmcgb24gYSB0ZWxlY29uZmVy ZW5jZSBpcyByYXJlbHkgYSBjb25zdHJ1Y3RpdmUgd2F5IHRvDQo+ID4gc3BlbmQgdGltZQ0KPiA+ DQo+ID4NCj4gPiBUaG9tYXMNCj4gPg0KPiA+DQo+ID4gVG8geW91ciBwb2ludCBpdCdzIGltcGFy YXRpdmUgdGhhdCB0aGUgZGlzY3Vzc2lvbiBjb250aW51ZXMgb24gbGlzdA0KPiA+IGFib3V0IHRo ZSBjaGFydGVyLiAgV2l0aCB0aGF0IGluIG1pbmQgaGVyZSBpcyBhIHN1Z2dlc3RlZCBlZGl0IG9m DQo+ID4gdGhlIHByZXZpb3VzbHkgZmxvYXRlZCBjaGFydGVyLCB3aXRoIGNvbW1lbnRzIGluICgp IHdpdGggSldEIHRhZ3MuDQo+ID4NCj4gPg0KPiA+IFRoZSBwdXJwb3NlIG9mIHRoZSBNQU5FVCB3 b3JraW5nIGdyb3VwIGlzIHRvIHN0YW5kYXJkaXplIElQIHJvdXRpbmcNCj4gPiBwcm90b2NvbCBm dW5jdGlvbmFsaXR5IHN1aXRhYmxlIGZvciB3aXJlbGVzcyByb3V0aW5nIGFwcGxpY2F0aW9uDQo+ ID4gd2l0aGluIGJvdGggc3RhdGljIGFuZCBkeW5hbWljIHRvcG9sb2dpZXMgd2l0aCBpbmNyZWFz ZWQgZHluYW1pY3MNCj4gPiBkdWUgdG8gbm9kZSBtb3Rpb24gb3Igb3RoZXIgZmFjdG9ycy4NCj4g Pg0KPiA+IEFwcHJvYWNoZXMgYXJlIGludGVuZGVkIHRvIGJlIHJlbGF0aXZlbHkgbGlnaHR3ZWln aHQgaW4gbmF0dXJlLA0KPiA+IHN1aXRhYmxlIGZvciBtdWx0aXBsZSBoYXJkd2FyZSBhbmQgd2ly ZWxlc3MgZW52aXJvbm1lbnRzLCBhbmQNCj4gPiBhZGRyZXNzIHNjZW5hcmlvcyB3aGVyZSBNQU5F VHMgYXJlIGRlcGxveWVkIGF0IHRoZSBlZGdlcyBvZiBhbiBJUA0KPiA+IGluZnJhc3RydWN0dXJl LiBIeWJyaWQgbWVzaCBpbmZyYXN0cnVjdHVyZXMgKGUuZy4sIGEgbWl4dHVyZSBvZg0KPiA+IGZp eGVkIGFuZCBtb2JpbGUgcm91dGVycykgc2hvdWxkIGFsc28gYmUgc3VwcG9ydGVkIGJ5IE1BTkVU DQo+ID4gc3BlY2lmaWNhdGlvbnMgYW5kIG1hbmFnZW1lbnQgZmVhdHVyZXMuDQo+ID4NCj4gPiBU aGUgTUFORVQgV0cgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBtYWludGVuYW5jZSBvZiBPTFNSdjIs IEFPRFZ2Mg0KPiA+IChKV0QgVEJEKSwgRExFUCBhbmQgTkhQRC4gT2YgcGFydGljdWxhciBpbnRl cmVzdDogc2VjdXJpdHkNCj4gPiBlbmhhbmNlbWVudHMsIGFuZCBlbmNyeXB0aW9uIHNlY3VyaXR5 IGV4dGVuc2lvbnMgZm9yIFJGQzU0NDQuIChKV0QNCj4gPiB3ZSBtYXkgd2FudCB0byBicmVhayB0 aGlzIG91dCBvZiB0aGUgV0cgYW5kIG1ha2UgYSBuZXcgTUFORVQgU2VjDQo+ID4gd29ya2luZyBn cm91cCB0byBncmFiIHRoZSBhdHRlbnRpb24gb2YgdGhvc2UgaW50ZXJlc3RlZCBpbiBzZWN1cml0 eQ0KPiA+IGFuZCBnZXQgdGhlaXIgcGFydGljaXBhdGlvbi4pDQo+ID4NCj4gPiBUaGUgTUFORVQg V0cgd2lsbCBzdGFuZGFyZGl6ZSBhIG11bHRpY2FzdCBNQU5FVCBwcm90b2NvbCBmcmFtZXdvcmsN Cj4gPiBiYXNlZCBvbiBwcmV2aW91cyB3b3JrIGFuZCBsZXNzb25zIGxlYXJuZWQgZm9yIHNjb3Bl ZCBmb3J3YXJkaW5nDQo+ID4gd2l0aGluIE1BTkVUIG5ldHdvcmtzLiAgQXMgcGFydCBvZiB0aGlz IGZyYW1ld29yayB0aGUgV0cgd2lsbA0KPiA+IHByb2R1Y2UgYSB3ZWxsIGRlZmluZWQgTUFORVQg bXVsdGljYXN0IGZvcndhcmRpbmcgaW5mb3JtYXRpb24gYmFzZS4NCj4gPg0KPiA+IFRoZSBXRyB3 aWxsIHByb2R1Y2UgYW4gaW5mb3JtYXRpb25hbCBkcmFmdCBvdXRsaW5pbmcgY2hhbGxlbmdlcyBh bmQNCj4gPiBiZXN0IHByYWN0aWNlcyBmb3IgZGVwbG95aW5nIGFuZCBtYW5hZ2luZyBNQU5FVCBu ZXR3b3Jrcy4NCj4gPg0KPiA+IFRoZSBNQU5FVCBXRyB3aWxsIGludGVyYWN0IHdpdGggdGhlIFBJ TSB3b3JraW5nIGdyb3VwIG9uIGlzc3Vlcw0KPiA+IHJlbGF0aW5nIHRvIHRoZSBtdWx0aWNhc3Qg d29yay4gIFRoZSBXRyB3aWxsIGFsc28gcGF5IGF0dGVudGlvbiB0bw0KPiA+IG90aGVyIElFVEYg YW5kIElSVEYgd29yayB0aGF0IGlzIGFkZHJlc3NpbmcgdG9waWNzIHJlbGF0ZWQgdG8gTUFORVQN Cj4gPiBlbnZpcm9ubWVudHMuDQo+ID4NCj4gPiBJbiBzdW1tYXJ5LCB0aGUgV0cgd2lsbCBkZXZl bG9wIHRoZSBmb2xsb3dpbmcgZHJhZnRzOg0KPiA+DQo+ID4gTUFORVQgTWFuYWdlbWVudCBEb2N1 bWVudCAoSW5mb3JtYXRpb25hbCkNCj4gPiBNQU5FVCBNYWludGVuYW5jZQ0KPiA+ICAtIFJGQzU0 NDQgU2VjdXJpdHkgZXh0ZW5zaW9uIChTdGFuZGFyZHMpIChKV0QgcG9zc2libHkgbW92ZSB0aGlz DQo+ID4gdG8gbmV3IHdvcmtpbmcgZ3JvdXApDQo+ID4gTUFORVQgTXVsdGljYXN0DQo+ID4gIC0g TXVsdGljYXN0IEZJQiAoU3RhbmRhcmRzKQ0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIFR1ZSwgQXBy IDI2LCAyMDE2IGF0IDI6NTUgUE0sIFRob21hcyBDbGF1c2VuIDwNCj4gPiBpZXRmQHRob21hc2Ns YXVzZW4ub3JnPiB3cm90ZToNCj4gPiBIaSwNCj4gPg0KPiA+IEkgYmVsaWV2ZSB0aGF0IGFuIHZp cnR1YWwgaW50ZXJpbSBpcyBwcmVtYXR1cmU6IGEgdGVsZWNvbmZlcmVuY2UNCj4gPiBpcywgbWVj aGFuaWNhbGx5LCBsZXNzIGluY2x1c2l2ZSB0aGFuIGFyZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lv bnMNCj4gPiAodGltZS16b25lcywgb3RoZXIgY29tbWl0bWVudHMsIHJlcXVpcmVtZW50IG9mIHN5 bmNocm9uaWNpdHkgb2YNCj4gPiBwYXJ0aWNpcGF0aW9uLCBldGMuKS4NCj4gPg0KPiA+IEZ1cnRo ZXJtb3JlLi4uLg0KPiA+DQo+ID4gVW50aWwgc3VjaCB0aW1lIHRoYXQgYSBzdHJhd21hbiBjaGFy dGVyIGlzIHByb3Bvc2VkLCB1cGRhdGVkIHRvDQo+ID4gcmVmbGVjdCB0aGUgcmVhbGl0eSBvZiB0 aGUgZ3JvdXAgYXMgc3RpcHVsYXRlZCBieSB0aGUgQUQgYW5kIGJ5IE1yLg0KPiA+IERlYW4sIGFz IHdlbGwgYXMgYWRkaXRpb25hbCBjaGFydGVyIGl0ZW1zIGVtZXJnaW5nIG9uIHRoZSBsaXN0LA0K PiA+ICBhbmQgd2l0aCByZWxhdGl2ZWx5IGJyb2FkIGFuZCBkZWVwIHN1cHBvcnQgZm9yIHRoZSBp bmNsdWRlZCBpdGVtcw0KPiA+IGJ5IHRoZSB3b3JraW5nIGdyb3VwLCBoYXZpbmcgYW4gaW50ZXJp bSAtIHZpcnR1YWwgb3Igb3RoZXJ3aXNlIC0gaXMNCj4gPiBub3QgY29uc3RydWN0aXZlLg0KPiA+ DQo+ID4gSW4gb3RoZXIgd29yZHMsIGl0IHNob3VsZCBiZSBlc3RhYmxpc2hlZCBvbiB0aGUgbGlz dCB0aGF0IHRoZXJlIGFyZQ0KPiA+IG1lYW5pbmdmdWwgdGhpbmdzIHRvIGRvLCBhbmQgdGhlcmUn cyBhIG1lYW5pbmdmdWwgY3JpdGljYWwgbWFzcyBvZg0KPiA+IHBlb3BsZSB0byBiZSBkb2luZyB0 aG9zZSB0aGluZ3MsIGJlZm9yZSBhICh2aXJ0dWFsKSBpbnRlcmltIGlzDQo+ID4gY2FsbGVkLiBC cmFpbnN0b3JtaW5nIG9uIGEgdGVsZWNvbmZlcmVuY2UgaXMgcmFyZWx5IGEgY29uc3RydWN0aXZl DQo+ID4gd2F5IHRvIHNwZW5kIHRpbWUuDQo+ID4NCj4gPg0KPiA+IEJlc3QsDQo+ID4NCj4gPg0K PiA+IFRob21hcw0KPiA+DQo+ID4gU2VudCBmcm9tIG15IGlQYWQNCj4gPg0KPiA+IE9uIDIyIEFw ciAyMDE2LCBhdCAxNzo1MCwgU3RhbiBSYXRsaWZmIDxyYXRsaWZmc3RhbkBnbWFpbC5jb20+DQo+ ID4gd3JvdGU6DQo+ID4NCj4gPiBIZWxsbyBXRywNCj4gPg0KPiA+IERvIHdlIG5lZWQgdG8gaG9s ZCBhbiBpbnRlcmltIG1lZXRpbmcgKHZpYSBXZWJFWCkgdG8gZGlzY3Vzcz8gSSdkDQo+ID4gbGlr ZSB0byBnZXQgb3BpbmlvbnMgb24gdGhlIGxpc3QgYWJvdXQgdGhhdC4gV2UnbGwgbmVlZCBhIGNv dXBsZSBvZg0KPiA+IHdlZWtzIHRvIHNjaGVkdWxlLCBidXQgd2UgY2FuIGRvIHRoYXQuDQo+ID4N Cj4gPiBPbmUgb3RoZXIgcG9pbnQgaW5saW5lOg0KPiA+DQo+ID4gT24gRnJpLCBBcHIgMjIsIDIw MTYgYXQgMTE6NDUgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDwNCj4gPiBjaHJpcy5k ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gd3JvdGU6DQo+ID4gTXVsdGljYXN0IGlzIHRoZSBvYnZp b3VzIHRvcCBpdGVtLiBMb3RzIG9mIHBvc3NpYmxlIGFwcHJvYWNoZXMsDQo+ID4gdGltZSB0byBk aXNjdXNzLg0KPiA+DQo+ID4gR2F0ZXdheXMgZm9yIEFPRFZ2MiBhdCBTdGFuZGFyZCBpcyBvYnZp b3VzbHkgbm90IHBvc3NpYmxlIHNpbmNlDQo+ID4gQU9EVnYyIGlzIGdvaW5nIHRvIGJlIEV4cGVy aW1lbnRhbCBhdCBtb3N0Lg0KPiA+DQo+ID4gTWFuYWdlbWVudCB3ZSBkaWQgb2YgY291cnNlIGhh dmUgYW4gTkhEUC9PTFNSdjIgZHJhZnQga2lsbGVkIGJ5IEFELg0KPiA+IFdoaWNoIHNpbmNlIE5I RFAvT0xTUnYyIHVzIGFsbCB3ZSBoYXZlIChTTUYgZXhjZXB0ZWQpIHRoYXQgd2FzIGENCj4gPiBi aXQgdHJpY2t5Lg0KPiA+DQo+ID4gSSB3b3VsZCBoYXZlIHRvIG1ha2UgYW4gSVBSIGRlY2xhcmF0 aW9uIHRvIHNheSBzb21lIG9mIHdoYXQgSSBtaWdodA0KPiA+IGhhdmUgdG8gc2F5IGFib3V0IGVu Y3J5cHRpb24uIE5vdCB0b2RheS4NCj4gPg0KPiA+IFVuZGVyc3Rvb2QuIEJ1dCBwbGVhc2UgcmVt ZW1iZXIgLSB0aGVyZSdzIG9ubHkgYWJvdXQgYSA1LXdlZWsgZ2FwDQo+ID4gbm93IGJlZm9yZSB0 aGUgY2hhcnRlciBuZWVkcyB0byBiZSBjb21wbGV0ZSBpbiBvcmRlciBmb3IgdGhlIFdHIHRvDQo+ ID4gbWVldCBpbiBCZXJsaW4uDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IFN0YW4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+IE1pc3NpbmcgZnJvbSB0aGUgbGlzdCBpcyBhbnkgd29yayBvbiBPTFNS djIgKG9yIE5IRFApLiBNVC1PTFNSdjIgaXMNCj4gPiBleHBlcmltZW50YWwuIFRoYXQgd291bGQg bmVlZCBpbXBsZW1lbnRhdGlvbiB0ZXN0cyB0byBhZHZhbmNlIHRvDQo+ID4gUFMuIEFueW9uZSBp bnRlcmVzdGVkIGluIHRoYXQgKEnigJltIG5vdCBzYXlpbmcgSSBjYW4pPw0KPiA+DQo+ID4gTW9y ZSBicm9hZGx5IG9uIE9MU1J2MiB0aGVyZSBhcmUgdmFyaW91cyB0aGluZ3MgdGhhdCBjb3VsZCBi ZSBkb25lLA0KPiA+IGJ1dCB3aGF0IGlzIHJlYWxseSBuZWVkZWQgaXMgcGVvcGxlIHdpdGggYSBy ZWFsIGFwcGxpY2F0aW9uLiBBbnkNCj4gPiB0aGF0IGV4aXN0IHdlcmUgZnJpZ2h0ZW5lZCBhd2F5 IGZyb20gdGhpcyBncm91cC4NCj4gPg0KPiA+IC0tDQo+ID4NCj4gPiBDaHJpc3RvcGhlciBEZWFy bG92ZQ0KPiA+IFNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCj4gPiBCQUUgU3lzdGVtcyBBcHBs aWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gX19fX19f Xw0KPiA+DQo+ID4gVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb20NCj4gPg0KPiA+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl LCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQNCj4gPiBCYWRkb3csIENoZWxtc2Zv cmQsIEVzc2V4IENNMiA4SE4uDQo+ID4gd3d3LmJhZXN5c3RlbXMuY29tL2FpDQo+ID4NCj4gPiBC QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQo+ID4gUmVnaXN0ZXJlZCBp biBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQo+ID4gUmVnaXN0ZXJlZCBPZmZpY2U6IFN1 cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KPiA+DQo+ID4N Cj4gPiBGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBKdXN0aW4NCj4gPiBEZWFuDQo+ID4gU2VudDogMjIgQXByaWwgMjAxNiAxNjowNw0KPiA+ IFRvOiBtYW5ldEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFttYW5ldF0gUmVjaGFydGVyIERpc2N1 c3Npb24NCj4gPg0KPiA+DQo+ID4gKioqIFdBUk5JTkcgKioqDQo+ID4gVGhpcyBtZXNzYWdlIG9y aWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tDQo+ID4g YW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQo+ID4gQ29uc2lkZXIgY2FyZWZ1 bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55DQo+ID4g YXR0YWNobWVudHMgb3IgcmVwbHkuDQo+ID4gRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQg RmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbg0KPiA+IGVtYWlscyB5b3UgcmVjZWl2 ZSwgY2xpY2sgaGVyZS4NCj4gPiBJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywg cGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3MuDQo+ID4NCj4gPiAqKiogV0FSTklORyAqKioNCj4g PiBFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUg b3VyDQo+ID4gb3JnYW5pemF0aW9uLg0KPiA+DQo+ID4gSSdsbCBzdGFydCB0aGluZ3Mgb2ZmIGJ5 IGZsb2F0aW5nIHRoZSBkcmFmdCByZS1jaGFydGVyIHdoaWNoIHdhcw0KPiA+IHByZXNlbnRlZCBp biBQcmFndWUuDQo+ID4NCj4gPiBUaGUgcHVycG9zZSBvZiB0aGUgTUFORVQgd29ya2luZyBncm91 cCBpcyB0byBzdGFuZGFyZGl6ZSBJUCByb3V0aW5nDQo+ID4gcHJvdG9jb2wgZnVuY3Rpb25hbGl0 eSBzdWl0YWJsZSBmb3Igd2lyZWxlc3Mgcm91dGluZyBhcHBsaWNhdGlvbg0KPiA+IHdpdGhpbiBi b3RoIHN0YXRpYyBhbmQgZHluYW1pYyB0b3BvbG9naWVzIHdpdGggaW5jcmVhc2VkIGR5bmFtaWNz DQo+ID4gZHVlIHRvIG5vZGUgbW90aW9uIG9yIG90aGVyIGZhY3RvcnMuDQo+ID4NCj4gPiBBcHBy b2FjaGVzIGFyZSBpbnRlbmRlZCB0byBiZSByZWxhdGl2ZWx5IGxpZ2h0d2VpZ2h0IGluIG5hdHVy ZSwNCj4gPiBzdWl0YWJsZSBmb3IgbXVsdGlwbGUgaGFyZHdhcmUgYW5kIHdpcmVsZXNzIGVudmly b25tZW50cywgYW5kDQo+ID4gYWRkcmVzcyBzY2VuYXJpb3Mgd2hlcmUgTUFORVRzIGFyZSBkZXBs b3llZCBhdCB0aGUgZWRnZXMgb2YgYW4gSVANCj4gPiBpbmZyYXN0cnVjdHVyZS4gSHlicmlkIG1l c2ggaW5mcmFzdHJ1Y3R1cmVzIChlLmcuLCBhIG1peHR1cmUgb2YNCj4gPiBmaXhlZCBhbmQgbW9i aWxlIHJvdXRlcnMpIHNob3VsZCBhbHNvIGJlIHN1cHBvcnRlZCBieSBNQU5FVA0KPiA+IHNwZWNp ZmljYXRpb25zIGFuZCBtYW5hZ2VtZW50IGZlYXR1cmVzLg0KPiA+DQo+ID4gVGhlIE1BTkVUIFdH IGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgbWFpbnRlbmFuY2Ugb2YgT0xTUnYyLCBBT0RWdjIsDQo+ ID4gRExFUCBhbmQgTkhQRC4gT2YgcGFydGljdWxhciBpbnRlcmVzdDogYm9yZGVyIGJlaGF2aW9y IGJldHdlZW4NCj4gPiBNQU5FVCBuZXR3b3JrcyBhbmQgZml4ZWQgSVAgbmV0d29yayBpbmZyYXN0 cnVjdHVyZXMsIGVuaGFuY2UgQU9EVnYyDQo+ID4gZ2F0ZXdheSBmdW5jdGlvbmFsaXR5OyBzZWN1 cml0eSBlbmhhbmNlbWVudHMsIGVuY3J5cHRpb24gc2VjdXJpdHkNCj4gPiBleHRlbnNpb25zIGZv ciBSRkM1NDQ0Lg0KPiA+DQo+ID4gVGhlIE1BTkVUIFdHIHdpbGwgc3RhbmRhcmRpemUgYSBtdWx0 aWNhc3QgTUFORVQgcHJvdG9jb2wgZnJhbWV3b3JrDQo+ID4gYmFzZWQgb24gcHJldmlvdXMgd29y ayBhbmQgbGVzc29ucyBsZWFybmVkIGZvciBzY29wZWQgZm9yd2FyZGluZw0KPiA+IHdpdGhpbiBN QU5FVCBuZXR3b3Jrcy4gIEFzIHBhcnQgb2YgdGhpcyBmcmFtZXdvcmsgdGhlIFdHIHdpbGwNCj4g PiBwcm9kdWNlIGEgd2VsbCBkZWZpbmVkIE1BTkVUIG11bHRpY2FzdCBmb3J3YXJkaW5nIGluZm9y bWF0aW9uIGJhc2UuDQo+ID4NCj4gPiBUaGUgV0cgd2lsbCBwcm9kdWNlIGFuIGluZm9ybWF0aW9u YWwgZHJhZnQgb3V0bGluaW5nIGNoYWxsZW5nZXMgYW5kDQo+ID4gYmVzdCBwcmFjdGljZXMgZm9y IGRlcGxveWluZyBhbmQgbWFuYWdpbmcgTUFORVQgbmV0d29ya3MuDQo+ID4NCj4gPiBUaGUgTUFO RVQgV0cgd2lsbCBpbnRlcmFjdCB3aXRoIHRoZSBQSU0gd29ya2luZyBncm91cCBvbiBpc3N1ZXMN Cj4gPiByZWxhdGluZyB0byB0aGUgbXVsdGljYXN0IHdvcmsuICBUaGUgV0cgd2lsbCBhbHNvIHBh eSBhdHRlbnRpb24gdG8NCj4gPiBvdGhlciBJRVRGIGFuZCBJUlRGIHdvcmsgdGhhdCBpcyBhZGRy ZXNzaW5nIHRvcGljcyByZWxhdGVkIHRvIE1BTkVUDQo+ID4gZW52aXJvbm1lbnRzLg0KPiA+DQo+ ID4gSW4gc3VtbWFyeSwgdGhlIFdHIHdpbGwgZGV2ZWxvcCB0aGUgZm9sbG93aW5nIGRyYWZ0czoN Cj4gPg0KPiA+IE1BTkVUIE1hbmFnZW1lbnQgRG9jdW1lbnQgKEluZm9ybWF0aW9uYWwpDQo+ID4g TUFORVQgTWFpbnRlbmFuY2UNCj4gPiAgLSBSRkM1NDQ0IFNlY3VyaXR5IGV4dGVuc2lvbiAoU3Rh bmRhcmRzKQ0KPiA+ICAtIEVuaGFuY2VkIEFPRFZ2MiBnYXRld2F5IGV4dGVuc2lvbiAoU3RhbmRh cmRzKQ0KPiA+IE1BTkVUIE11bHRpY2FzdA0KPiA+ICAtIE11bHRpY2FzdCBGSUIgKFN0YW5kYXJk cykNCj4gPg0KPiA+DQo+ID4gVGhpcyB3aWxsIGxpa2VseSBiZSBjb25zaWRlcmVkIHRvbyBicm9h ZCB0byBwYXNzLiAgV2Ugd2lsbCBsaWtlbHkNCj4gPiBuZWVkIHRvIGN1dCBzb21lIGFuZCBmb2N1 cyB0aGUgd29yay4gIEZvciBtZSBwZXJzb25hbGx5IEkga25vdyBJDQo+ID4gaGF2ZSB0aGUgdGlt ZSBhbmQgYmFja2luZyB0byB3b3JrIG9uIHRoZSBNdWx0aWNhc3QgcGllY2UuDQo+ID4NCj4gPiBK dXN0aW4NCj4gPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQo+ID4gKg0KPiA+IFRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KPiA+IHJlY2lwaWVudCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQo+ ID4gcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5 IHRoZSBzZW5kZXIuDQo+ID4gWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFu eSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KPiA+IGRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24uDQo+ID4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+ICoNCj4gPg0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbWFuZXQgbWFp bGluZyBsaXN0DQo+ID4gbWFuZXRAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbWFuZXQgbWFpbGluZyBsaXN0DQo+ID4g bWFuZXRAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21hbmV0DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiA+IG1hbmV0QGlldGYub3JnDQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPiA+DQo+ID4NCj4g Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gPiBtYW5ldEBpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCj4gPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxp c3QNCj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldA0K From nobody Wed May 4 04:43:14 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F339E12D59F for ; Wed, 4 May 2016 04:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh6qGuih2Nru for ; Wed, 4 May 2016 04:43:02 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6546D12D569 for ; Wed, 4 May 2016 04:42:58 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n129so184858814wmn.1 for ; Wed, 04 May 2016 04:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=4yPvsfW58KSGJkxwL5GIzdcJtA1ZNQBLgWKJNWSGvMA=; b=KyLTrITtGWGKrQG+y51wfdOKvN10ETjOPUP/gOhjjmS0mn40m6Q1fS658pDwjJZLfo +8/3a3/K4H5EZU6PaFKqxp/XhBEXsIbI01RrvBFPStBVRkZb4gReq3ePHk4ldu3IiEWi zQnn7vAxNJhp2u8eZjVUAl0mgtyBmi31vjLl/ihPAXhztIx+F6p7e+JXTV16BySugKrC XgvnOOOYEGv4ZlpXLmJkEyqKvB3vHaK+jgOvQLpmHP2saoQttdXhUdNjdMrOgqCxVH36 OLgbZSC27YH2v8PLTSOd02EQnY5y10as0Ms+k+38tYTDnHV8A4F2oYyXVz793wa+67cQ 9EqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4yPvsfW58KSGJkxwL5GIzdcJtA1ZNQBLgWKJNWSGvMA=; b=ToXtqVV6+rgL5wSRbz+HwTLTkkntHjmfTSxEPVHjK/hJI6sfaL43P/DVcuopeBgPnx aoOY3cTmO3EfONY8mHK1nhfpsYiiyu1KcZF8NIXg5zLJTcO3CNrJIgQzg9r7XJXY2T6N kgRuHBEWb+clUIBaQXygRbamY3EEj/+KtF2Mdw4IdqVlaoau1IbcfegV3wqTmsHux8+x EtP3ckvjR8TSxXlBYDjpKSo275SgBG/11Z7KHW86jCQUT7ikTqsZIznGUj8hJbF+M+PR BL/G80cchOpyJ9/uL8TE+hk9Kbt4UlzWf+1VTgk27WymALnHvbeL/ANSrFPAz3Elqb26 wv+Q== X-Gm-Message-State: AOPr4FXA43yw4hxSqVYj+sFGKwyY9U24C9I4wNWLDk4B4YDzoNezydeRVVs6+D33lIwE1g== X-Received: by 10.28.113.67 with SMTP id m64mr31359503wmc.58.1462362176924; Wed, 04 May 2016 04:42:56 -0700 (PDT) Received: from johns-mbp-4.home (host86-155-246-227.range86-155.btcentralplus.com. [86.155.246.227]) by smtp.gmail.com with ESMTPSA id r5sm3730131wjy.37.2016.05.04.04.42.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 May 2016 04:42:56 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E4109A49-B5D4-4519-AC93-C30CA2F9BDEE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Dowdell In-Reply-To: <2DC54CCE-46BE-48D0-9497-52D31DCB5B40@inf-net.nl> Date: Wed, 4 May 2016 12:42:54 +0100 Message-Id: <8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> References: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com> <2DC54CCE-46BE-48D0-9497-52D31DCB5B40@inf-net.nl> To: MANET IETF X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [manet] DLEP and latency metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 11:43:05 -0000 --Apple-Mail=_E4109A49-B5D4-4519-AC93-C30CA2F9BDEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I know we=E2=80=99re all a bit tied up with various last calls but can I = ask for adjudication on this point? The current draft is ambiguous as to = whether the latency metric includes the current queuing delay, taking = account of how full or not the queue is at the sampling instant, or a = notional =E2=80=9Cno traffic" delay (in the same manner as for the = bandwidth metric), and there are polarised views for and against. Just that I=E2=80=99m keen to get this one clarified one way or the = other. Following Stan=E2=80=99s proposal below, can I propose that the Latency = Metric is measured in absence of traffic, and that an extension metric = for Link Utilisation (which could provide metrics plural) is written up? Regards John > On 27 Apr 2016, at 07:43, Teco Boot wrote: >=20 >>=20 >> Op 27 apr. 2016, om 01:16 heeft Stan Ratliff = het volgende geschreven: >>=20 >> John, >>=20 >> Speaking as a co-author and a DLEP implementer, >>=20 >> On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell = wrote: >> Hi all >>=20 >> A question has arisen as to whether the Latency metric should include = queueing delay in the modem. >>=20 >> It has long been held that the bandwidth metric is measured in the = absence of traffic (though the metric descriptions in 10.14 and 10.15 of = Current Data Rate are ambiguous on this point), yet section 10.16 of -22 = states ... >>=20 >> Yes, that's the way my implementation went. I don't see a use case = for a bandwidth metric that attempts to take traffic into account, and = it seems to me like such a metric could (would) fluctuate wildly. =46rom = my experience, the "interesting statistic" was always "how fast is the = pipe?" Trying to factor traffic into account can have really weird = side-effects - for instance, I remember a radio implementation that = reported a "Current Data Rate" of 0 on an idle link (because, after all, = no traffic was flowing)... that drove the router nuts, since it saw a = "broken" (or nearly broken) link. >>=20 >>=20 >>=20 >> " Latency: A 64-bit unsigned integer, representing the transmission = delay, in microseconds, that a packet encounters as it is transmitted = over the link.=E2=80=9D >>=20 >> =E2=80=A6 which suggests that queuing delay should be included. >>=20 >> Much as in the case above, I can't see a use case for a "Latency" = metric *without* queueing delay. >=20 > I don't get this. Above, you suggest traffic is not taken into = account. Here, you suggest queuing delay (caused by traffic?) is taken = into account. >=20 > I suggest packet handling delay for a single packet on an idle medium = is taken into account. Delay caused by filled up queues is not. Queue = depth would be another metric. Which would fluctuate wildly^^2. And = could be a complex composite metric when *FQ is used. See RFC 7567 / BCP = 197 on what packet forwarding devices SHOULD do. >=20 > Teco >=20 >=20 >>=20 >>=20 >> There are positive and negative connotations; a modem queue that = suddenly becomes full might not have any more data queued to it, or a = DLEP-powered routing algorithm might choose another modem instead, = allowing the queue to subside, but that might not be what the system = integrator wanted to happen. >>=20 >> And that would depend on a lot of code that outside the scope of the = DLEP spec - specifically, it depends on how an algorithm actually = *deals* with the DLEP metrics supplied. >>=20 >> Having said all of that, I can see a possibility for a couple of = follow-on metrics for a DLEP extension - the first would be a "Link = Utilization" metric. The other would be a "Propagation delay" metric, = based on the physical properties of the transmission medium. >>=20 >> Just a thought. >>=20 >> Regards, >> Stan >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet = --Apple-Mail=_E4109A49-B5D4-4519-AC93-C30CA2F9BDEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I know we=E2=80=99re all a bit tied up with = various last calls but can I ask for adjudication on this point? The = current draft is ambiguous as to whether the latency metric includes the = current queuing delay, taking account of how full or not the queue is at = the sampling instant, or a notional =E2=80=9Cno traffic" delay (in the = same manner as for the bandwidth metric), and there are polarised views = for and against.

Just that I=E2=80=99m keen to get this one clarified one way = or the other.

Following Stan=E2=80=99s proposal below, can I propose that = the Latency Metric is measured in absence of traffic, and that an = extension metric for Link Utilisation (which could provide metrics = plural) is written up?

Regards
John

On = 27 Apr 2016, at 07:43, Teco Boot <teco@inf-net.nl> wrote:


Op 27 apr. 2016, om 01:16 heeft Stan = Ratliff <ratliffstan@gmail.com> het volgende geschreven:

John,

Speaking as = a co-author and a DLEP implementer,

On Tue, = Apr 26, 2016 at 6:06 PM, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
Hi = all

A question has arisen as to whether the = Latency metric should include queueing delay in the modem.

It has long been held that the bandwidth = metric is measured in the absence of traffic (though the metric = descriptions in 10.14 and 10.15 of Current Data Rate are ambiguous on = this point), yet section 10.16 of -22 states ...

Yes, that's the way my implementation went. I don't see a use = case for a bandwidth metric that attempts to take traffic into account, = and it seems to me like such a metric could (would) fluctuate wildly. = =46rom my experience, the "interesting statistic" was always "how fast = is the pipe?" Trying to factor traffic into account can have really = weird side-effects - for instance, I remember a radio implementation = that reported a "Current Data Rate" of 0 on an idle link (because, after = all, no traffic was flowing)... that drove the router nuts, since it saw = a "broken" (or nearly broken) link.



" Latency: A 64-bit unsigned integer, = representing the transmission delay, in microseconds, that a packet = encounters as it is transmitted over the link.=E2=80=9D

=E2=80=A6 which suggests that queuing delay should be = included.

Much as in the case above, I = can't see a use case for a "Latency" metric *without* queueing delay.

I don't get this. Above, you suggest traffic is = not taken into account. Here, you suggest queuing delay (caused by = traffic?) is taken into account.

I suggest packet handling delay for a single = packet on an idle medium is taken into account. Delay caused by filled = up queues is not. Queue depth would be another metric. Which would = fluctuate wildly^^2. And could be a complex composite metric when *FQ is = used. See RFC 7567 / BCP 197 on what packet forwarding devices SHOULD = do.

Teco




There are positive and negative connotations; = a modem queue that suddenly becomes full might not have any more data = queued to it, or a DLEP-powered routing algorithm might choose another = modem instead, allowing the queue to subside, but that might not be what = the system integrator wanted to happen.

And = that would depend on a lot of code that outside the scope of the DLEP = spec - specifically, it depends on how an algorithm actually *deals* = with the DLEP metrics supplied.

Having said = all of that, I can see a possibility for a couple of follow-on metrics = for a DLEP extension - the first would be a "Link Utilization" metric. = The other would be a "Propagation delay" metric, based on the physical = properties of the transmission medium.

Just = a thought.

Regards,
Stan


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

= --Apple-Mail=_E4109A49-B5D4-4519-AC93-C30CA2F9BDEE-- From nobody Wed May 4 05:20:25 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B8B12D64A for ; Wed, 4 May 2016 05:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVwUl-27Vtu7 for ; Wed, 4 May 2016 05:20:21 -0700 (PDT) Received: from ndjsvnpf103.ndc.nasa.gov (NDJSVNPF103.ndc.nasa.gov [198.117.1.153]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF1312D665 for ; Wed, 4 May 2016 05:20:21 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndjsvnpf103.ndc.nasa.gov (Postfix) with ESMTP id A209640080BD; Wed, 4 May 2016 07:20:20 -0500 (CDT) Received: from NDJSCHT107.ndc.nasa.gov (ndjscht107-pub.ndc.nasa.gov [198.117.1.207]) by ndjsppt103.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u44CKKSZ010263; Wed, 4 May 2016 07:20:20 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.156]) by NDJSCHT107.ndc.nasa.gov ([198.117.1.207]) with mapi id 14.03.0266.001; Wed, 4 May 2016 07:20:20 -0500 From: "Ivancic, William D. (GRC-LCA0)" To: John Dowdell , MANET IETF Thread-Topic: [manet] DLEP and latency metric Thread-Index: AQHRoAfw7fIq3W4yTE2IUaKCzqXfcJ+dNwoAgAB9EICAC1PYAP//x8kA Date: Wed, 4 May 2016 12:20:19 +0000 Message-ID: References: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com> <2DC54CCE-46BE-48D0-9497-52D31DCB5B40@inf-net.nl> <8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> In-Reply-To: <8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [184.56.61.175] Content-Type: multipart/alternative; boundary="_000_D34F606F461F4williamdivancicnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-04_05:, , signatures=0 Archived-At: Subject: Re: [manet] DLEP and latency metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 12:20:24 -0000 --_000_D34F606F461F4williamdivancicnasagov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just a word of caution. I remember experimenting with some manet related protocols that had all typ= es of metrics and weighting. When we applied all of these complexities to = an environment with varying traffic we eventually zeroed out most of the op= tions as they were effectively meaningless. I suspect queueing delay would= be one of those here. That effort was probably 8 to 10 years ago. Unfor= tunately, I don=92t think I can legally say much more than that at this tim= e. Will From: manet > on beha= lf of John Dowdell > Date: Wednesday, May 4, 2016 at 7:42 AM To: MANET IETF > Subject: Re: [manet] DLEP and latency metric I know we=92re all a bit tied up with various last calls but can I ask for = adjudication on this point? The current draft is ambiguous as to whether th= e latency metric includes the current queuing delay, taking account of how = full or not the queue is at the sampling instant, or a notional =93no traff= ic" delay (in the same manner as for the bandwidth metric), and there are p= olarised views for and against. Just that I=92m keen to get this one clarified one way or the other. Following Stan=92s proposal below, can I propose that the Latency Metric is= measured in absence of traffic, and that an extension metric for Link Util= isation (which could provide metrics plural) is written up? Regards John On 27 Apr 2016, at 07:43, Teco Boot > wrote: Op 27 apr. 2016, om 01:16 heeft Stan Ratliff > het volgende geschreven: John, Speaking as a co-author and a DLEP implementer, On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell > wrote: Hi all A question has arisen as to whether the Latency metric should include queue= ing delay in the modem. It has long been held that the bandwidth metric is measured in the absence = of traffic (though the metric descriptions in 10.14 and 10.15 of Current Da= ta Rate are ambiguous on this point), yet section 10.16 of -22 states ... Yes, that's the way my implementation went. I don't see a use case for a ba= ndwidth metric that attempts to take traffic into account, and it seems to = me like such a metric could (would) fluctuate wildly. From my experience, t= he "interesting statistic" was always "how fast is the pipe?" Trying to fac= tor traffic into account can have really weird side-effects - for instance,= I remember a radio implementation that reported a "Current Data Rate" of 0= on an idle link (because, after all, no traffic was flowing)... that drove= the router nuts, since it saw a "broken" (or nearly broken) link. " Latency: A 64-bit unsigned integer, representing the transmission delay, = in microseconds, that a packet encounters as it is transmitted over the lin= k.=94 =85 which suggests that queuing delay should be included. Much as in the case above, I can't see a use case for a "Latency" metric *w= ithout* queueing delay. I don't get this. Above, you suggest traffic is not taken into account. Her= e, you suggest queuing delay (caused by traffic?) is taken into account. I suggest packet handling delay for a single packet on an idle medium is ta= ken into account. Delay caused by filled up queues is not. Queue depth woul= d be another metric. Which would fluctuate wildly^^2. And could be a comple= x composite metric when *FQ is used. See RFC 7567 / BCP 197 on what packet = forwarding devices SHOULD do. Teco There are positive and negative connotations; a modem queue that suddenly b= ecomes full might not have any more data queued to it, or a DLEP-powered ro= uting algorithm might choose another modem instead, allowing the queue to s= ubside, but that might not be what the system integrator wanted to happen. And that would depend on a lot of code that outside the scope of the DLEP s= pec - specifically, it depends on how an algorithm actually *deals* with th= e DLEP metrics supplied. Having said all of that, I can see a possibility for a couple of follow-on = metrics for a DLEP extension - the first would be a "Link Utilization" metr= ic. The other would be a "Propagation delay" metric, based on the physical = properties of the transmission medium. Just a thought. Regards, Stan _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_D34F606F461F4williamdivancicnasagov_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Just a word of caution. 

I remember experimenting with some manet related protocols that had al= l types of metrics and weighting.  When we applied all of these comple= xities to an environment with varying traffic we eventually zeroed out most= of the options as they were effectively meaningless.  I suspect queueing delay would be one of those here. &n= bsp;That effort was probably 8 to 10 years ago.   Unfortunately, I don= =92t think I can legally say much more than that at this time.

Will

From: manet <manet-bounces@ietf.org> on behalf of John Dow= dell <john.dowdell.ietf@g= mail.com>
Date: Wednesday, May 4, 2016 at 7:4= 2 AM
To: MANET IETF <manet@ietf.org>
Subject: Re: [manet] DLEP and laten= cy metric

I know we=92re all a bit tied up with various last calls bu= t can I ask for adjudication on this point? The current draft is ambiguous = as to whether the latency metric includes the current queuing delay, taking= account of how full or not the queue is at the sampling instant, or a notional =93no traffic" delay (in th= e same manner as for the bandwidth metric), and there are polarised views f= or and against.

Just that I=92m keen to get this one clarified one way or t= he other.

Following Stan=92s proposal below, can I propose that the L= atency Metric is measured in absence of traffic, and that an extension metr= ic for Link Utilisation (which could provide metrics plural) is written up?=

Regards
John

On 27 Apr 2016, at 07:43, Teco Boot <teco@inf-net.nl> wrote:


Op 27 apr. 2016, om 01:16 heeft Stan Ratliff <ratliffstan@gmail.com> het volgende geschr= even:

John,

Speaking as a co-author and a DLEP implementer,

On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell <john.dowdell.ietf@gmail.com> wrote:=
Hi all

A question has arisen as to whether the Latency metric should include queue= ing delay in the modem.

It has long been held that the bandwidth metric is measured in the absence = of traffic (though the metric descriptions in 10.14 and 10.15 of Current Da= ta Rate are ambiguous on this point), yet section 10.16 of -22 states ...
Yes, that's the way my implementation went. I don't see a use case for a ba= ndwidth metric that attempts to take traffic into account, and it seems to = me like such a metric could (would) fluctuate wildly. From my experience, t= he "interesting statistic" was always "how fast is the pipe?" Trying to factor traffic into account ca= n have really weird side-effects - for instance, I remember a radio impleme= ntation that reported a "Current Data Rate" of 0 on an idle link = (because, after all, no traffic was flowing)... that drove the router nuts, since it saw a "broken" (or nearly broken= ) link.



" Latency: A 64-bit unsigned integer, representing the transmission de= lay, in microseconds, that a packet encounters as it is transmitted over th= e link.=94

=85 which suggests that queuing delay should be included.

Much as in the case above, I can't see a use case for a "Latency"= metric *without* queueing delay.

I don't get this. Above, you suggest traffic is not taken into account. Here= , you suggest queuing delay (caused by traffic?) is taken into account.

I suggest packet handling delay for a single packet on an idle medium is tak= en into account. Delay caused by filled up queues is not. Queue depth would= be another metric. Which would fluctuate wildly^^2. And could be a complex= composite metric when *FQ is used. See RFC 7567 / BCP 197 on what packet forwarding devices SHOULD do.=

Teco



There are positive and negative connotations; a modem queue that suddenly b= ecomes full might not have any more data queued to it, or a DLEP-powered ro= uting algorithm might choose another modem instead, allowing the queue to s= ubside, but that might not be what the system integrator wanted to happen.

And that would depend on a lot of code that outside the scope of the DLEP s= pec - specifically, it depends on how an algorithm actually *deals* with th= e DLEP metrics supplied.

Having said all of that, I can see a possibility for a couple of follow-on = metrics for a DLEP extension - the first would be a "Link Utilization&= quot; metric. The other would be a "Propagation delay" metric, ba= sed on the physical properties of the transmission medium.

Just a thought.

Regards,
Stan


_______________________________________________
manet mailing list
manet@ietf.org
https://= www.ietf.org/mailman/listinfo/manet

 --_000_D34F606F461F4williamdivancicnasagov_-- From nobody Wed May 4 05:29:22 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC1B12D67E for ; Wed, 4 May 2016 05:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsmlfRphyBBw for ; Wed, 4 May 2016 05:29:17 -0700 (PDT) Received: from isabel.astrium.eads.net (isabel.astrium.eads.net [194.62.210.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FE712D66C for ; Wed, 4 May 2016 05:29:15 -0700 (PDT) Received: from rosout.astrium.eads.net ([10.222.0.6]) by isabel.astrium.eads.net (8.14.4/8.14.4) with ESMTP id u44CTD47019578; Wed, 4 May 2016 13:29:13 +0100 Received: from rosout.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 60D3E2080F0; Wed, 4 May 2016 13:29:13 +0100 (BST) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 52D4720817A; Wed, 4 May 2016 13:29:13 +0100 (BST) X-IMSS-HAND-OFF-DIRECTIVE: 127.0.0.1:10026 Received: from AUK52839.UKN.UKNROOT.ASTRIUM.CORP (unknown [10.221.1.32]) by rosout.astrium.eads.net (Postfix) with ESMTPS id D6A6A2080F0; Wed, 4 May 2016 13:29:04 +0100 (BST) Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52839.UKN.UKNROOT.ASTRIUM.CORP ([fe80::cdf2:d214:a3a9:7510%15]) with mapi id 14.03.0123.003; Wed, 4 May 2016 13:29:04 +0100 From: "MATTY, Steven" To: "'John Dowdell'" , MANET IETF Thread-Topic: [manet] DLEP and latency metric Thread-Index: AQHRpfor29rCn4bFHkef/MQshMtCN5+otCPA Date: Wed, 4 May 2016 12:29:03 +0000 Message-ID: References: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com> <2DC54CCE-46BE-48D0-9497-52D31DCB5B40@inf-net.nl> <22940_1462362197_5729E055_22940_1245_1_8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> In-Reply-To: <22940_1462362197_5729E055_22940_1245_1_8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.1.73] X-TM-AS-Product-Ver: IMSVA-9.0.0.1549-8.0.0.1202-22300.007 X-TM-AS-Result: No--17.796-5.0-31-10 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_D9712B947A4CCA43AB42F01B90AF1DEC0174A9DD02AUK52982UKNUK_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-imss-scan-details: No--17.796-5.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1549-8.0.1202-22300.007 X-TMASE-Result: 10--17.795700-10.000000 X-TMASE-MatchedRID: +XkuFvcrUd1bJCKOm3VRCeedK36PXYKWSNEjouKFY5So/ap1sxOkK+6A vfi45Pl5hhbyY5TF+t1mVHNo7XGkncw5a2l7PIfmtXl9IxEPXOoST+Tl8FLXS417BSxBD9mKZ1Q ZA8e62gH0jm/tdr0joQlojktAVaJIgpj+/1yWgqEAhmnHHeGnvfQtczJ9lhtOR0fNrXtwqEuL2V VUUXnzGcUKyubJxNZpU+OjsPhIWDiJc9/81M9zct9RlPzeVuQQA04Biro9XDHh9uQP1XF3gSY2n OuLWx53TlXCKSwFieFgP1dNF1ow7ZPWrYhEvfad0c4jGwXkyPmShXk5ExDaS3e3TKu87YUUV03K e42qDJYmC1NuoSXJFEj2sPWKvtn0IF51ZLrOG6EPvK4rRmOPuWn+ZklyqxAEBwWTSM3joIzy3NH Ui0it5Zb5x/qcSShKQpxiLlDD9FXRXodL02fDcmtEzrC9eANpwu/r/HiaIrXkZj1sOgA2ijHNoF LUJY+TiCiZZOL7oZ1or4yxPAz7WdMGD8JuBXZPwEz5jkq73mUWRwz1PvGH8zGfai8NZXCpnDGOv JTZD5nvXvInwhwK20K9qlwiTElfdZPoD9V2prR0PA/ki2kI7EtU4/pKr/obV6FnwkMygZdr7kxH WmzJaGoP2Q08Uz0YNs3S39zaoXYytf6nW43O0BS11FlOYRohT3bHVzoTp+QXlh2Nyyp8x7Rd0Ww ZSVdNNJyAyqAmcb9B6yOrxc8xu+rRJDUyDHkIODaN+C/dmn1R18QpzXStTnic1EL5RdbnPtXU6t 7MmF9uFolVV/ju0HuTVkeYosXtyiBjGmb09NubKItl61J/yZUdXE/WGn0FFUew0Fl/1pHoDqtQY Cc5dyAHAopEd76v5p/0XRv5plsa+2Xd5ifmuLEqxSh1IDTwXaCR/HGkIhyv6uqFI2IIMw== X-TMASE-SNAP-Result: 1.811037.0001-0-1-22:0,12:0 Archived-At: Subject: Re: [manet] DLEP and latency metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 12:29:20 -0000 --_000_D9712B947A4CCA43AB42F01B90AF1DEC0174A9DD02AUK52982UKNUK_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KSSBkb27igJl0IHNlZSBob3cgYXBwbHlpbmcgcXVldWluZyBkZWxheSB3b3VsZCB3b3Jr IOKAkyBpZiBRb1MgKGUuZy4gODAyLjFRLTIwMDUgb3IgODAyLjFRLTIwMTEgb3Igb3RoZXIpIHF1 ZXVpbmcgaXMgYXBwbGllZCBvbiBpbmNvbWluZyB0cmFmZmljIHRoZW4gc29tZSBvZiBpdCBtYXkg d2VsbCBnZXQgYSBsb3dlciBkZWxheSB0aGFuIG90aGVycyDigJMgYnV0IHRoZXJlIGlzIG9ubHkg b25lIOKAmGxhdGVuY3nigJkgc3BlY2lmaWVkIGluIERMRVAg4oCTIHNvIGFuIGV4dGVuc2lvbiB0 byBwcm92aWRlIHF1ZXVpbmcgZGVsYXkgbWV0cmljcyB3b3VsZCBzZWVtIHRoZSBtb3N0IHNlbnNp YmxlIG9wdGlvbiB0byBtZS4NCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBEb3dkZWxsDQpTZW50OiBXZWRuZXNkYXksIE1heSAw NCwgMjAxNiAxMjo0MyBQTQ0KVG86IE1BTkVUIElFVEYNClN1YmplY3Q6IFJlOiBbbWFuZXRdIERM RVAgYW5kIGxhdGVuY3kgbWV0cmljDQoNCkkga25vdyB3ZeKAmXJlIGFsbCBhIGJpdCB0aWVkIHVw IHdpdGggdmFyaW91cyBsYXN0IGNhbGxzIGJ1dCBjYW4gSSBhc2sgZm9yIGFkanVkaWNhdGlvbiBv biB0aGlzIHBvaW50PyBUaGUgY3VycmVudCBkcmFmdCBpcyBhbWJpZ3VvdXMgYXMgdG8gd2hldGhl ciB0aGUgbGF0ZW5jeSBtZXRyaWMgaW5jbHVkZXMgdGhlIGN1cnJlbnQgcXVldWluZyBkZWxheSwg dGFraW5nIGFjY291bnQgb2YgaG93IGZ1bGwgb3Igbm90IHRoZSBxdWV1ZSBpcyBhdCB0aGUgc2Ft cGxpbmcgaW5zdGFudCwgb3IgYSBub3Rpb25hbCDigJxubyB0cmFmZmljIiBkZWxheSAoaW4gdGhl IHNhbWUgbWFubmVyIGFzIGZvciB0aGUgYmFuZHdpZHRoIG1ldHJpYyksIGFuZCB0aGVyZSBhcmUg cG9sYXJpc2VkIHZpZXdzIGZvciBhbmQgYWdhaW5zdC4NCg0KSnVzdCB0aGF0IEnigJltIGtlZW4g dG8gZ2V0IHRoaXMgb25lIGNsYXJpZmllZCBvbmUgd2F5IG9yIHRoZSBvdGhlci4NCg0KRm9sbG93 aW5nIFN0YW7igJlzIHByb3Bvc2FsIGJlbG93LCBjYW4gSSBwcm9wb3NlIHRoYXQgdGhlIExhdGVu Y3kgTWV0cmljIGlzIG1lYXN1cmVkIGluIGFic2VuY2Ugb2YgdHJhZmZpYywgYW5kIHRoYXQgYW4g ZXh0ZW5zaW9uIG1ldHJpYyBmb3IgTGluayBVdGlsaXNhdGlvbiAod2hpY2ggY291bGQgcHJvdmlk ZSBtZXRyaWNzIHBsdXJhbCkgaXMgd3JpdHRlbiB1cD8NCg0KUmVnYXJkcw0KSm9obg0KDQpPbiAy NyBBcHIgMjAxNiwgYXQgMDc6NDMsIFRlY28gQm9vdCA8dGVjb0BpbmYtbmV0Lm5sPG1haWx0bzp0 ZWNvQGluZi1uZXQubmw+PiB3cm90ZToNCg0KDQpPcCAyNyBhcHIuIDIwMTYsIG9tIDAxOjE2IGhl ZWZ0IFN0YW4gUmF0bGlmZiA8cmF0bGlmZnN0YW5AZ21haWwuY29tPG1haWx0bzpyYXRsaWZmc3Rh bkBnbWFpbC5jb20+PiBoZXQgdm9sZ2VuZGUgZ2VzY2hyZXZlbjoNCg0KSm9obiwNCg0KU3BlYWtp bmcgYXMgYSBjby1hdXRob3IgYW5kIGEgRExFUCBpbXBsZW1lbnRlciwNCg0KT24gVHVlLCBBcHIg MjYsIDIwMTYgYXQgNjowNiBQTSwgSm9obiBEb3dkZWxsIDxqb2huLmRvd2RlbGwuaWV0ZkBnbWFp bC5jb208bWFpbHRvOmpvaG4uZG93ZGVsbC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgYWxs DQoNCkEgcXVlc3Rpb24gaGFzIGFyaXNlbiBhcyB0byB3aGV0aGVyIHRoZSBMYXRlbmN5IG1ldHJp YyBzaG91bGQgaW5jbHVkZSBxdWV1ZWluZyBkZWxheSBpbiB0aGUgbW9kZW0uDQoNCkl0IGhhcyBs b25nIGJlZW4gaGVsZCB0aGF0IHRoZSBiYW5kd2lkdGggbWV0cmljIGlzIG1lYXN1cmVkIGluIHRo ZSBhYnNlbmNlIG9mIHRyYWZmaWMgKHRob3VnaCB0aGUgbWV0cmljIGRlc2NyaXB0aW9ucyBpbiAx MC4xNCBhbmQgMTAuMTUgb2YgQ3VycmVudCBEYXRhIFJhdGUgYXJlIGFtYmlndW91cyBvbiB0aGlz IHBvaW50KSwgeWV0IHNlY3Rpb24gMTAuMTYgb2YgLTIyIHN0YXRlcyAuLi4NCg0KWWVzLCB0aGF0 J3MgdGhlIHdheSBteSBpbXBsZW1lbnRhdGlvbiB3ZW50LiBJIGRvbid0IHNlZSBhIHVzZSBjYXNl IGZvciBhIGJhbmR3aWR0aCBtZXRyaWMgdGhhdCBhdHRlbXB0cyB0byB0YWtlIHRyYWZmaWMgaW50 byBhY2NvdW50LCBhbmQgaXQgc2VlbXMgdG8gbWUgbGlrZSBzdWNoIGEgbWV0cmljIGNvdWxkICh3 b3VsZCkgZmx1Y3R1YXRlIHdpbGRseS4gRnJvbSBteSBleHBlcmllbmNlLCB0aGUgImludGVyZXN0 aW5nIHN0YXRpc3RpYyIgd2FzIGFsd2F5cyAiaG93IGZhc3QgaXMgdGhlIHBpcGU/IiBUcnlpbmcg dG8gZmFjdG9yIHRyYWZmaWMgaW50byBhY2NvdW50IGNhbiBoYXZlIHJlYWxseSB3ZWlyZCBzaWRl LWVmZmVjdHMgLSBmb3IgaW5zdGFuY2UsIEkgcmVtZW1iZXIgYSByYWRpbyBpbXBsZW1lbnRhdGlv biB0aGF0IHJlcG9ydGVkIGEgIkN1cnJlbnQgRGF0YSBSYXRlIiBvZiAwIG9uIGFuIGlkbGUgbGlu ayAoYmVjYXVzZSwgYWZ0ZXIgYWxsLCBubyB0cmFmZmljIHdhcyBmbG93aW5nKS4uLiB0aGF0IGRy b3ZlIHRoZSByb3V0ZXIgbnV0cywgc2luY2UgaXQgc2F3IGEgImJyb2tlbiIgKG9yIG5lYXJseSBi cm9rZW4pIGxpbmsuDQoNCg0KDQoiIExhdGVuY3k6IEEgNjQtYml0IHVuc2lnbmVkIGludGVnZXIs IHJlcHJlc2VudGluZyB0aGUgdHJhbnNtaXNzaW9uIGRlbGF5LCBpbiBtaWNyb3NlY29uZHMsIHRo YXQgYSBwYWNrZXQgZW5jb3VudGVycyBhcyBpdCBpcyB0cmFuc21pdHRlZCBvdmVyIHRoZSBsaW5r LuKAnQ0KDQrigKYgd2hpY2ggc3VnZ2VzdHMgdGhhdCBxdWV1aW5nIGRlbGF5IHNob3VsZCBiZSBp bmNsdWRlZC4NCg0KTXVjaCBhcyBpbiB0aGUgY2FzZSBhYm92ZSwgSSBjYW4ndCBzZWUgYSB1c2Ug Y2FzZSBmb3IgYSAiTGF0ZW5jeSIgbWV0cmljICp3aXRob3V0KiBxdWV1ZWluZyBkZWxheS4NCg0K SSBkb24ndCBnZXQgdGhpcy4gQWJvdmUsIHlvdSBzdWdnZXN0IHRyYWZmaWMgaXMgbm90IHRha2Vu IGludG8gYWNjb3VudC4gSGVyZSwgeW91IHN1Z2dlc3QgcXVldWluZyBkZWxheSAoY2F1c2VkIGJ5 IHRyYWZmaWM/KSBpcyB0YWtlbiBpbnRvIGFjY291bnQuDQoNCkkgc3VnZ2VzdCBwYWNrZXQgaGFu ZGxpbmcgZGVsYXkgZm9yIGEgc2luZ2xlIHBhY2tldCBvbiBhbiBpZGxlIG1lZGl1bSBpcyB0YWtl biBpbnRvIGFjY291bnQuIERlbGF5IGNhdXNlZCBieSBmaWxsZWQgdXAgcXVldWVzIGlzIG5vdC4g UXVldWUgZGVwdGggd291bGQgYmUgYW5vdGhlciBtZXRyaWMuIFdoaWNoIHdvdWxkIGZsdWN0dWF0 ZSB3aWxkbHleXjIuIEFuZCBjb3VsZCBiZSBhIGNvbXBsZXggY29tcG9zaXRlIG1ldHJpYyB3aGVu ICpGUSBpcyB1c2VkLiBTZWUgUkZDIDc1NjcgLyBCQ1AgMTk3IG9uIHdoYXQgcGFja2V0IGZvcndh cmRpbmcgZGV2aWNlcyBTSE9VTEQgZG8uDQoNClRlY28NCg0KDQoNCg0KDQpUaGVyZSBhcmUgcG9z aXRpdmUgYW5kIG5lZ2F0aXZlIGNvbm5vdGF0aW9uczsgYSBtb2RlbSBxdWV1ZSB0aGF0IHN1ZGRl bmx5IGJlY29tZXMgZnVsbCBtaWdodCBub3QgaGF2ZSBhbnkgbW9yZSBkYXRhIHF1ZXVlZCB0byBp dCwgb3IgYSBETEVQLXBvd2VyZWQgcm91dGluZyBhbGdvcml0aG0gbWlnaHQgY2hvb3NlIGFub3Ro ZXIgbW9kZW0gaW5zdGVhZCwgYWxsb3dpbmcgdGhlIHF1ZXVlIHRvIHN1YnNpZGUsIGJ1dCB0aGF0 IG1pZ2h0IG5vdCBiZSB3aGF0IHRoZSBzeXN0ZW0gaW50ZWdyYXRvciB3YW50ZWQgdG8gaGFwcGVu Lg0KDQpBbmQgdGhhdCB3b3VsZCBkZXBlbmQgb24gYSBsb3Qgb2YgY29kZSB0aGF0IG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoZSBETEVQIHNwZWMgLSBzcGVjaWZpY2FsbHksIGl0IGRlcGVuZHMgb24g aG93IGFuIGFsZ29yaXRobSBhY3R1YWxseSAqZGVhbHMqIHdpdGggdGhlIERMRVAgbWV0cmljcyBz dXBwbGllZC4NCg0KSGF2aW5nIHNhaWQgYWxsIG9mIHRoYXQsIEkgY2FuIHNlZSBhIHBvc3NpYmls aXR5IGZvciBhIGNvdXBsZSBvZiBmb2xsb3ctb24gbWV0cmljcyBmb3IgYSBETEVQIGV4dGVuc2lv biAtIHRoZSBmaXJzdCB3b3VsZCBiZSBhICJMaW5rIFV0aWxpemF0aW9uIiBtZXRyaWMuIFRoZSBv dGhlciB3b3VsZCBiZSBhICJQcm9wYWdhdGlvbiBkZWxheSIgbWV0cmljLCBiYXNlZCBvbiB0aGUg cGh5c2ljYWwgcHJvcGVydGllcyBvZiB0aGUgdHJhbnNtaXNzaW9uIG1lZGl1bS4NCg0KSnVzdCBh IHRob3VnaHQuDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5v cmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tYW5ldA0KDQoNClRoaXMgZW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMp IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBv ciBpbmZvcm1hdGlvbiBvdGhlcndpc2UgcHJvdGVjdGVkIGZyb20gZGlzY2xvc3VyZS4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5LCBkbyBub3QgY29weSB0aGlzIG1lc3NhZ2Ugb3IgYW55IGF0dGFjaG1lbnRz IGFuZCBkbyBub3QgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBvciBkaXNjbG9zZSBpdHMgY29udGVu dCB0byBhbnkgcGVyc29uLCBidXQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1l bnRzIGZyb20geW91ciBzeXN0ZW0uIEFpcmJ1cyBEZWZlbmNlIGFuZCBTcGFjZSBMaW1pdGVkIGRp c2NsYWltcyBhbnkgYW5kIGFsbCBsaWFiaWxpdHkgaWYgdGhpcyBlbWFpbCB0cmFuc21pc3Npb24g d2FzIHZpcnVzIGNvcnJ1cHRlZCwgYWx0ZXJlZCBvciBmYWxzaWZpZWQuDQotby0NCkVtYWlscyB0 byBBaXJidXMgRGVmZW5jZSBhbmQgU3BhY2UgTGltaXRlZCBtYXkgYmUgcHJvY2Vzc2VkLCByZWNv cmRlZCBhbmQgbW9uaXRvcmVkIG91dHNpZGUgdGhlIFVLLg0KLW8tDQpBaXJidXMgRGVmZW5jZSBh bmQgU3BhY2UgTGltaXRlZCwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcyBOby4gMjQ0 OTI1OQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IEd1bm5lbHMgV29vZCBSb2FkLCBTdGV2ZW5hZ2UsIEhl cnRmb3Jkc2hpcmUsIFNHMSAyQVMsIEVuZ2xhbmQ= --_000_D9712B947A4CCA43AB42F01B90AF1DEC0174A9DD02AUK52982UKNUK_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiYjNDM7MQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgc2VlIGhvdyBhcHBseWluZyBxdWV1aW5n IGRlbGF5IHdvdWxkIHdvcmsg4oCTIGlmIFFvUyAoZS5nLiA4MDIuMVEtMjAwNSBvciA4MDIuMVEt MjAxMSBvciBvdGhlcikgcXVldWluZyBpcyBhcHBsaWVkIG9uIGluY29taW5nIHRyYWZmaWMgdGhl biBzb21lIG9mIGl0DQogbWF5IHdlbGwgZ2V0IGEgbG93ZXIgZGVsYXkgdGhhbiBvdGhlcnMg4oCT IGJ1dCB0aGVyZSBpcyBvbmx5IG9uZSDigJhsYXRlbmN54oCZIHNwZWNpZmllZCBpbiBETEVQIOKA kyBzbyBhbiBleHRlbnNpb24gdG8gcHJvdmlkZSBxdWV1aW5nIGRlbGF5IG1ldHJpY3Mgd291bGQg c2VlbSB0aGUgbW9zdCBzZW5zaWJsZSBvcHRpb24gdG8gbWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWFuZXQg W21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2hu IERvd2RlbGw8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMDQsIDIwMTYgMTI6NDMg UE08YnI+DQo8Yj5Ubzo8L2I+IE1BTkVUIElFVEY8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtt YW5ldF0gRExFUCBhbmQgbGF0ZW5jeSBtZXRyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBrbm93IHdl4oCZcmUgYWxsIGEgYml0IHRpZWQg dXAgd2l0aCB2YXJpb3VzIGxhc3QgY2FsbHMgYnV0IGNhbiBJIGFzayBmb3IgYWRqdWRpY2F0aW9u IG9uIHRoaXMgcG9pbnQ/IFRoZSBjdXJyZW50IGRyYWZ0IGlzIGFtYmlndW91cyBhcyB0byB3aGV0 aGVyIHRoZSBsYXRlbmN5IG1ldHJpYyBpbmNsdWRlcyB0aGUgY3VycmVudCBxdWV1aW5nIGRlbGF5 LCB0YWtpbmcgYWNjb3VudCBvZiBob3cgZnVsbCBvciBub3QgdGhlDQogcXVldWUgaXMgYXQgdGhl IHNhbXBsaW5nIGluc3RhbnQsIG9yIGEgbm90aW9uYWwg4oCcbm8gdHJhZmZpYyZxdW90OyBkZWxh eSAoaW4gdGhlIHNhbWUgbWFubmVyIGFzIGZvciB0aGUgYmFuZHdpZHRoIG1ldHJpYyksIGFuZCB0 aGVyZSBhcmUgcG9sYXJpc2VkIHZpZXdzIGZvciBhbmQgYWdhaW5zdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCB0aGF0IEnigJltIGtl ZW4gdG8gZ2V0IHRoaXMgb25lIGNsYXJpZmllZCBvbmUgd2F5IG9yIHRoZSBvdGhlci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9sbG93aW5n IFN0YW7igJlzIHByb3Bvc2FsIGJlbG93LCBjYW4gSSBwcm9wb3NlIHRoYXQgdGhlIExhdGVuY3kg TWV0cmljIGlzIG1lYXN1cmVkIGluIGFic2VuY2Ugb2YgdHJhZmZpYywgYW5kIHRoYXQgYW4gZXh0 ZW5zaW9uIG1ldHJpYyBmb3IgTGluayBVdGlsaXNhdGlvbiAod2hpY2ggY291bGQgcHJvdmlkZSBt ZXRyaWNzIHBsdXJhbCkgaXMgd3JpdHRlbiB1cD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9objxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyNyBBcHIgMjAxNiwgYXQgMDc6NDMsIFRlY28g Qm9vdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlY29AaW5mLW5ldC5ubCI+dGVjb0BpbmYtbmV0Lm5s PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCk9wIDI3IGFwci4gMjAxNiwg b20gMDE6MTYgaGVlZnQgU3RhbiBSYXRsaWZmICZsdDs8YSBocmVmPSJtYWlsdG86cmF0bGlmZnN0 YW5AZ21haWwuY29tIj5yYXRsaWZmc3RhbkBnbWFpbC5jb208L2E+Jmd0OyBoZXQgdm9sZ2VuZGUg Z2VzY2hyZXZlbjo8YnI+DQo8YnI+DQpKb2huLDxicj4NCjxicj4NClNwZWFraW5nIGFzIGEgY28t YXV0aG9yIGFuZCBhIERMRVAgaW1wbGVtZW50ZXIsPGJyPg0KPGJyPg0KT24gVHVlLCBBcHIgMjYs IDIwMTYgYXQgNjowNiBQTSwgSm9obiBEb3dkZWxsICZsdDs8YSBocmVmPSJtYWlsdG86am9obi5k b3dkZWxsLmlldGZAZ21haWwuY29tIj5qb2huLmRvd2RlbGwuaWV0ZkBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQpIaSBhbGw8YnI+DQo8YnI+DQpBIHF1ZXN0aW9uIGhhcyBhcmlzZW4gYXMg dG8gd2hldGhlciB0aGUgTGF0ZW5jeSBtZXRyaWMgc2hvdWxkIGluY2x1ZGUgcXVldWVpbmcgZGVs YXkgaW4gdGhlIG1vZGVtLjxicj4NCjxicj4NCkl0IGhhcyBsb25nIGJlZW4gaGVsZCB0aGF0IHRo ZSBiYW5kd2lkdGggbWV0cmljIGlzIG1lYXN1cmVkIGluIHRoZSBhYnNlbmNlIG9mIHRyYWZmaWMg KHRob3VnaCB0aGUgbWV0cmljIGRlc2NyaXB0aW9ucyBpbiAxMC4xNCBhbmQgMTAuMTUgb2YgQ3Vy cmVudCBEYXRhIFJhdGUgYXJlIGFtYmlndW91cyBvbiB0aGlzIHBvaW50KSwgeWV0IHNlY3Rpb24g MTAuMTYgb2YgLTIyIHN0YXRlcyAuLi48YnI+DQo8YnI+DQpZZXMsIHRoYXQncyB0aGUgd2F5IG15 IGltcGxlbWVudGF0aW9uIHdlbnQuIEkgZG9uJ3Qgc2VlIGEgdXNlIGNhc2UgZm9yIGEgYmFuZHdp ZHRoIG1ldHJpYyB0aGF0IGF0dGVtcHRzIHRvIHRha2UgdHJhZmZpYyBpbnRvIGFjY291bnQsIGFu ZCBpdCBzZWVtcyB0byBtZSBsaWtlIHN1Y2ggYSBtZXRyaWMgY291bGQgKHdvdWxkKSBmbHVjdHVh dGUgd2lsZGx5LiBGcm9tIG15IGV4cGVyaWVuY2UsIHRoZSAmcXVvdDtpbnRlcmVzdGluZyBzdGF0 aXN0aWMmcXVvdDsgd2FzIGFsd2F5cw0KICZxdW90O2hvdyBmYXN0IGlzIHRoZSBwaXBlPyZxdW90 OyBUcnlpbmcgdG8gZmFjdG9yIHRyYWZmaWMgaW50byBhY2NvdW50IGNhbiBoYXZlIHJlYWxseSB3 ZWlyZCBzaWRlLWVmZmVjdHMgLSBmb3IgaW5zdGFuY2UsIEkgcmVtZW1iZXIgYSByYWRpbyBpbXBs ZW1lbnRhdGlvbiB0aGF0IHJlcG9ydGVkIGEgJnF1b3Q7Q3VycmVudCBEYXRhIFJhdGUmcXVvdDsg b2YgMCBvbiBhbiBpZGxlIGxpbmsgKGJlY2F1c2UsIGFmdGVyIGFsbCwgbm8gdHJhZmZpYyB3YXMg Zmxvd2luZykuLi4gdGhhdA0KIGRyb3ZlIHRoZSByb3V0ZXIgbnV0cywgc2luY2UgaXQgc2F3IGEg JnF1b3Q7YnJva2VuJnF1b3Q7IChvciBuZWFybHkgYnJva2VuKSBsaW5rLjxicj4NCjxicj4NCjxi cj4NCjxicj4NCiZxdW90OyBMYXRlbmN5OiBBIDY0LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLCByZXBy ZXNlbnRpbmcgdGhlIHRyYW5zbWlzc2lvbiBkZWxheSwgaW4gbWljcm9zZWNvbmRzLCB0aGF0IGEg cGFja2V0IGVuY291bnRlcnMgYXMgaXQgaXMgdHJhbnNtaXR0ZWQgb3ZlciB0aGUgbGluay7igJ08 YnI+DQo8YnI+DQrigKYgd2hpY2ggc3VnZ2VzdHMgdGhhdCBxdWV1aW5nIGRlbGF5IHNob3VsZCBi ZSBpbmNsdWRlZC48YnI+DQo8YnI+DQpNdWNoIGFzIGluIHRoZSBjYXNlIGFib3ZlLCBJIGNhbid0 IHNlZSBhIHVzZSBjYXNlIGZvciBhICZxdW90O0xhdGVuY3kmcXVvdDsgbWV0cmljICp3aXRob3V0 KiBxdWV1ZWluZyBkZWxheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpJ IGRvbid0IGdldCB0aGlzLiBBYm92ZSwgeW91IHN1Z2dlc3QgdHJhZmZpYyBpcyBub3QgdGFrZW4g aW50byBhY2NvdW50LiBIZXJlLCB5b3Ugc3VnZ2VzdCBxdWV1aW5nIGRlbGF5IChjYXVzZWQgYnkg dHJhZmZpYz8pIGlzIHRha2VuIGludG8gYWNjb3VudC48YnI+DQo8YnI+DQpJIHN1Z2dlc3QgcGFj a2V0IGhhbmRsaW5nIGRlbGF5IGZvciBhIHNpbmdsZSBwYWNrZXQgb24gYW4gaWRsZSBtZWRpdW0g aXMgdGFrZW4gaW50byBhY2NvdW50LiBEZWxheSBjYXVzZWQgYnkgZmlsbGVkIHVwIHF1ZXVlcyBp cyBub3QuIFF1ZXVlIGRlcHRoIHdvdWxkIGJlIGFub3RoZXIgbWV0cmljLiBXaGljaCB3b3VsZCBm bHVjdHVhdGUgd2lsZGx5Xl4yLiBBbmQgY291bGQgYmUgYSBjb21wbGV4IGNvbXBvc2l0ZSBtZXRy aWMgd2hlbiAqRlEgaXMgdXNlZC4NCiBTZWUgUkZDIDc1NjcgLyBCQ1AgMTk3IG9uIHdoYXQgcGFj a2V0IGZvcndhcmRpbmcgZGV2aWNlcyBTSE9VTEQgZG8uPGJyPg0KPGJyPg0KVGVjbzxicj4NCjxi cj4NCjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3Rl eHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4N ClRoZXJlIGFyZSBwb3NpdGl2ZSBhbmQgbmVnYXRpdmUgY29ubm90YXRpb25zOyBhIG1vZGVtIHF1 ZXVlIHRoYXQgc3VkZGVubHkgYmVjb21lcyBmdWxsIG1pZ2h0IG5vdCBoYXZlIGFueSBtb3JlIGRh dGEgcXVldWVkIHRvIGl0LCBvciBhIERMRVAtcG93ZXJlZCByb3V0aW5nIGFsZ29yaXRobSBtaWdo dCBjaG9vc2UgYW5vdGhlciBtb2RlbSBpbnN0ZWFkLCBhbGxvd2luZyB0aGUgcXVldWUgdG8gc3Vi c2lkZSwgYnV0IHRoYXQgbWlnaHQgbm90IGJlIHdoYXQNCiB0aGUgc3lzdGVtIGludGVncmF0b3Ig d2FudGVkIHRvIGhhcHBlbi48YnI+DQo8YnI+DQpBbmQgdGhhdCB3b3VsZCBkZXBlbmQgb24gYSBs b3Qgb2YgY29kZSB0aGF0IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBETEVQIHNwZWMgLSBzcGVj aWZpY2FsbHksIGl0IGRlcGVuZHMgb24gaG93IGFuIGFsZ29yaXRobSBhY3R1YWxseSAqZGVhbHMq IHdpdGggdGhlIERMRVAgbWV0cmljcyBzdXBwbGllZC48YnI+DQo8YnI+DQpIYXZpbmcgc2FpZCBh bGwgb2YgdGhhdCwgSSBjYW4gc2VlIGEgcG9zc2liaWxpdHkgZm9yIGEgY291cGxlIG9mIGZvbGxv dy1vbiBtZXRyaWNzIGZvciBhIERMRVAgZXh0ZW5zaW9uIC0gdGhlIGZpcnN0IHdvdWxkIGJlIGEg JnF1b3Q7TGluayBVdGlsaXphdGlvbiZxdW90OyBtZXRyaWMuIFRoZSBvdGhlciB3b3VsZCBiZSBh ICZxdW90O1Byb3BhZ2F0aW9uIGRlbGF5JnF1b3Q7IG1ldHJpYywgYmFzZWQgb24gdGhlIHBoeXNp Y2FsIHByb3BlcnRpZXMgb2YgdGhlIHRyYW5zbWlzc2lvbiBtZWRpdW0uPGJyPg0KPGJyPg0KSnVz dCBhIHRob3VnaHQuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpTdGFuPGJyPg0KPGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpt YW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1h bmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWFuZXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWFuZXQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0jZmZm ZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+PHByZT5UaGlzIGVtYWlsIChpbmNsdWRpbmcgYW55IGF0 dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gb3IgaW5mb3JtYXRpb24gb3RoZXJ3aXNlIHByb3RlY3RlZCBmcm9tIGRpc2Nsb3N1 cmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZG8gbm90IGNvcHkgdGhpcyBtZXNzYWdlIG9yIGFueSBh dHRhY2htZW50cyBhbmQgZG8gbm90IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugb3IgZGlzY2xvc2Ug aXRzIGNvbnRlbnQgdG8gYW55IHBlcnNvbiwgYnV0IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFu eSBhdHRhY2htZW50cyBmcm9tIHlvdXIgc3lzdGVtLiBBaXJidXMgRGVmZW5jZSBhbmQgU3BhY2Ug TGltaXRlZCBkaXNjbGFpbXMgYW55IGFuZCBhbGwgbGlhYmlsaXR5IGlmIHRoaXMgZW1haWwgdHJh bnNtaXNzaW9uIHdhcyB2aXJ1cyBjb3JydXB0ZWQsIGFsdGVyZWQgb3IgZmFsc2lmaWVkLg0KLW8t DQpFbWFpbHMgdG8gQWlyYnVzIERlZmVuY2UgYW5kIFNwYWNlIExpbWl0ZWQgbWF5IGJlIHByb2Nl c3NlZCwgcmVjb3JkZWQgYW5kIG1vbml0b3JlZCBvdXRzaWRlIHRoZSBVSy4NCi1vLQ0KQWlyYnVz IERlZmVuY2UgYW5kIFNwYWNlIExpbWl0ZWQsIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2Fs ZXMgTm8uIDI0NDkyNTkNClJlZ2lzdGVyZWQgT2ZmaWNlOiBHdW5uZWxzIFdvb2QgUm9hZCwgU3Rl dmVuYWdlLCBIZXJ0Zm9yZHNoaXJlLCBTRzEgMkFTLCBFbmdsYW5kPC9wcmU+PC9mb250PjwvdGQ+ PC90cj48L3RhYmxlPg== --_000_D9712B947A4CCA43AB42F01B90AF1DEC0174A9DD02AUK52982UKNUK_-- From nobody Wed May 4 05:38:49 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2325B12D667 for ; Wed, 4 May 2016 05:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQC-H1_lKsSc for ; Wed, 4 May 2016 05:38:45 -0700 (PDT) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D234212D691 for ; Wed, 4 May 2016 05:38:44 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,577,1454976000"; d="scan'208,217"; a="34677736" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 04 May 2016 13:38:41 +0100 X-IronPort-AV: E=Sophos;i="5.24,577,1454976000"; d="scan'208,217";a="116653182" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 04 May 2016 13:38:41 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.88]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Wed, 4 May 2016 13:38:41 +0100 From: "Dearlove, Christopher (UK)" To: John Dowdell , MANET IETF Thread-Topic: [manet] DLEP and latency metric Thread-Index: AQHRoAgNXqv1Mir4G0y/4T79aUI8x5+c0nQAgAB9EICAC1PZAIAAH/Vw Date: Wed, 4 May 2016 12:38:40 +0000 Message-ID: References: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com> <2DC54CCE-46BE-48D0-9497-52D31DCB5B40@inf-net.nl> <8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> In-Reply-To: <8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2E92GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP and latency metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 12:38:48 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2E92GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 V2FzIHRoZSBzdWdnZXN0aW9uIHRvIGluY2x1ZGUgYW4gZW1wdHkgcXVldWluZyBkZWxheSwgaS5l LiBpdCBpbmNsdWRlZCBldmVyeXRoaW5nLCBidXQgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIHF1ZXVl IHdhcyBlbXB0eT8gVGhhdCBzb3VuZHMgbGlrZSBhIHNlbnNpYmxlIGFwcHJvYWNoLCBhc3N1bWlu ZyBpdOKAmXMgcmVhc29uYWJseSBzdGFibGUuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0K U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQy MTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVh cmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl LCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBF c3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVt cy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdp c3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNl OiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJv bTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9o biBEb3dkZWxsDQpTZW50OiAwNCBNYXkgMjAxNiAxMjo0Mw0KVG86IE1BTkVUIElFVEYNClN1Ympl Y3Q6IFJlOiBbbWFuZXRdIERMRVAgYW5kIGxhdGVuY3kgbWV0cmljDQoNCg0KKioqIFdBUk5JTkcg KioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25z aWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3Bl biBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJl ZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwg Y2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9z ZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZl ZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0 dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3Rs aWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+ Lg0KKioqIFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2lu YXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KSSBrbm93IHdl4oCZcmUgYWxs IGEgYml0IHRpZWQgdXAgd2l0aCB2YXJpb3VzIGxhc3QgY2FsbHMgYnV0IGNhbiBJIGFzayBmb3Ig YWRqdWRpY2F0aW9uIG9uIHRoaXMgcG9pbnQ/IFRoZSBjdXJyZW50IGRyYWZ0IGlzIGFtYmlndW91 cyBhcyB0byB3aGV0aGVyIHRoZSBsYXRlbmN5IG1ldHJpYyBpbmNsdWRlcyB0aGUgY3VycmVudCBx dWV1aW5nIGRlbGF5LCB0YWtpbmcgYWNjb3VudCBvZiBob3cgZnVsbCBvciBub3QgdGhlIHF1ZXVl IGlzIGF0IHRoZSBzYW1wbGluZyBpbnN0YW50LCBvciBhIG5vdGlvbmFsIOKAnG5vIHRyYWZmaWMi IGRlbGF5IChpbiB0aGUgc2FtZSBtYW5uZXIgYXMgZm9yIHRoZSBiYW5kd2lkdGggbWV0cmljKSwg YW5kIHRoZXJlIGFyZSBwb2xhcmlzZWQgdmlld3MgZm9yIGFuZCBhZ2FpbnN0Lg0KDQpKdXN0IHRo YXQgSeKAmW0ga2VlbiB0byBnZXQgdGhpcyBvbmUgY2xhcmlmaWVkIG9uZSB3YXkgb3IgdGhlIG90 aGVyLg0KDQpGb2xsb3dpbmcgU3RhbuKAmXMgcHJvcG9zYWwgYmVsb3csIGNhbiBJIHByb3Bvc2Ug dGhhdCB0aGUgTGF0ZW5jeSBNZXRyaWMgaXMgbWVhc3VyZWQgaW4gYWJzZW5jZSBvZiB0cmFmZmlj LCBhbmQgdGhhdCBhbiBleHRlbnNpb24gbWV0cmljIGZvciBMaW5rIFV0aWxpc2F0aW9uICh3aGlj aCBjb3VsZCBwcm92aWRlIG1ldHJpY3MgcGx1cmFsKSBpcyB3cml0dGVuIHVwPw0KDQpSZWdhcmRz DQpKb2huDQoNCk9uIDI3IEFwciAyMDE2LCBhdCAwNzo0MywgVGVjbyBCb290IDx0ZWNvQGluZi1u ZXQubmw8bWFpbHRvOnRlY29AaW5mLW5ldC5ubD4+IHdyb3RlOg0KDQoNCk9wIDI3IGFwci4gMjAx Niwgb20gMDE6MTYgaGVlZnQgU3RhbiBSYXRsaWZmIDxyYXRsaWZmc3RhbkBnbWFpbC5jb208bWFp bHRvOnJhdGxpZmZzdGFuQGdtYWlsLmNvbT4+IGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOg0KDQpK b2huLA0KDQpTcGVha2luZyBhcyBhIGNvLWF1dGhvciBhbmQgYSBETEVQIGltcGxlbWVudGVyLA0K DQpPbiBUdWUsIEFwciAyNiwgMjAxNiBhdCA2OjA2IFBNLCBKb2huIERvd2RlbGwgPGpvaG4uZG93 ZGVsbC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86am9obi5kb3dkZWxsLmlldGZAZ21haWwuY29tPj4g d3JvdGU6DQpIaSBhbGwNCg0KQSBxdWVzdGlvbiBoYXMgYXJpc2VuIGFzIHRvIHdoZXRoZXIgdGhl IExhdGVuY3kgbWV0cmljIHNob3VsZCBpbmNsdWRlIHF1ZXVlaW5nIGRlbGF5IGluIHRoZSBtb2Rl bS4NCg0KSXQgaGFzIGxvbmcgYmVlbiBoZWxkIHRoYXQgdGhlIGJhbmR3aWR0aCBtZXRyaWMgaXMg bWVhc3VyZWQgaW4gdGhlIGFic2VuY2Ugb2YgdHJhZmZpYyAodGhvdWdoIHRoZSBtZXRyaWMgZGVz Y3JpcHRpb25zIGluIDEwLjE0IGFuZCAxMC4xNSBvZiBDdXJyZW50IERhdGEgUmF0ZSBhcmUgYW1i aWd1b3VzIG9uIHRoaXMgcG9pbnQpLCB5ZXQgc2VjdGlvbiAxMC4xNiBvZiAtMjIgc3RhdGVzIC4u Lg0KDQpZZXMsIHRoYXQncyB0aGUgd2F5IG15IGltcGxlbWVudGF0aW9uIHdlbnQuIEkgZG9uJ3Qg c2VlIGEgdXNlIGNhc2UgZm9yIGEgYmFuZHdpZHRoIG1ldHJpYyB0aGF0IGF0dGVtcHRzIHRvIHRh a2UgdHJhZmZpYyBpbnRvIGFjY291bnQsIGFuZCBpdCBzZWVtcyB0byBtZSBsaWtlIHN1Y2ggYSBt ZXRyaWMgY291bGQgKHdvdWxkKSBmbHVjdHVhdGUgd2lsZGx5LiBGcm9tIG15IGV4cGVyaWVuY2Us IHRoZSAiaW50ZXJlc3Rpbmcgc3RhdGlzdGljIiB3YXMgYWx3YXlzICJob3cgZmFzdCBpcyB0aGUg cGlwZT8iIFRyeWluZyB0byBmYWN0b3IgdHJhZmZpYyBpbnRvIGFjY291bnQgY2FuIGhhdmUgcmVh bGx5IHdlaXJkIHNpZGUtZWZmZWN0cyAtIGZvciBpbnN0YW5jZSwgSSByZW1lbWJlciBhIHJhZGlv IGltcGxlbWVudGF0aW9uIHRoYXQgcmVwb3J0ZWQgYSAiQ3VycmVudCBEYXRhIFJhdGUiIG9mIDAg b24gYW4gaWRsZSBsaW5rIChiZWNhdXNlLCBhZnRlciBhbGwsIG5vIHRyYWZmaWMgd2FzIGZsb3dp bmcpLi4uIHRoYXQgZHJvdmUgdGhlIHJvdXRlciBudXRzLCBzaW5jZSBpdCBzYXcgYSAiYnJva2Vu IiAob3IgbmVhcmx5IGJyb2tlbikgbGluay4NCg0KDQoNCiIgTGF0ZW5jeTogQSA2NC1iaXQgdW5z aWduZWQgaW50ZWdlciwgcmVwcmVzZW50aW5nIHRoZSB0cmFuc21pc3Npb24gZGVsYXksIGluIG1p Y3Jvc2Vjb25kcywgdGhhdCBhIHBhY2tldCBlbmNvdW50ZXJzIGFzIGl0IGlzIHRyYW5zbWl0dGVk IG92ZXIgdGhlIGxpbmsu4oCdDQoNCuKApiB3aGljaCBzdWdnZXN0cyB0aGF0IHF1ZXVpbmcgZGVs YXkgc2hvdWxkIGJlIGluY2x1ZGVkLg0KDQpNdWNoIGFzIGluIHRoZSBjYXNlIGFib3ZlLCBJIGNh bid0IHNlZSBhIHVzZSBjYXNlIGZvciBhICJMYXRlbmN5IiBtZXRyaWMgKndpdGhvdXQqIHF1ZXVl aW5nIGRlbGF5Lg0KDQpJIGRvbid0IGdldCB0aGlzLiBBYm92ZSwgeW91IHN1Z2dlc3QgdHJhZmZp YyBpcyBub3QgdGFrZW4gaW50byBhY2NvdW50LiBIZXJlLCB5b3Ugc3VnZ2VzdCBxdWV1aW5nIGRl bGF5IChjYXVzZWQgYnkgdHJhZmZpYz8pIGlzIHRha2VuIGludG8gYWNjb3VudC4NCg0KSSBzdWdn ZXN0IHBhY2tldCBoYW5kbGluZyBkZWxheSBmb3IgYSBzaW5nbGUgcGFja2V0IG9uIGFuIGlkbGUg bWVkaXVtIGlzIHRha2VuIGludG8gYWNjb3VudC4gRGVsYXkgY2F1c2VkIGJ5IGZpbGxlZCB1cCBx dWV1ZXMgaXMgbm90LiBRdWV1ZSBkZXB0aCB3b3VsZCBiZSBhbm90aGVyIG1ldHJpYy4gV2hpY2gg d291bGQgZmx1Y3R1YXRlIHdpbGRseV5eMi4gQW5kIGNvdWxkIGJlIGEgY29tcGxleCBjb21wb3Np dGUgbWV0cmljIHdoZW4gKkZRIGlzIHVzZWQuIFNlZSBSRkMgNzU2NyAvIEJDUCAxOTcgb24gd2hh dCBwYWNrZXQgZm9yd2FyZGluZyBkZXZpY2VzIFNIT1VMRCBkby4NCg0KVGVjbw0KDQoNCg0KDQoN ClRoZXJlIGFyZSBwb3NpdGl2ZSBhbmQgbmVnYXRpdmUgY29ubm90YXRpb25zOyBhIG1vZGVtIHF1 ZXVlIHRoYXQgc3VkZGVubHkgYmVjb21lcyBmdWxsIG1pZ2h0IG5vdCBoYXZlIGFueSBtb3JlIGRh dGEgcXVldWVkIHRvIGl0LCBvciBhIERMRVAtcG93ZXJlZCByb3V0aW5nIGFsZ29yaXRobSBtaWdo dCBjaG9vc2UgYW5vdGhlciBtb2RlbSBpbnN0ZWFkLCBhbGxvd2luZyB0aGUgcXVldWUgdG8gc3Vi c2lkZSwgYnV0IHRoYXQgbWlnaHQgbm90IGJlIHdoYXQgdGhlIHN5c3RlbSBpbnRlZ3JhdG9yIHdh bnRlZCB0byBoYXBwZW4uDQoNCkFuZCB0aGF0IHdvdWxkIGRlcGVuZCBvbiBhIGxvdCBvZiBjb2Rl IHRoYXQgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIERMRVAgc3BlYyAtIHNwZWNpZmljYWxseSwg aXQgZGVwZW5kcyBvbiBob3cgYW4gYWxnb3JpdGhtIGFjdHVhbGx5ICpkZWFscyogd2l0aCB0aGUg RExFUCBtZXRyaWNzIHN1cHBsaWVkLg0KDQpIYXZpbmcgc2FpZCBhbGwgb2YgdGhhdCwgSSBjYW4g c2VlIGEgcG9zc2liaWxpdHkgZm9yIGEgY291cGxlIG9mIGZvbGxvdy1vbiBtZXRyaWNzIGZvciBh IERMRVAgZXh0ZW5zaW9uIC0gdGhlIGZpcnN0IHdvdWxkIGJlIGEgIkxpbmsgVXRpbGl6YXRpb24i IG1ldHJpYy4gVGhlIG90aGVyIHdvdWxkIGJlIGEgIlByb3BhZ2F0aW9uIGRlbGF5IiBtZXRyaWMs IGJhc2VkIG9uIHRoZSBwaHlzaWNhbCBwcm9wZXJ0aWVzIG9mIHRoZSB0cmFuc21pc3Npb24gbWVk aXVtLg0KDQpKdXN0IGEgdGhvdWdodC4NCg0KUmVnYXJkcywNClN0YW4NCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0 DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGll bnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkg dGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJw b3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKgo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2E92GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPldhcyB0aGUgc3VnZ2VzdGlvbiB0byBpbmNsdWRlIGFuIGVtcHR5IHF1ZXVpbmcgZGVsYXks IGkuZS4gaXQgaW5jbHVkZWQgZXZlcnl0aGluZywgYnV0IGluIHRoZSBjYXNlIHdoZXJlIHRoZSBx dWV1ZSB3YXMgZW1wdHk/IFRoYXQgc291bmRzIGxpa2UgYSBzZW5zaWJsZSBhcHByb2FjaCwNCiBh c3N1bWluZyBpdOKAmXMgcmVhc29uYWJseSBzdGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8 YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJ bnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFu PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgw KTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJtYWlsdG86Y2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t PC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+ PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUg U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmss IEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJo dHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+ d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5 MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTog U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0IFttYWls dG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBEb3dk ZWxsPGJyPg0KPGI+U2VudDo8L2I+IDA0IE1heSAyMDE2IDEyOjQzPGJyPg0KPGI+VG86PC9iPiBN QU5FVCBJRVRGPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIERMRVAgYW5kIGxhdGVu Y3kgbWV0cmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNv bGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286cD48L3Nw YW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNr Z3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5 NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9u LCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+ PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxl bT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBv biBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxi cj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2Vt Pjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJl ZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMg eW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0 ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxh Z3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1h aWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0 LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVu dHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0aGlzIHByb2Nl c3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MS4w cHQgNC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KioN Cjwvc3Bhbj48L3N0cm9uZz48L3NwYW4+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5XQVJOSU5HDQo8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KioqPC9zcGFuPjwv c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVz IGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGtub3cgd2XigJlyZSBhbGwgYSBiaXQgdGllZCB1cCB3aXRoIHZhcmlvdXMgbGFzdCBj YWxscyBidXQgY2FuIEkgYXNrIGZvciBhZGp1ZGljYXRpb24gb24gdGhpcyBwb2ludD8gVGhlIGN1 cnJlbnQgZHJhZnQgaXMgYW1iaWd1b3VzIGFzIHRvIHdoZXRoZXIgdGhlIGxhdGVuY3kgbWV0cmlj IGluY2x1ZGVzIHRoZSBjdXJyZW50IHF1ZXVpbmcgZGVsYXksIHRha2luZyBhY2NvdW50IG9mIGhv dyBmdWxsIG9yIG5vdCB0aGUNCiBxdWV1ZSBpcyBhdCB0aGUgc2FtcGxpbmcgaW5zdGFudCwgb3Ig YSBub3Rpb25hbCDigJxubyB0cmFmZmljJnF1b3Q7IGRlbGF5IChpbiB0aGUgc2FtZSBtYW5uZXIg YXMgZm9yIHRoZSBiYW5kd2lkdGggbWV0cmljKSwgYW5kIHRoZXJlIGFyZSBwb2xhcmlzZWQgdmll d3MgZm9yIGFuZCBhZ2FpbnN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5KdXN0IHRoYXQgSeKAmW0ga2VlbiB0byBnZXQgdGhpcyBvbmUgY2xh cmlmaWVkIG9uZSB3YXkgb3IgdGhlIG90aGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb2xsb3dpbmcgU3RhbuKAmXMgcHJvcG9zYWwgYmVs b3csIGNhbiBJIHByb3Bvc2UgdGhhdCB0aGUgTGF0ZW5jeSBNZXRyaWMgaXMgbWVhc3VyZWQgaW4g YWJzZW5jZSBvZiB0cmFmZmljLCBhbmQgdGhhdCBhbiBleHRlbnNpb24gbWV0cmljIGZvciBMaW5r IFV0aWxpc2F0aW9uICh3aGljaCBjb3VsZCBwcm92aWRlIG1ldHJpY3MgcGx1cmFsKSBpcyB3cml0 dGVuIHVwPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Kb2huPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDI3IEFwciAyMDE2LCBhdCAwNzo0MywgVGVjbyBCb290ICZsdDs8YSBocmVmPSJtYWls dG86dGVjb0BpbmYtbmV0Lm5sIj50ZWNvQGluZi1uZXQubmw8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1h bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dv cmQtc3BhY2luZzowcHgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGJyPg0KT3AgMjcgYXByLiAyMDE2LCBvbSAwMToxNiBoZWVmdCBTdGFuIFJh dGxpZmYgJmx0OzxhIGhyZWY9Im1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20iPnJhdGxpZmZz dGFuQGdtYWlsLmNvbTwvYT4mZ3Q7IGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOjxicj4NCjxicj4N CkpvaG4sPGJyPg0KPGJyPg0KU3BlYWtpbmcgYXMgYSBjby1hdXRob3IgYW5kIGEgRExFUCBpbXBs ZW1lbnRlciw8YnI+DQo8YnI+DQpPbiBUdWUsIEFwciAyNiwgMjAxNiBhdCA2OjA2IFBNLCBKb2hu IERvd2RlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2huLmRvd2RlbGwuaWV0ZkBnbWFpbC5jb20i PmpvaG4uZG93ZGVsbC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCkhpIGFsbDxi cj4NCjxicj4NCkEgcXVlc3Rpb24gaGFzIGFyaXNlbiBhcyB0byB3aGV0aGVyIHRoZSBMYXRlbmN5 IG1ldHJpYyBzaG91bGQgaW5jbHVkZSBxdWV1ZWluZyBkZWxheSBpbiB0aGUgbW9kZW0uPGJyPg0K PGJyPg0KSXQgaGFzIGxvbmcgYmVlbiBoZWxkIHRoYXQgdGhlIGJhbmR3aWR0aCBtZXRyaWMgaXMg bWVhc3VyZWQgaW4gdGhlIGFic2VuY2Ugb2YgdHJhZmZpYyAodGhvdWdoIHRoZSBtZXRyaWMgZGVz Y3JpcHRpb25zIGluIDEwLjE0IGFuZCAxMC4xNSBvZiBDdXJyZW50IERhdGEgUmF0ZSBhcmUgYW1i aWd1b3VzIG9uIHRoaXMgcG9pbnQpLCB5ZXQgc2VjdGlvbiAxMC4xNiBvZiAtMjIgc3RhdGVzIC4u Ljxicj4NCjxicj4NClllcywgdGhhdCdzIHRoZSB3YXkgbXkgaW1wbGVtZW50YXRpb24gd2VudC4g SSBkb24ndCBzZWUgYSB1c2UgY2FzZSBmb3IgYSBiYW5kd2lkdGggbWV0cmljIHRoYXQgYXR0ZW1w dHMgdG8gdGFrZSB0cmFmZmljIGludG8gYWNjb3VudCwgYW5kIGl0IHNlZW1zIHRvIG1lIGxpa2Ug c3VjaCBhIG1ldHJpYyBjb3VsZCAod291bGQpIGZsdWN0dWF0ZSB3aWxkbHkuIEZyb20gbXkgZXhw ZXJpZW5jZSwgdGhlICZxdW90O2ludGVyZXN0aW5nIHN0YXRpc3RpYyZxdW90OyB3YXMgYWx3YXlz DQogJnF1b3Q7aG93IGZhc3QgaXMgdGhlIHBpcGU/JnF1b3Q7IFRyeWluZyB0byBmYWN0b3IgdHJh ZmZpYyBpbnRvIGFjY291bnQgY2FuIGhhdmUgcmVhbGx5IHdlaXJkIHNpZGUtZWZmZWN0cyAtIGZv ciBpbnN0YW5jZSwgSSByZW1lbWJlciBhIHJhZGlvIGltcGxlbWVudGF0aW9uIHRoYXQgcmVwb3J0 ZWQgYSAmcXVvdDtDdXJyZW50IERhdGEgUmF0ZSZxdW90OyBvZiAwIG9uIGFuIGlkbGUgbGluayAo YmVjYXVzZSwgYWZ0ZXIgYWxsLCBubyB0cmFmZmljIHdhcyBmbG93aW5nKS4uLiB0aGF0DQogZHJv dmUgdGhlIHJvdXRlciBudXRzLCBzaW5jZSBpdCBzYXcgYSAmcXVvdDticm9rZW4mcXVvdDsgKG9y IG5lYXJseSBicm9rZW4pIGxpbmsuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJnF1b3Q7IExhdGVu Y3k6IEEgNjQtYml0IHVuc2lnbmVkIGludGVnZXIsIHJlcHJlc2VudGluZyB0aGUgdHJhbnNtaXNz aW9uIGRlbGF5LCBpbiBtaWNyb3NlY29uZHMsIHRoYXQgYSBwYWNrZXQgZW5jb3VudGVycyBhcyBp dCBpcyB0cmFuc21pdHRlZCBvdmVyIHRoZSBsaW5rLuKAnTxicj4NCjxicj4NCuKApiB3aGljaCBz dWdnZXN0cyB0aGF0IHF1ZXVpbmcgZGVsYXkgc2hvdWxkIGJlIGluY2x1ZGVkLjxicj4NCjxicj4N Ck11Y2ggYXMgaW4gdGhlIGNhc2UgYWJvdmUsIEkgY2FuJ3Qgc2VlIGEgdXNlIGNhc2UgZm9yIGEg JnF1b3Q7TGF0ZW5jeSZxdW90OyBtZXRyaWMgKndpdGhvdXQqIHF1ZXVlaW5nIGRlbGF5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkkgZG9uJ3QgZ2V0IHRoaXMuIEFib3Zl LCB5b3Ugc3VnZ2VzdCB0cmFmZmljIGlzIG5vdCB0YWtlbiBpbnRvIGFjY291bnQuIEhlcmUsIHlv dSBzdWdnZXN0IHF1ZXVpbmcgZGVsYXkgKGNhdXNlZCBieSB0cmFmZmljPykgaXMgdGFrZW4gaW50 byBhY2NvdW50Ljxicj4NCjxicj4NCkkgc3VnZ2VzdCBwYWNrZXQgaGFuZGxpbmcgZGVsYXkgZm9y IGEgc2luZ2xlIHBhY2tldCBvbiBhbiBpZGxlIG1lZGl1bSBpcyB0YWtlbiBpbnRvIGFjY291bnQu IERlbGF5IGNhdXNlZCBieSBmaWxsZWQgdXAgcXVldWVzIGlzIG5vdC4gUXVldWUgZGVwdGggd291 bGQgYmUgYW5vdGhlciBtZXRyaWMuIFdoaWNoIHdvdWxkIGZsdWN0dWF0ZSB3aWxkbHleXjIuIEFu ZCBjb3VsZCBiZSBhIGNvbXBsZXggY29tcG9zaXRlIG1ldHJpYyB3aGVuICpGUSBpcyB1c2VkLg0K IFNlZSBSRkMgNzU2NyAvIEJDUCAxOTcgb24gd2hhdCBwYWNrZXQgZm9yd2FyZGluZyBkZXZpY2Vz IFNIT1VMRCBkby48YnI+DQo8YnI+DQpUZWNvPGJyPg0KPGJyPg0KPGJyIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6 IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0K PGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KVGhlcmUgYXJlIHBvc2l0aXZlIGFu ZCBuZWdhdGl2ZSBjb25ub3RhdGlvbnM7IGEgbW9kZW0gcXVldWUgdGhhdCBzdWRkZW5seSBiZWNv bWVzIGZ1bGwgbWlnaHQgbm90IGhhdmUgYW55IG1vcmUgZGF0YSBxdWV1ZWQgdG8gaXQsIG9yIGEg RExFUC1wb3dlcmVkIHJvdXRpbmcgYWxnb3JpdGhtIG1pZ2h0IGNob29zZSBhbm90aGVyIG1vZGVt IGluc3RlYWQsIGFsbG93aW5nIHRoZSBxdWV1ZSB0byBzdWJzaWRlLCBidXQgdGhhdCBtaWdodCBu b3QgYmUgd2hhdA0KIHRoZSBzeXN0ZW0gaW50ZWdyYXRvciB3YW50ZWQgdG8gaGFwcGVuLjxicj4N Cjxicj4NCkFuZCB0aGF0IHdvdWxkIGRlcGVuZCBvbiBhIGxvdCBvZiBjb2RlIHRoYXQgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhlIERMRVAgc3BlYyAtIHNwZWNpZmljYWxseSwgaXQgZGVwZW5kcyBv biBob3cgYW4gYWxnb3JpdGhtIGFjdHVhbGx5ICpkZWFscyogd2l0aCB0aGUgRExFUCBtZXRyaWNz IHN1cHBsaWVkLjxicj4NCjxicj4NCkhhdmluZyBzYWlkIGFsbCBvZiB0aGF0LCBJIGNhbiBzZWUg YSBwb3NzaWJpbGl0eSBmb3IgYSBjb3VwbGUgb2YgZm9sbG93LW9uIG1ldHJpY3MgZm9yIGEgRExF UCBleHRlbnNpb24gLSB0aGUgZmlyc3Qgd291bGQgYmUgYSAmcXVvdDtMaW5rIFV0aWxpemF0aW9u JnF1b3Q7IG1ldHJpYy4gVGhlIG90aGVyIHdvdWxkIGJlIGEgJnF1b3Q7UHJvcGFnYXRpb24gZGVs YXkmcXVvdDsgbWV0cmljLCBiYXNlZCBvbiB0aGUgcGh5c2ljYWwgcHJvcGVydGllcyBvZiB0aGUg dHJhbnNtaXNzaW9uIG1lZGl1bS48YnI+DQo8YnI+DQpKdXN0IGEgdGhvdWdodC48YnI+DQo8YnI+ DQpSZWdhcmRzLDxicj4NClN0YW48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPgpU aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50 ZW5kZWQ8YnI+CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlv dXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90IGNvcHkg aXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRpc3RyaWJ1 dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvcD48 L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2E92GLKXM0002VGREEN_-- From nobody Wed May 4 05:49:16 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B2B12D1D4 for ; Wed, 4 May 2016 05:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG8urUlhQR-4 for ; Wed, 4 May 2016 05:49:10 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED89D12B03D for ; Wed, 4 May 2016 05:49:09 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for manet@ietf.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1axwEm-002aQr-HQ>; Wed, 04 May 2016 14:49:08 +0200 Received: from x4dba3ec7.dyn.telefonica.de ([77.186.62.199] helo=[192.168.1.174]) by inpost2.zedat.fu-berlin.de (Exim 4.85) for manet@ietf.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1axwEm-001lEg-8i>; Wed, 04 May 2016 14:49:08 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Lotte Steenbrink In-Reply-To: <20160504100008.8315.79330.idtracker@ietfa.amsl.com> Date: Wed, 4 May 2016 14:49:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5716C1CA-76CC-46B8-96DC-4DADC5C7AD14@fu-berlin.de> References: <20160504100008.8315.79330.idtracker@ietfa.amsl.com> To: manet X-Mailer: Apple Mail (2.3112) X-Originating-IP: 77.186.62.199 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-16.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 12:49:15 -0000 Hello everyone, based on the responses gathered during WGLC, we=E2=80=99ve published a = new revision. Again, thank you for the constructive, detailed and = helpful reviews and feedback. We know AODVv2 is a long document, so = we=E2=80=99re grateful you made it through despite the very short notice = and time frame. Here=E2=80=99s a summary of what we=E2=80=99ve changed: =E2=80=A2 Message types are now allocated from the Experimental range of = the "Message Types=E2=80=9C namespace of RFC5444 and there is no golbal = registry for MetricType allocations anymore. =E2=80=A2 All messages except RERR are forwarded instead of = regenerated*. The change from regeneration to forwarding was made = possible by a bunch of other changes: + ValidityTime has been removed. + The AckReq flag is not part of a RREP anymore. = Bidirectionality is checked with the use of RREP_Ack messages. + Instructions on how to zero out the metric value when = calculating the ICV have been added. In consequence, the following changes were made as well: + RREP are unicast again. + Since RREP are unicast, they aren=E2=80=99t stored in the = Multicast Route Message Set anymore. We relied on the MRMS to determine = when a RREP_Ack wasn=E2=80=99t received within the expected time, so now = the fact that we=E2=80=99re waiting for a RREP_Ack is recorded in the = Neighbor Set. (So now checking if the RREP_Ack was expected means "go = look in the neighbor set and see if the state is Unknown and the Timeout = hasn't been reached yet." and the timer is handled as part of the = Neighbor Set too.) =E2=80=A2 is in use again. =E2=80=A2 The language used in the draft has been updated that while = routes to prefixes can=E2=80=99t be directly requested, they *can* be = discovered =E2=80=9Eon the fly=E2=80=9C. =E2=80=A2 The instructions on how to calculate and evaluate ICVs are = more detailed and bullet point-y now. =E2=80=A2 As suggested by Jiazi, the experiment description got its own = section and has been extended. =E2=80=A2 The applicability statement details which network = characteristics might be problematic for AODVv2. =E2=80=A2 Key Management considerations have ben added. =E2=80=A2 Some language has (hopefully) been clarified based on the = reviews by Ulrich and Jiazi. =E2=80=A2 As requested by him, Thomas Clausen has ben removed from the = Acknowledgements . With kind regards, Lotte Steenbrink *RERRs are a special case since they are one hop messages: routers only = pass on information about broken links if they concern their own routes. = The exception is that if an RERR is triggered by an undeliverable = packet, it's both a one-hop message from each router that deletes the = route to all its neighbors, and also a message that needs forwarding = multi-hop to PktSource. > Am 04.05.2016 um 12:00 schrieb internet-drafts@ietf.org: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Mobile Ad-hoc Networks of the IETF. >=20 > Title : Ad Hoc On-demand Distance Vector Version 2 = (AODVv2) Routing > Authors : Charles E. Perkins > Stan Ratliff > John Dowdell > Lotte Steenbrink > Victoria Mercieca > Filename : draft-ietf-manet-aodvv2-16.txt > Pages : 84 > Date : 2016-05-04 >=20 > Abstract: > The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing > protocol is intended for use by mobile routers in wireless, multihop > networks. AODVv2 determines unicast routes among AODVv2 routers > within the network in an on-demand fashion. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-manet-aodvv2-16 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-16 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed May 4 06:09:10 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEFD12D66E for ; Wed, 4 May 2016 06:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdSyW_X7CSYi for ; Wed, 4 May 2016 06:09:04 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD8612D1CC for ; Wed, 4 May 2016 06:09:04 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id n129so188116053wmn.1 for ; Wed, 04 May 2016 06:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ysO+ebVVG/lV5ONrgzB2t3+ZdL28Ejk4PEa9bV5krU4=; b=jX1n0H45pTzFYcwV/lfH0+hfkYc9L9BCH24TH4UeMaZg9RfcBPJHGH3j0+OMiv/fZV go5obx0QTjwxXVl6wCuDcxzR4MJVOpzo+Jw9Y+334NM8znKKPQ84Nc1Nc0gjJ7R+mKcm Y47hGuSO3nvAtgOLTodk9YLtCV3qHBio0nmlmVmVRa7bE2ba4a09yuXdQjz4Y9V0A3uI rFXwshHpfEeiJ0tkYVga+ulpU0pT/zoJk4THfdxTzxsvWqECXT79DE8VkjPOv7gNFA2B MPjOAO3w7cdF3zhZ24oXftQIM5g7D/3rzTGI7tGgQ4GxE1whfeBdvLhLli8Uc0QF6/hy yAJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ysO+ebVVG/lV5ONrgzB2t3+ZdL28Ejk4PEa9bV5krU4=; b=FS26xcP7hGHQTSeIbyV2a6wCF8IFp8aw0h0MCTa+yg8AdkiOqkn3yk4IV0PzqbYCFA orZzazLvSx3OC3bQOUNPhBFurvfktOTBWTucWC5ttVoqkvsSRlWygvn6Ay/lgvkyRc8B Y387YfxhV31Q4OVWt0JjvunkvBwD/eK2Y4jFzKyBuB8WpaAVooO2dSqDQhSCl/hYUJOq EjTUmSpkoyhL0kz4LUvMK2w90iLJlJNubHBQTjnbZ65HUcmDlW9SerthP8RELQlep3bm D+JMHkMeHrxZd1CQJQH3iv2YvLR27RLzpiP8WZRJ92Jvhgyfb7kebZQynfML3gVCjEnV G2Lw== X-Gm-Message-State: AOPr4FUxS+KrF8sgNW0bNOy9kbTSkUOpmbAxl1t87PQobkZFcnxUqnqMxkdBa2HnxFXqeA== X-Received: by 10.28.195.7 with SMTP id t7mr29639701wmf.96.1462367342562; Wed, 04 May 2016 06:09:02 -0700 (PDT) Received: from johns-mbp-4.home (host86-155-246-227.range86-155.btcentralplus.com. [86.155.246.227]) by smtp.gmail.com with ESMTPSA id ug8sm4139020wjc.42.2016.05.04.06.09.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 May 2016 06:09:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4036BBD4-57D4-42A5-9D6A-7F3F8F491001" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Dowdell In-Reply-To: Date: Wed, 4 May 2016 14:08:59 +0100 Message-Id: References: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com> <2DC54CCE-46BE-48D0-9497-52D31DCB5B40@inf-net.nl> <8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP and latency metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 13:09:08 -0000 --Apple-Mail=_4036BBD4-57D4-42A5-9D6A-7F3F8F491001 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 May 2016, at 13:38, Dearlove, Christopher (UK) = wrote: >=20 > Was the suggestion to include an empty queuing delay, i.e. it included = everything, but in the case where the queue was empty? Yes that is my proposal, or actually my seconding of Stan=E2=80=99s = proposal, assuming I understood Stan correctly. Regards John > That sounds like a sensible approach, assuming it=E2=80=99s reasonably = stable. > =20 > -- >=20 > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > = __________________________________________________________________________= >=20 > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com = >=20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >=20 > =20 > From: manet [mailto:manet-bounces@ietf.org = ] On Behalf Of John Dowdell > Sent: 04 May 2016 12:43 > To: MANET IETF > Subject: Re: [manet] DLEP and latency metric > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > For information regarding Red Flags that you can look out for in = emails you receive, click here = . > If you feel the email is suspicious, please follow this process = . >=20 > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our = organization. > =20 > I know we=E2=80=99re all a bit tied up with various last calls but can = I ask for adjudication on this point? The current draft is ambiguous as = to whether the latency metric includes the current queuing delay, taking = account of how full or not the queue is at the sampling instant, or a = notional =E2=80=9Cno traffic" delay (in the same manner as for the = bandwidth metric), and there are polarised views for and against. > =20 > Just that I=E2=80=99m keen to get this one clarified one way or the = other. > =20 > Following Stan=E2=80=99s proposal below, can I propose that the = Latency Metric is measured in absence of traffic, and that an extension = metric for Link Utilisation (which could provide metrics plural) is = written up? > =20 > Regards > John > =20 > On 27 Apr 2016, at 07:43, Teco Boot > wrote: > =20 >=20 > Op 27 apr. 2016, om 01:16 heeft Stan Ratliff > het volgende geschreven: >=20 > John, >=20 > Speaking as a co-author and a DLEP implementer, >=20 > On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell = > = wrote: > Hi all >=20 > A question has arisen as to whether the Latency metric should include = queueing delay in the modem. >=20 > It has long been held that the bandwidth metric is measured in the = absence of traffic (though the metric descriptions in 10.14 and 10.15 of = Current Data Rate are ambiguous on this point), yet section 10.16 of -22 = states ... >=20 > Yes, that's the way my implementation went. I don't see a use case for = a bandwidth metric that attempts to take traffic into account, and it = seems to me like such a metric could (would) fluctuate wildly. =46rom my = experience, the "interesting statistic" was always "how fast is the = pipe?" Trying to factor traffic into account can have really weird = side-effects - for instance, I remember a radio implementation that = reported a "Current Data Rate" of 0 on an idle link (because, after all, = no traffic was flowing)... that drove the router nuts, since it saw a = "broken" (or nearly broken) link. >=20 >=20 >=20 > " Latency: A 64-bit unsigned integer, representing the transmission = delay, in microseconds, that a packet encounters as it is transmitted = over the link.=E2=80=9D >=20 > =E2=80=A6 which suggests that queuing delay should be included. >=20 > Much as in the case above, I can't see a use case for a "Latency" = metric *without* queueing delay. >=20 > I don't get this. Above, you suggest traffic is not taken into = account. Here, you suggest queuing delay (caused by traffic?) is taken = into account. >=20 > I suggest packet handling delay for a single packet on an idle medium = is taken into account. Delay caused by filled up queues is not. Queue = depth would be another metric. Which would fluctuate wildly^^2. And = could be a complex composite metric when *FQ is used. See RFC 7567 / BCP = 197 on what packet forwarding devices SHOULD do. >=20 > Teco >=20 >=20 >=20 >=20 >=20 > There are positive and negative connotations; a modem queue that = suddenly becomes full might not have any more data queued to it, or a = DLEP-powered routing algorithm might choose another modem instead, = allowing the queue to subside, but that might not be what the system = integrator wanted to happen. >=20 > And that would depend on a lot of code that outside the scope of the = DLEP spec - specifically, it depends on how an algorithm actually = *deals* with the DLEP metrics supplied. >=20 > Having said all of that, I can see a possibility for a couple of = follow-on metrics for a DLEP extension - the first would be a "Link = Utilization" metric. The other would be a "Propagation delay" metric, = based on the physical properties of the transmission medium. >=20 > Just a thought. >=20 > Regards, > Stan >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 --Apple-Mail=_4036BBD4-57D4-42A5-9D6A-7F3F8F491001 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 May 2016, at 13:38, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Was the suggestion to include an empty = queuing delay, i.e. it included everything, but in the case where the = queue was empty?

Yes that is my proposal, or actually my seconding = of Stan=E2=80=99s proposal, assuming I understood Stan = correctly.

Regards
John

That sounds like a sensible approach, = assuming it=E2=80=99s reasonably stable.
 

--

Christopher Dearlove
Senior Principal = Engineer
BAE Systems Applied Intelligence Laboratories
_______________________________________________________________= ___________

T:  +44 = (0)1245 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, = Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research = Park, Guildford, Surrey, GU2 7YP

 
From: manet [mailto:manet-bounces@ietf.org] On Behalf = Of John Dowdell
Sent: 04 May 2016 12:43
To: MANET IETF
Subject: Re: [manet] DLEP and = latency metric
 
 
*** WARNING ***

This message originates from outside our = organisation, either from an external partner or the = internet.
Consider carefully whether you should click on = any links, open any attachments or reply.
For = information regarding Red = Flags that you = can look out for in emails you receive, click here.
If you feel the = email is suspicious, please follow this = process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our = organization.
 
I know we=E2=80=99re all a bit tied up with various = last calls but can I ask for adjudication on this point? The current = draft is ambiguous as to whether the latency metric includes the current = queuing delay, taking account of how full or not the queue is at the = sampling instant, or a notional =E2=80=9Cno traffic" delay (in the same = manner as for the bandwidth metric), and there are polarised views for = and against.
 
Just that I=E2=80=99m keen to get this one clarified = one way or the other.
 
Following Stan=E2=80=99s proposal below, can I = propose that the Latency Metric is measured in absence of traffic, and = that an extension metric for Link Utilisation (which could provide = metrics plural) is written up?
 
Regards
John
 
On 27 Apr 2016, at = 07:43, Teco Boot <teco@inf-net.nl> = wrote:
 

Op 27 = apr. 2016, om 01:16 heeft Stan Ratliff <ratliffstan@gmail.com> = het volgende geschreven:

John,

Speaking as a co-author and a DLEP = implementer,

On Tue, Apr 26, 2016 at 6:06 = PM, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
Hi = all

A question has arisen as to whether the = Latency metric should include queueing delay in the modem.

It has long been held that the bandwidth = metric is measured in the absence of traffic (though the metric = descriptions in 10.14 and 10.15 of Current Data Rate are ambiguous on = this point), yet section 10.16 of -22 states ...

Yes, that's the way my implementation went. I don't see a use = case for a bandwidth metric that attempts to take traffic into account, = and it seems to me like such a metric could (would) fluctuate wildly. = =46rom my experience, the "interesting statistic" was always "how fast = is the pipe?" Trying to factor traffic into account can have really = weird side-effects - for instance, I remember a radio implementation = that reported a "Current Data Rate" of 0 on an idle link (because, after = all, no traffic was flowing)... that drove the router nuts, since it saw = a "broken" (or nearly broken) link.



" Latency: A 64-bit unsigned integer, = representing the transmission delay, in microseconds, that a packet = encounters as it is transmitted over the link.=E2=80=9D

=E2=80=A6 which suggests that queuing delay should be = included.

Much as in the case above, I = can't see a use case for a "Latency" metric *without* queueing = delay.

I don't = get this. Above, you suggest traffic is not taken into account. Here, = you suggest queuing delay (caused by traffic?) is taken into account.

I suggest packet handling delay for a single = packet on an idle medium is taken into account. Delay caused by filled = up queues is not. Queue depth would be another metric. Which would = fluctuate wildly^^2. And could be a complex composite metric when *FQ is = used. See RFC 7567 / BCP 197 on what packet forwarding devices SHOULD = do.

Teco





There are positive and negative connotations; a modem queue = that suddenly becomes full might not have any more data queued to it, or = a DLEP-powered routing algorithm might choose another modem instead, = allowing the queue to subside, but that might not be what the system = integrator wanted to happen.

And that would = depend on a lot of code that outside the scope of the DLEP spec - = specifically, it depends on how an algorithm actually *deals* with the = DLEP metrics supplied.

Having said all of = that, I can see a possibility for a couple of follow-on metrics for a = DLEP extension - the first would be a "Link Utilization" metric. The = other would be a "Propagation delay" metric, based on the physical = properties of the transmission medium.

Just = a thought.

Regards,
Stan


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
 

***************************************************************= *****
This email and any attachments are confidential to = the intended
recipient and may also be privileged. If you = are not the intended
recipient please delete it from your = system and notify the sender.
You should not copy it or = use it for any purpose nor disclose or
distribute its = contents to any other person.
***************************************************************= *****


= --Apple-Mail=_4036BBD4-57D4-42A5-9D6A-7F3F8F491001-- From nobody Wed May 4 07:44:25 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B715112D515 for ; Wed, 4 May 2016 07:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iK4OLHUA5Rz for ; Wed, 4 May 2016 07:44:22 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4184F12B032 for ; Wed, 4 May 2016 07:43:50 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id j8so62494055lfd.2 for ; Wed, 04 May 2016 07:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tcmOn1p3pVRxgMXccrj5lCbwB6nytth3KI2JKx8GhHU=; b=Yju0VWNMFHX5aAfGfGGN+d2HjVKQIWrgkP9cm84p09ebjKc8atO8UHJbGxBXsAKGge 9jDaU2Z60jT8Pm4UpK4iYVe9Ayutz4rwzxgG6iiLhhVybck6SQwULZvQ213BT2tWK2vK X5dyBUqR16kDhUxaWz7NT/ff4c66+slGZDmfJP92mdKQBpJzHBRYgRVbgAfGCp5vxpx5 pmtQbke614gIq3/1CPkUIssom5tLzyq37XneiCr2xgTN9g5SgpKGsuUbMWkBiKOm02P3 12tbUWkedFLnsyLTdbuRZDqVOsppxfX1frfgrsLNlF/QkkPJzAxE24lPPnkWNd4spclR sp5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tcmOn1p3pVRxgMXccrj5lCbwB6nytth3KI2JKx8GhHU=; b=TDGVCYZ5Rs6dZ3iPmaoDQZSf9YLciCxGNtA+XG3FXWXgf2Fcum9KcjHri6cS6KjnZM zl0geuSnwtagrTjui2FDYaHVbAAsw0M280LnQ685jdstfMioCtbFXkGY65VFM5qsL0yd r+l3K/EjIAbQQRL5Pe/FgsVlRzCpOmYS+YFQjrhi3DzdkeHpElB3Ysc3gBxv/rUTQjOx p2jQAo46LhMRbuwa7DmipfQY0d3W0UWAQtEBBqjiQT34HHisXVn4UbAzQclhbV8XWwb0 q63UTPA55JKOWqL76CH4YhyBidjCkPcZVUMarjyjXY2FOo2q3XFL9zqbBgWFgnluTgv2 XoDw== X-Gm-Message-State: AOPr4FX7emHK+acBKfb2DOzP5KL75X/fF+tUjUTIWwNjrWSDTsSqerMfkIcNzd30cIGB56/A0DyXanyFJhe4Tw== MIME-Version: 1.0 X-Received: by 10.112.169.42 with SMTP id ab10mr3797102lbc.63.1462373028474; Wed, 04 May 2016 07:43:48 -0700 (PDT) Received: by 10.112.204.200 with HTTP; Wed, 4 May 2016 07:43:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 May 2016 10:43:48 -0400 Message-ID: From: James Nguyen To: Justin Dean Content-Type: multipart/alternative; boundary=001a11c38a9ce4376a05320540b2 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Recharter Discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:44:24 -0000 --001a11c38a9ce4376a05320540b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2016 at 11:07 AM, Justin Dean wrote: > I'll start things off by floating the draft re-charter which was presente= d > in Prague. > > The purpose of the MANET working group is to standardize IP routing proto= col functionality suitable for wireless routing application within both sta= tic and dynamic topologies with increased dynamics due to node motion or ot= her factors. > > Approaches are intended to be relatively lightweight in nature, suitable = for multiple hardware and wireless environments, and address scenarios wher= e MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh inf= rastructures (e.g., a mixture of fixed and mobile routers) should also be s= upported by MANET specifications and management features. > > The MANET WG is responsible for the maintenance of OLSRv2, AODVv2, DLEP a= nd NHPD. Of particular interest: border behavior between MANET networks and= fixed IP network infrastructures, enhance AODVv2 gateway functionality; se= curity enhancements, encryption security extensions for RFC5444. > > > + 1 I'm interested in "border behavior between MANET networks and fixed IP network infrastructures." Is there any existing work on this? The MANET WG will standardize a multicast MANET protocol framework based on previous work and lessons learned for scoped forwarding within MANET networks. As part of this framework the WG will produce a well defined MANET multicast forwarding information base. > > > +1 > The WG will produce an informational draft outlining challenges and best = practices for deploying and managing MANET networks. > > The MANET WG will interact with the PIM working group on issues relating = to the multicast work. The WG will also pay attention to other IETF and IR= TF work that is addressing topics related to MANET environments. > > In summary, the WG will develop the following drafts: > > MANET Management Document (Informational) > > > I'm still unclear what would be the in the document. As of now, there isn't a clear management solution for MANET (eg.g, cloud computing, SDN). As for management protocols, RESTCONF will soon be standardized, but transport needs to be addressed for MANET. CoMI seems to be a good fit for MANET, but it'll be far from being matured. Anyhow, if we work and publish this document, it'll be out of date in a year or two. I can volunteer to work on this, but I need some guidance. On a separate note, for all future protocols, will we continue to develop MIB or YANG? > MANET Maintenance > - RFC5444 Security extension (Standards) > - Enhanced AODVv2 gateway extension (Standards) > MANET Multicast > - Multicast FIB (Standards) > > > This will likely be considered too broad to pass. We will likely need to= cut some and focus the work. For me personally I know I have the time and= backing to work on the Multicast piece. > > Justin > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --=20 James Nguyen Email: james.huy.nguyen@gmail.com --001a11c38a9ce4376a05320540b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 22, 2016 at 11:07 AM, Justin Dean <bebemaster@gmail.com= > wrote:
I'll start things off by floating the draft re-charte= r which was presented in Prague. =C2=A0

The purpose of the MANET work=
ing group is to standardize IP routing protocol functionality suitable for =
wireless routing application within both static and dynamic topologies with=
 increased dynamics due to node motion or other factors. =20

Approaches are intended to be relatively lightweight in nature, suitable fo=
r multiple hardware and wireless environments, and address scenarios where =
MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infra=
structures (e.g., a mixture of fixed and mobile routers) should also be sup=
ported by MANET specifications and management features.

The MANET WG is responsible for the maintenance of OLSRv2, AODVv2, DLEP and=
 NHPD. Of particular interest: border behavior between MANET networks and f=
ixed IP network infrastructures, enhance AODVv2 gateway functionality; secu=
rity enhancements, encryption security extensions for RFC5444.=20
> + 1
I'm interested in "border beh=
avior between MANET networks and fixed IP network infrastructures."=C2=
=A0 Is there any existing work on this?=C2=A0 
The MANET WG will stan=
dardize a multicast MANET protocol framework based on previous work and les=
sons learned for scoped forwarding within MANET networks.  As part of this =
framework the WG will produce a well defined MANET multicast forwarding inf=
ormation base.
> +1=C2=A0 
The WG will produce an informa=
tional draft outlining challenges and best practices for deploying and mana=
ging MANET networks.

The MANET WG will interact with the PIM working group on issues relating to=
 the multicast work.  The WG will also pay attention to other IETF and IRTF=
 work that is addressing topics related to MANET environments.

In summary, the WG will develop the following drafts:

MANET Management Document (Informational)
>= =C2=A0 I'm still unclear what would be the in the document.=C2=A0 As of= now, there isn't a clear management solution for MANET (eg.g, cloud co= mputing, SDN).=C2=A0 As for management protocols, RESTCONF will soon be sta= ndardized, but transport needs to be addressed for MANET.=C2=A0 CoMI seems = to be a good fit for MANET, but it'll be far from being matured.=C2=A0 = Anyhow, if we work and publish this document, it'll be out of date in a= year or two.=C2=A0 I can volunteer to work on this, but I need some guidan= ce.=C2=A0

On a separate note, for all future protocols, = will we continue to develop MIB or YANG?=C2=A0 
MANET Maintenance=20
 - RFC5444 Security extension (Standards)
 - Enhanced AODVv2 gateway extension (Standards)
MANET Multicast
 - Multicast FIB (Standards)


This will likely be considered too broad to pass.  We will likely need to c=
ut some and focus the work.  For me personally I know I have the time and b=
acking to work on the Multicast piece. =20

Justin

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




--
James Nguyen
Email: james.huy.nguyen@gmail.com
--001a11c38a9ce4376a05320540b2-- From nobody Wed May 4 08:10:13 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1126212D6ED for ; Wed, 4 May 2016 08:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xZje5NPx_3V for ; Wed, 4 May 2016 08:10:04 -0700 (PDT) Received: from ukel19pa18.eemsg.mail.mil (ukel19pa18.eemsg.mail.mil [214.24.22.86]) by ietfa.amsl.com (Postfix) with ESMTP id BED3612D6F0 for ; Wed, 4 May 2016 08:09:21 -0700 (PDT) Received: from edge-cols03.mail.mil ([131.64.107.102]) by ukel19pa18.eemsg.mail.mil with ESMTP; 04 May 2016 15:09:20 +0000 Received: from UCOLHPQN.easf.csd.disa.mil (131.64.107.40) by edge-cols03.mail.mil (131.64.107.102) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 4 May 2016 15:09:19 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([169.254.6.80]) by UCOLHPQN.easf.csd.disa.mil ([131.64.107.40]) with mapi id 14.03.0266.001; Wed, 4 May 2016 15:09:19 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: James Nguyen , Justin Dean Thread-Topic: [Non-DoD Source] Re: [manet] Recharter Discussion Thread-Index: AQHRphOCwt7hMGfEhEmHjILibD91/Z+o28jg Date: Wed, 4 May 2016 15:09:18 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDFA2829F65@UCOLHU2J.easf.csd.disa.mil> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] [Non-DoD Source] Re: Recharter Discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:10:12 -0000 Rm9sa3M6DQoNCkkgYW0gYWxzbyBpbnRlcmVzdGVkIGluIHRoZSBicm9hZGVyIGZyYW1ld29yayBv ZiBNQU5FVHMuIFRoZSBmcmFtZXdvcmsgc2hvdWxkIGluY2x1ZGUgYXMgZm9sbG93czoNCg0KMS4g VGhlIGZ1bmRhbWVudGFsIG5ldHdvcmsgdG9wb2xvZ3kgYXJjaGl0ZWN0dXJlIG9mIE1BTkVUcyBp cyBwZWVyLXRvLXBlZXIgKFAyUCkgYnkgZGVmaW5pdGlvbiBhcyBhbGwgbm9kZXMgbW92ZSBmcm9t IG9uZSBwbGFjZSB0byBhbm90aGVyIHdpdGggbW9iaWxpdHkgcGF0dGVybnMgdGhhdCBhcmUgdGVy bWVkIGFzICJhZCBob2MiIG1vdmVtZW50cyB3aGVyZSBlYWNoIG5vZGUgaW5kZXBlbmRlbnRseSB3 aXRoIG5vIGZpeGVkIGluZnJhc3RydWN0dXJlcywgYW5kIHRoZXkgdXNlIHRoZSBJUCBNQU5FVCBw aHlzaWNhbCByb3V0aW5nIHByb3RvY29scyB0KGUuZy4gQU9EVnYyKSBoYXQgaW5jbHVkZSBicm9h ZGNhc3QgYW5kIG11bHRpY2FzdC4NCg0KMi4gVGhlIGxhcmdlLXNjYWxlIE1BTkVUcyB0b3BvbG9n eSBhcmNoaXRlY3R1cmUgd2lsbCBiZSBoaWVyYXJjaGljYWwgYWwgbGVhc3Qgb2YgdHdvIHRpZXJz OiBBY2Nlc3MgTUFORVRzIGFuZCBhIEJhY2tib25lIE1BTkVUIHRoYXQgY29ubmVjdHMgYWxsIGFj Y2VzcyBNQU5FVHMuIEVhY2ggYWNjZXNzIE1BTkVUIG1heSB1c2UgSVAgTUFORVQgcGh5c2ljYWwg cm91dGluZyBwcm90b2NvbCAoZS5nLiBBT0RWdjIpLiBIb3dldmVyLCB0aGUgQmFja2JvbmUgTUFO RVQgbWF5IHVzZSAibG9naWNhbCIgcm91dGluZyBwcm90b2NvbCAoc3VjaCBhcywgS2V5LWJhc2Vk IERpc3RyaWJ1dGVkIEhhc2ggVGFibGUgW0RIVF0pIHRoYXQgbWF5IHVzZSB1bmljYXN0IGFtb25n IHRoZSBiYWNrYm9uZSBub2RlIHBlZXJzIChtYXkgY2x1c3RlciBoZWFkKS4gSXQgaW1wbGllcyB0 aGF0IHdlIG5lZWQgdG8gZGV2ZWxvcCAob3IgY2hvb3NlIG9yIG1vZGlmaWVkIGZyb20gdGhlIGV4 aXN0aW5nIERIVCkgdGhlIEtleS1iYXNlZCBESFQgImxvZ2ljYWwiIHJvdXRpbmcgcHJvdG9jb2wg d2l0aCB1bmljYXN0IHRoYXQgaXMgc3VpdGFibGUgZm9yIHRoZSBCYWNrYm9uZSBNQU5FVC4NCg0K My4gSXQgaW1wbGllcyB0aGF0IHRoZXJlIHdpbGwgdHdvIGtpbmRzIG9mIHJvdXRpbmcgcHJvdG9j b2w6IEFjY2VzcyBNQU5FVCBQaHlzaWNhbCBSb3V0aW5nIFByb3RvY29sIChlLmcuIEFPRFZ2Mikg YW5kIEJhY2tib25lIE1BTkVUIExvZ2ljYWwgVW5pY2FzdCBSb3V0aW5nIFByb3RvY29sIChlLmcu IERIVC1iYXNlZCByb3V0aW5nIHNjaGVtZXMpLg0KDQpDb21tZW50cyB3aWxsIGJlIGFwcHJlY2lh dGVkIG9uIHRoZSBhYm92ZSB0b3BpYy4NCg0KQmVzdCByZWdhcmRzLA0KUmFkaGlrYSANCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbWVzIE5ndXllbg0KU2VudDogV2VkbmVzZGF5LCBN YXkgMDQsIDIwMTYgMTA6NDQgQU0NClRvOiBKdXN0aW4gRGVhbiA8YmViZW1hc3RlckBnbWFpbC5j b20+DQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFtOb24tRG9EIFNvdXJjZV0gUmU6IFtt YW5ldF0gUmVjaGFydGVyIERpc2N1c3Npb24NCg0KQWxsIGFjdGl2ZSBsaW5rcyBjb250YWluZWQg aW4gdGhpcyBlbWFpbCB3ZXJlIGRpc2FibGVkLiBQbGVhc2UgdmVyaWZ5IHRoZSBpZGVudGl0eSBv ZiB0aGUgc2VuZGVyLCBhbmQgY29uZmlybSB0aGUgYXV0aGVudGljaXR5IG9mIGFsbCBsaW5rcyBj b250YWluZWQgd2l0aGluIHRoZSBtZXNzYWdlIHByaW9yIHRvIGNvcHlpbmcgYW5kIHBhc3Rpbmcg dGhlIGFkZHJlc3MgdG8gYSBXZWIgYnJvd3Nlci4gDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KDQoNCg0KDQpPbiBGcmksIEFwciAyMiwgMjAxNiBhdCAxMTowNyBBTSwg SnVzdGluIERlYW4gPGJlYmVtYXN0ZXJAZ21haWwuY29tIDwgQ2F1dGlvbi1tYWlsdG86YmViZW1h c3RlckBnbWFpbC5jb20gPiA+IHdyb3RlOg0KDQoNCglJJ2xsIHN0YXJ0IHRoaW5ncyBvZmYgYnkg ZmxvYXRpbmcgdGhlIGRyYWZ0IHJlLWNoYXJ0ZXIgd2hpY2ggd2FzIHByZXNlbnRlZCBpbiBQcmFn dWUuICANCgkNCgkNCglUaGUgcHVycG9zZSBvZiB0aGUgTUFORVQgd29ya2luZyBncm91cCBpcyB0 byBzdGFuZGFyZGl6ZSBJUCByb3V0aW5nIHByb3RvY29sIGZ1bmN0aW9uYWxpdHkgc3VpdGFibGUg Zm9yIHdpcmVsZXNzIHJvdXRpbmcgYXBwbGljYXRpb24gd2l0aGluIGJvdGggc3RhdGljIGFuZCBk eW5hbWljIHRvcG9sb2dpZXMgd2l0aCBpbmNyZWFzZWQgZHluYW1pY3MgZHVlIHRvIG5vZGUgbW90 aW9uIG9yIG90aGVyIGZhY3RvcnMuICBBcHByb2FjaGVzIGFyZSBpbnRlbmRlZCB0byBiZSByZWxh dGl2ZWx5IGxpZ2h0d2VpZ2h0IGluIG5hdHVyZSwgc3VpdGFibGUgZm9yIG11bHRpcGxlIGhhcmR3 YXJlIGFuZCB3aXJlbGVzcyBlbnZpcm9ubWVudHMsIGFuZCBhZGRyZXNzIHNjZW5hcmlvcyB3aGVy ZSBNQU5FVHMgYXJlIGRlcGxveWVkIGF0IHRoZSBlZGdlcyBvZiBhbiBJUCBpbmZyYXN0cnVjdHVy ZS4gSHlicmlkIG1lc2ggaW5mcmFzdHJ1Y3R1cmVzIChlLmcuLCBhIG1peHR1cmUgb2YgZml4ZWQg YW5kIG1vYmlsZSByb3V0ZXJzKSBzaG91bGQgYWxzbyBiZSBzdXBwb3J0ZWQgYnkgTUFORVQgc3Bl Y2lmaWNhdGlvbnMgYW5kIG1hbmFnZW1lbnQgZmVhdHVyZXMuVGhlIE1BTkVUIFdHIGlzIHJlc3Bv bnNpYmxlIGZvciB0aGUgbWFpbnRlbmFuY2Ugb2YgT0xTUnYyLCBBT0RWdjIsIERMRVAgYW5kIE5I UEQuIE9mIHBhcnRpY3VsYXIgaW50ZXJlc3Q6IGJvcmRlciBiZWhhdmlvciBiZXR3ZWVuIE1BTkVU IG5ldHdvcmtzIGFuZCBmaXhlZCBJUCBuZXR3b3JrIGluZnJhc3RydWN0dXJlcywgZW5oYW5jZSBB T0RWdjIgZ2F0ZXdheSBmdW5jdGlvbmFsaXR5OyBzZWN1cml0eSBlbmhhbmNlbWVudHMsIGVuY3J5 cHRpb24gc2VjdXJpdHkgZXh0ZW5zaW9ucyBmb3IgUkZDNTQ0NC4gDQoNCj4gKyAxDQpJJ20gaW50 ZXJlc3RlZCBpbiAiYm9yZGVyIGJlaGF2aW9yIGJldHdlZW4gTUFORVQgbmV0d29ya3MgYW5kIGZp eGVkIElQIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmVzLiIgIElzIHRoZXJlIGFueSBleGlzdGluZyB3 b3JrIG9uIHRoaXM/ICANCg0KCVRoZSBNQU5FVCBXRyB3aWxsIHN0YW5kYXJkaXplIGEgbXVsdGlj YXN0IE1BTkVUIHByb3RvY29sIGZyYW1ld29yayBiYXNlZCBvbiBwcmV2aW91cyB3b3JrIGFuZCBs ZXNzb25zIGxlYXJuZWQgZm9yIHNjb3BlZCBmb3J3YXJkaW5nIHdpdGhpbiBNQU5FVCBuZXR3b3Jr cy4gIEFzIHBhcnQgb2YgdGhpcyBmcmFtZXdvcmsgdGhlIFdHIHdpbGwgcHJvZHVjZSBhIHdlbGwg ZGVmaW5lZCBNQU5FVCBtdWx0aWNhc3QgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBiYXNlLg0KDQo+ ICsxICANCg0KDQoJVGhlIFdHIHdpbGwgcHJvZHVjZSBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0IG91 dGxpbmluZyBjaGFsbGVuZ2VzIGFuZCBiZXN0IHByYWN0aWNlcyBmb3IgZGVwbG95aW5nIGFuZCBt YW5hZ2luZyBNQU5FVCBuZXR3b3Jrcy5UaGUgTUFORVQgV0cgd2lsbCBpbnRlcmFjdCB3aXRoIHRo ZSBQSU0gd29ya2luZyBncm91cCBvbiBpc3N1ZXMgcmVsYXRpbmcgdG8gdGhlIG11bHRpY2FzdCB3 b3JrLiAgVGhlIFdHIHdpbGwgYWxzbyBwYXkgYXR0ZW50aW9uIHRvIG90aGVyIElFVEYgYW5kIElS VEYgd29yayB0aGF0IGlzIGFkZHJlc3NpbmcgdG9waWNzIHJlbGF0ZWQgdG8gTUFORVQgZW52aXJv bm1lbnRzLkluIHN1bW1hcnksIHRoZSBXRyB3aWxsIGRldmVsb3AgdGhlIGZvbGxvd2luZyBkcmFm dHM6TUFORVQgTWFuYWdlbWVudCBEb2N1bWVudCAoSW5mb3JtYXRpb25hbCkNCg0KPiAgSSdtIHN0 aWxsIHVuY2xlYXIgd2hhdCB3b3VsZCBiZSB0aGUgaW4gdGhlIGRvY3VtZW50LiAgQXMgb2Ygbm93 LCB0aGVyZSBpc24ndCBhIGNsZWFyIG1hbmFnZW1lbnQgc29sdXRpb24gZm9yIE1BTkVUIChlZy5n LCBjbG91ZCBjb21wdXRpbmcsIFNETikuICBBcyBmb3IgbWFuYWdlbWVudCBwcm90b2NvbHMsIFJF U1RDT05GIHdpbGwgc29vbiBiZSBzdGFuZGFyZGl6ZWQsIGJ1dCB0cmFuc3BvcnQgbmVlZHMgdG8g YmUgYWRkcmVzc2VkIGZvciBNQU5FVC4gIENvTUkgc2VlbXMgdG8gYmUgYSBnb29kIGZpdCBmb3Ig TUFORVQsIGJ1dCBpdCdsbCBiZSBmYXIgZnJvbSBiZWluZyBtYXR1cmVkLiAgQW55aG93LCBpZiB3 ZSB3b3JrIGFuZCBwdWJsaXNoIHRoaXMgZG9jdW1lbnQsIGl0J2xsIGJlIG91dCBvZiBkYXRlIGlu IGEgeWVhciBvciB0d28uICBJIGNhbiB2b2x1bnRlZXIgdG8gd29yayBvbiB0aGlzLCBidXQgSSBu ZWVkIHNvbWUgZ3VpZGFuY2UuICANCg0KDQpPbiBhIHNlcGFyYXRlIG5vdGUsIGZvciBhbGwgZnV0 dXJlIHByb3RvY29scywgd2lsbCB3ZSBjb250aW51ZSB0byBkZXZlbG9wIE1JQiBvciBZQU5HPyAg DQoNCg0KCU1BTkVUIE1haW50ZW5hbmNlICAtIFJGQzU0NDQgU2VjdXJpdHkgZXh0ZW5zaW9uIChT dGFuZGFyZHMpIC0gRW5oYW5jZWQgQU9EVnYyIGdhdGV3YXkgZXh0ZW5zaW9uIChTdGFuZGFyZHMp TUFORVQgTXVsdGljYXN0IC0gTXVsdGljYXN0IEZJQiAoU3RhbmRhcmRzKVRoaXMgd2lsbCBsaWtl bHkgYmUgY29uc2lkZXJlZCB0b28gYnJvYWQgdG8gcGFzcy4gIFdlIHdpbGwgbGlrZWx5IG5lZWQg dG8gY3V0IHNvbWUgYW5kIGZvY3VzIHRoZSB3b3JrLiAgRm9yIG1lIHBlcnNvbmFsbHkgSSBrbm93 IEkgaGF2ZSB0aGUgdGltZSBhbmQgYmFja2luZyB0byB3b3JrIG9uIHRoZSBNdWx0aWNhc3QgcGll Y2UuICBKdXN0aW4NCg0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoJbWFuZXQgbWFpbGluZyBsaXN0DQoJbWFuZXRAaWV0Zi5vcmcgPCBDYXV0aW9uLW1h aWx0bzptYW5ldEBpZXRmLm9yZyA+IA0KCUNhdXRpb24taHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tYW5ldCA8IENhdXRpb24taHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tYW5ldCA+IA0KCQ0KCQ0KDQoNCg0KDQotLSANCg0KSmFtZXMgTmd1eWVuDQpF bWFpbDogamFtZXMuaHV5Lm5ndXllbkBnbWFpbC5jb20gPCBDYXV0aW9uLW1haWx0bzpqYW1lcy5o dXkubmd1eWVuQGdtYWlsLmNvbSA+IA0K From nobody Wed May 4 08:21:04 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D1B12D73A for ; Wed, 4 May 2016 08:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa9_oskEO_FM for ; Wed, 4 May 2016 08:20:59 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA99C12D6C9 for ; Wed, 4 May 2016 08:18:54 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id u5so26175544igk.1 for ; Wed, 04 May 2016 08:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=TkGsZPUyWbs7NhBcMS6WOOYNI+OlQL4mpZU3pfGJcZc=; b=pvJo3m0yO9DNL6zNkda5Eans95hhGfdveX7WG5c4N/rZskheED74cs6k2W76CsHDK+ DgWY8MlWSNF0ZqiS44B0UNhYVC2XXeoQ3FVCLPYVvumQSRRdDJZ1os5x+ZVIvXBxh4k5 OYW3K5Xupo9KOAZtWto6aPbSE69yam/MfH1Qr/H21nmoC8o0RkDNqb7rHH0oJ8xWfAsi oSL3zRGYzqdiS9FrmhcefT7E7Fko64nP1PjzrzJpRoi5TlbQ0FhXH6tShAj+zTtAfyjh i3reXc5nJGvdbclBu1ItKnCvhJDozxbjnDiN6wiCB39hHSfQIQPJBghgxlDswG/qTKfX t2Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TkGsZPUyWbs7NhBcMS6WOOYNI+OlQL4mpZU3pfGJcZc=; b=Hchsnn/2lgp5Hzffo3OjmP6AX0eEtFQW1l/tyTVU4dEYyiPcf0jAhih0HLbYSAMi1g DXV2rzY8OkEyFLnzuMe9ibm02Jb9B203v/lPCUL6yNsxEqPPXgAnOMEAtR7e4qsrR702 gYCcScBstiyv7fLbMsafTCQ57/544lpGhbE+KxwYA3W0g2/Oi6ri4XgblsyZaz/jgOov aYh3g+r+sO4BpY3C/a2i2JXtoaEiM929n42mPZh8i8Nkv7aGyP+gMGtonAnBjFZUYuNi gfdNZUXaUaPb7s2FcxMkMMsCLCNg9fqxJ4V/pZizpk12p2UIMTKBe/msg+r45BnrOWvY WWPw== X-Gm-Message-State: AOPr4FVvluorFWpmhpY/JsRrFG+vlwJX2ji0kAYdQOThRnvQmne8LM9Q2rf27umy7/DHpT9W0ytL9/am1RzOfg== MIME-Version: 1.0 X-Received: by 10.50.23.196 with SMTP id o4mr11241169igf.36.1462375134272; Wed, 04 May 2016 08:18:54 -0700 (PDT) Received: by 10.79.72.68 with HTTP; Wed, 4 May 2016 08:18:54 -0700 (PDT) In-Reply-To: References: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com> <2DC54CCE-46BE-48D0-9497-52D31DCB5B40@inf-net.nl> <8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> Date: Wed, 4 May 2016 11:18:54 -0400 Message-ID: From: Stan Ratliff To: John Dowdell Content-Type: multipart/alternative; boundary=14dae93b57126829cf053205be54 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , MANET IETF Subject: Re: [manet] DLEP and latency metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:21:02 -0000 --14dae93b57126829cf053205be54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, That actually wasn't my proposal. I'll attempt to clarify. First off, the text from DLEP-22 on Latency, in Section 10.16: "The Latency value is reported as transmission delay. The calculation of latency is implementation dependent. For example, the latency may be a running average calculated from the internal queuing." So, the text doesn't mandate that queuing delay be included, it just lists that as an example. That being said, I'm one who doesn't see that a Latency calculation is all that interesting *UNLESS* you include queuing delay. Otherwise, to me anyway, it's along the lines of "You know Mr. Router, my normal bit-twiddling delay + Propagation Delay on this RF link is about ms. What I'll leave unsaid is how bad things get if/when a queue of traffic exists for said link, but that's OK, isn't it? What's some unknown (unreported) amount of delay between friends?" The first calculation (ignoring queuing delay) is more or less "Here's my *best case* Latency". Add "some fudge-factor" to make it anywhere close to real. So, my proposal was: 1. Leave the bandwidth definition alone, in that it does *not* include current traffic on the link. It's an indication of "how fast is the pipe". 2. Leave the Latency stuff alone as well - yes, the example includes queuing delay. But it's only an example; nothing stops a vendor from implementing Latency *without* queuing delay, although I think that's a bad idea. 3. Look at the possibility of augmenting the statistics to make everyone happy. Specifically, add a. A "Bandwidth Utilization" metric. That way, a router could see something like "CDRT on the link is 20Mbps, and the link is currently at 80% capacity). b. A "Propagation Delay" metric, that is *exactly* what John has been discussing. That metric is "modem bit-twiddling time, in case the frame has to be somehow morphed for transmission, PLUS RF propagation delay." That number would change if, for instance, the modem changes modulation techniques on the link, but would otherwise be pretty stable. OK, I'm running for the closet to jump into the flame-retardant suit... :-) Regards, Stan On Wed, May 4, 2016 at 9:08 AM, John Dowdell wrote: > > On 4 May 2016, at 13:38, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > Was the suggestion to include an empty queuing delay, i.e. it included > everything, but in the case where the queue was empty? > > > Yes that is my proposal, or actually my seconding of Stan=E2=80=99s propo= sal, > assuming I understood Stan correctly. > > Regards > John > > That sounds like a sensible approach, assuming it=E2=80=99s reasonably st= able. > > > *--* > > > > > *Christopher DearloveSenior Principal EngineerBAE Systems Applied > Intelligence Laboratories* > > *________________________________________________________________________= __* > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > *From:* manet [mailto:manet-bounces@ietf.org ] *O= n > Behalf Of *John Dowdell > *Sent:* 04 May 2016 12:43 > *To:* MANET IETF > *Subject:* Re: [manet] DLEP and latency metric > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > *Consider carefully whether you should click on any links, open any > attachments or reply.For information regarding **Red Flags** that you can > look out for in emails you receive, click here > .* > *If you feel the email is suspicious, please follow this process > .* > **** **WARNING ****** > EXTERNAL EMAIL -- This message originates from outside our organization. > > I know we=E2=80=99re all a bit tied up with various last calls but can I = ask for > adjudication on this point? The current draft is ambiguous as to whether > the latency metric includes the current queuing delay, taking account of > how full or not the queue is at the sampling instant, or a notional =E2= =80=9Cno > traffic" delay (in the same manner as for the bandwidth metric), and ther= e > are polarised views for and against. > > Just that I=E2=80=99m keen to get this one clarified one way or the other= . > > Following Stan=E2=80=99s proposal below, can I propose that the Latency M= etric is > measured in absence of traffic, and that an extension metric for Link > Utilisation (which could provide metrics plural) is written up? > > Regards > John > > > On 27 Apr 2016, at 07:43, Teco Boot wrote: > > > > Op 27 apr. 2016, om 01:16 heeft Stan Ratliff het > volgende geschreven: > > John, > > Speaking as a co-author and a DLEP implementer, > > On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell > wrote: > Hi all > > A question has arisen as to whether the Latency metric should include > queueing delay in the modem. > > It has long been held that the bandwidth metric is measured in the absenc= e > of traffic (though the metric descriptions in 10.14 and 10.15 of Current > Data Rate are ambiguous on this point), yet section 10.16 of -22 states .= .. > > Yes, that's the way my implementation went. I don't see a use case for a > bandwidth metric that attempts to take traffic into account, and it seems > to me like such a metric could (would) fluctuate wildly. From my > experience, the "interesting statistic" was always "how fast is the pipe?= " > Trying to factor traffic into account can have really weird side-effects = - > for instance, I remember a radio implementation that reported a "Current > Data Rate" of 0 on an idle link (because, after all, no traffic was > flowing)... that drove the router nuts, since it saw a "broken" (or nearl= y > broken) link. > > > > " Latency: A 64-bit unsigned integer, representing the transmission delay= , > in microseconds, that a packet encounters as it is transmitted over the > link.=E2=80=9D > > =E2=80=A6 which suggests that queuing delay should be included. > > Much as in the case above, I can't see a use case for a "Latency" metric > *without* queueing delay. > > > I don't get this. Above, you suggest traffic is not taken into account. > Here, you suggest queuing delay (caused by traffic?) is taken into accoun= t. > > I suggest packet handling delay for a single packet on an idle medium is > taken into account. Delay caused by filled up queues is not. Queue depth > would be another metric. Which would fluctuate wildly^^2. And could be a > complex composite metric when *FQ is used. See RFC 7567 / BCP 197 on what > packet forwarding devices SHOULD do. > > Teco > > > > > > There are positive and negative connotations; a modem queue that suddenly > becomes full might not have any more data queued to it, or a DLEP-powered > routing algorithm might choose another modem instead, allowing the queue = to > subside, but that might not be what the system integrator wanted to happe= n. > > And that would depend on a lot of code that outside the scope of the DLEP > spec - specifically, it depends on how an algorithm actually *deals* with > the DLEP metrics supplied. > > Having said all of that, I can see a possibility for a couple of follow-o= n > metrics for a DLEP extension - the first would be a "Link Utilization" > metric. The other would be a "Propagation delay" metric, based on the > physical properties of the transmission medium. > > Just a thought. > > Regards, > Stan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --14dae93b57126829cf053205be54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,=C2=A0

That actually wasn't my = proposal. I'll attempt to clarify. First off, the text from DLEP-22 on = Latency, in Section 10.16:=C2=A0

"The Latency= value is reported as transmission delay. The calculation
of lat= ency is implementation dependent. For example, the latency may
be= a running average calculated from the internal queuing."
So, the text doesn't mandate that queuing delay be include= d, it just lists that as an example. That being said, I'm one who doesn= 't see that a Latency calculation is all that interesting *UNLESS* you = include queuing delay. Otherwise, to me anyway, it's along the lines of= "You know Mr. Router, my normal bit-twiddling delay + Propagation Del= ay on this RF link is about <blah> ms. What I'll leave unsaid is = how bad things get if/when a queue of traffic exists for said link, but tha= t's OK, isn't it? What's some unknown (unreported) amount of de= lay between friends?"

The first calculation (= ignoring queuing delay) is more or less "Here's my *best case* Lat= ency". Add "some fudge-factor" to make it anywhere close to = real.=C2=A0

So, my proposal was:=C2=A0
1= . Leave the bandwidth definition alone, in that it does *not* include curre= nt traffic on the link. It's an indication of "how fast is the pip= e".=C2=A0
2. Leave the Latency stuff alone as well - yes, th= e example includes queuing delay. But it's only an example; nothing sto= ps a vendor from implementing Latency *without* queuing delay, although I t= hink that's a bad idea.=C2=A0
3. Look at the possibility of a= ugmenting the statistics to make everyone happy. Specifically, add=C2=A0
=C2=A0 =C2=A0 a. A "Bandwidth Utilization" metric. That w= ay, a router could see something like "CDRT on the link is 20Mbps, and= the link is currently at 80% capacity).=C2=A0
=C2=A0 =C2=A0 b. A= "Propagation Delay" metric, that is *exactly* what John has been= discussing. That metric is "modem bit-twiddling time, in case the fra= me has to be somehow morphed for transmission, PLUS RF propagation delay.&q= uot; That number would change if, for instance, the modem changes modulatio= n techniques on the link, but would otherwise be pretty stable.=C2=A0
=

OK, I'm running for the closet to jump into the fla= me-retardant suit... :-)

Regards,
Stan


On W= ed, May 4, 2016 at 9:08 AM, John Dowdell <john.dowdell.ietf@gmai= l.com> wrote:

On 4 May 2016, at 13:38, D= earlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
Was the suggestion to include an empty queuing delay, i.e. it i= ncluded everything, but in the case where the queue was empty?

Yes that is my proposal, or a= ctually my seconding of Stan=E2=80=99s proposal, assuming I understood Stan= correctly.

Regards
John

=
That sounds like a sensible approach, assumi= ng it=E2=80=99s reasonably stable.
=C2=A0

--

Christopher Dearlove
Senior Principal Engine= er
BAE Systems Applied Intelligence Laboratories
_________________________________________________________________________= _

T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Techn= ology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems = Applied Intelligence Limited
Registered in England & Wales No: 01337= 451

Re= gistered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP=

=C2=A0
From:=C2=A0manet [mailto:manet-bounces@ietf.org]=C2=A0On Beh= alf Of=C2=A0John Dowdell
Sent:=C2=A004 May 2016 12:43
To:=C2=A0MANET IETF
Subject= :=C2=A0Re: [manet] DLEP and latency metric
=C2=A0
=C2=A0
*** WARNING ***

This message origin= ates from outside our organisation, either from an external partner or the = internet.
Consider carefully whether you should click on any links, open an= y attachments or reply.
For information regarding=C2=A0Red Flags=C2=A0th= at you can look out for in emails you receive, click=C2=A0here.
If you feel the email is suspicious, please follo= w=C2=A0this proce= ss.

=
***=C2=A0WARNING=C2=A0***
EXTERNAL EMAIL -- This message origin= ates from outside our organization.
=C2=A0
I know= we=E2=80=99re all a bit tied up with various last calls but can I ask for = adjudication on this point? The current draft is ambiguous as to whether th= e latency metric includes the current queuing delay, taking account of how = full or not the queue is at the sampling instant, or a notional =E2=80=9Cno= traffic" delay (in the same manner as for the bandwidth metric), and = there are polarised views for and against.
=C2=A0
Just that I=E2=80=99m keen to get this one clarified one way or the o= ther.
=C2=A0=
Following Stan=E2=80=99s propos= al below, can I propose that the Latency Metric is measured in absence of t= raffic, and that an extension metric for Link Utilisation (which could prov= ide metrics plural) is written up?
=C2=A0
Re= gards
John
=C2=A0
On 27 Apr 2016, at 07:43, Teco Boot <teco@in= f-net.nl> wrote:
= =C2=A0

Op 27 apr. 2016, o= m 01:16 heeft Stan Ratliff <ratliffstan= @gmail.com> het volgende geschreven:

John,

Speaking as= a co-author and a DLEP implementer,

On Tue, Apr 26, 2016 at 6:06 PM= , John Dowdell <john.dowdell.ietf= @gmail.com> wrote:
Hi all

A question has arisen as to whet= her the Latency metric should include queueing delay in the modem.

I= t has long been held that the bandwidth metric is measured in the absence o= f traffic (though the metric descriptions in 10.14 and 10.15 of Current Dat= a Rate are ambiguous on this point), yet section 10.16 of -22 states ...
Yes, that's the way my implementation went. I don't see a use = case for a bandwidth metric that attempts to take traffic into account, and= it seems to me like such a metric could (would) fluctuate wildly. From my = experience, the "interesting statistic" was always "how fast= is the pipe?" Trying to factor traffic into account can have really w= eird side-effects - for instance, I remember a radio implementation that re= ported a "Current Data Rate" of 0 on an idle link (because, after= all, no traffic was flowing)... that drove the router nuts, since it saw a= "broken" (or nearly broken) link.



" Latency:= A 64-bit unsigned integer, representing the transmission delay, in microse= conds, that a packet encounters as it is transmitted over the link.=E2=80= =9D

=E2=80=A6 which suggests that queuing delay should be included.<= br>
Much as in the case above, I can't see a use case for a "La= tency" metric *without* queueing delay.

I don't get this. Above, you suggest traffic is= not taken into account. Here, you suggest queuing delay (caused by traffic= ?) is taken into account.

I suggest packet handling delay for a sing= le packet on an idle medium is taken into account. Delay caused by filled u= p queues is not. Queue depth would be another metric. Which would fluctuate= wildly^^2. And could be a complex composite metric when *FQ is used. See R= FC 7567 / BCP 197 on what packet forwarding devices SHOULD do.

Teco<= br>




There are positive and negative connotations;= a modem queue that suddenly becomes full might not have any more data queu= ed to it, or a DLEP-powered routing algorithm might choose another modem in= stead, allowing the queue to subside, but that might not be what the system= integrator wanted to happen.

And that would depend on a lot of code= that outside the scope of the DLEP spec - specifically, it depends on how = an algorithm actually *deals* with the DLEP metrics supplied.

Having= said all of that, I can see a possibility for a couple of follow-on metric= s for a DLEP extension - the first would be a "Link Utilization" = metric. The other would be a "Propagation delay" metric, based on= the physical properties of the transmission medium.

Just a thought.=

Regards,
Stan


_______________________________________= ________
manet mailing list
manet@ietf.or= g
https://www.ietf.o= rg/mailman/listinfo/manet
=
=C2=A0

*****************************************= ***************************
This email and any attachments are confident= ial to the intended
recipient and may also be privileged. If you are not= the intended
recipient please delete it from your system and notify the= sender.
You should not copy it or use it for any purpose nor disclose o= r
distribute its contents to any other person.
**********************= **********************************************

=

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--14dae93b57126829cf053205be54-- From nobody Wed May 4 08:24:48 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2890812D7B7 for ; Wed, 4 May 2016 08:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EciTzlQs39A0 for ; Wed, 4 May 2016 08:24:44 -0700 (PDT) Received: from ndjsvnpf101.ndc.nasa.gov (NDJSVNPF101.ndc.nasa.gov [198.117.1.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAA612D793 for ; Wed, 4 May 2016 08:22:26 -0700 (PDT) Received: from ndjsppt104.ndc.nasa.gov (ndjsppt104.ndc.nasa.gov [198.117.1.198]) by ndjsvnpf101.ndc.nasa.gov (Postfix) with ESMTP id DB3E14005C67; Wed, 4 May 2016 10:22:25 -0500 (CDT) Received: from NDJSCHT116.ndc.nasa.gov (ndjscht116-pub.ndc.nasa.gov [198.117.1.216]) by ndjsppt104.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u44FMPMb032122; Wed, 4 May 2016 10:22:25 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.156]) by NDJSCHT116.ndc.nasa.gov ([198.117.1.216]) with mapi id 14.03.0266.001; Wed, 4 May 2016 10:22:25 -0500 From: "Ivancic, William D. (GRC-LCA0)" To: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" , James Nguyen , Justin Dean Thread-Topic: [manet] [Non-DoD Source] Re: Recharter Discussion Thread-Index: AQHRphcUYNmVOwYgPUy1vWxZVTlPaJ+o9oGA Date: Wed, 4 May 2016 15:22:25 +0000 Message-ID: References: <8486C8728176924BAF5BDB2F7D7EEDDFA2829F65@UCOLHU2J.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDFA2829F65@UCOLHU2J.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [139.88.111.195] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-04_05:, , signatures=0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] [Non-DoD Source] Re: Recharter Discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:24:47 -0000 Radhika, To me, depending on how one looks at this, it boarders on either a research item or a deployment item (addressing schemes that work between ad-hoc and backbone, etc=8A). Can you better define what you would like out of the engineer group? Do we need a protocol that operates between the tiers? Will On 5/4/16, 11:09 AM, "manet on behalf of Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" wrote: >Folks: > >I am also interested in the broader framework of MANETs. The framework >should include as follows: > >1. The fundamental network topology architecture of MANETs is >peer-to-peer (P2P) by definition as all nodes move from one place to >another with mobility patterns that are termed as "ad hoc" movements >where each node independently with no fixed infrastructures, and they use >the IP MANET physical routing protocols t(e.g. AODVv2) hat include >broadcast and multicast. > >2. The large-scale MANETs topology architecture will be hierarchical al >least of two tiers: Access MANETs and a Backbone MANET that connects all >access MANETs. Each access MANET may use IP MANET physical routing >protocol (e.g. AODVv2). However, the Backbone MANET may use "logical" >routing protocol (such as, Key-based Distributed Hash Table [DHT]) that >may use unicast among the backbone node peers (may cluster head). It >implies that we need to develop (or choose or modified from the existing >DHT) the Key-based DHT "logical" routing protocol with unicast that is >suitable for the Backbone MANET. > >3. It implies that there will two kinds of routing protocol: Access MANET >Physical Routing Protocol (e.g. AODVv2) and Backbone MANET Logical >Unicast Routing Protocol (e.g. DHT-based routing schemes). > >Comments will be appreciated on the above topic. > >Best regards, >Radhika=20 > >-----Original Message----- >From: manet [mailto:manet-bounces@ietf.org] On Behalf Of James Nguyen >Sent: Wednesday, May 04, 2016 10:44 AM >To: Justin Dean >Cc: manet@ietf.org >Subject: [Non-DoD Source] Re: [manet] Recharter Discussion > >All active links contained in this email were disabled. Please verify the >identity of the sender, and confirm the authenticity of all links >contained within the message prior to copying and pasting the address to >a Web browser.=20 > > >________________________________ > > > > > >On Fri, Apr 22, 2016 at 11:07 AM, Justin Dean Caution-mailto:bebemaster@gmail.com > > wrote: > > > I'll start things off by floating the draft re-charter which was >presented in Prague. >=09 >=09 > The purpose of the MANET working group is to standardize IP routing >protocol functionality suitable for wireless routing application within >both static and dynamic topologies with increased dynamics due to node >motion or other factors. Approaches are intended to be relatively >lightweight in nature, suitable for multiple hardware and wireless >environments, and address scenarios where MANETs are deployed at the >edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a >mixture of fixed and mobile routers) should also be supported by MANET >specifications and management features.The MANET WG is responsible for >the maintenance of OLSRv2, AODVv2, DLEP and NHPD. Of particular interest: >border behavior between MANET networks and fixed IP network >infrastructures, enhance AODVv2 gateway functionality; security >enhancements, encryption security extensions for RFC5444. > >> + 1 >I'm interested in "border behavior between MANET networks and fixed IP >network infrastructures." Is there any existing work on this? > > The MANET WG will standardize a multicast MANET protocol framework based >on previous work and lessons learned for scoped forwarding within MANET >networks. As part of this framework the WG will produce a well defined >MANET multicast forwarding information base. > >> +1 =20 > > > The WG will produce an informational draft outlining challenges and best >practices for deploying and managing MANET networks.The MANET WG will >interact with the PIM working group on issues relating to the multicast >work. The WG will also pay attention to other IETF and IRTF work that is >addressing topics related to MANET environments.In summary, the WG will >develop the following drafts:MANET Management Document (Informational) > >> I'm still unclear what would be the in the document. As of now, there >>isn't a clear management solution for MANET (eg.g, cloud computing, >>SDN). As for management protocols, RESTCONF will soon be standardized, >>but transport needs to be addressed for MANET. CoMI seems to be a good >>fit for MANET, but it'll be far from being matured. Anyhow, if we work >>and publish this document, it'll be out of date in a year or two. I can >>volunteer to work on this, but I need some guidance. > > >On a separate note, for all future protocols, will we continue to develop >MIB or YANG? =20 > > > MANET Maintenance - RFC5444 Security extension (Standards) - Enhanced >AODVv2 gateway extension (Standards)MANET Multicast - Multicast FIB >(Standards)This will likely be considered too broad to pass. We will >likely need to cut some and focus the work. For me personally I know I >have the time and backing to work on the Multicast piece. Justin > > _______________________________________________ > manet mailing list > manet@ietf.org < Caution-mailto:manet@ietf.org > > Caution-https://www.ietf.org/mailman/listinfo/manet < >Caution-https://www.ietf.org/mailman/listinfo/manet > >=09 >=09 > > > > >--=20 > >James Nguyen >Email: james.huy.nguyen@gmail.com < >Caution-mailto:james.huy.nguyen@gmail.com > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From nobody Wed May 4 08:35:55 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810AE12D7CC for ; Wed, 4 May 2016 08:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMQS8FRUDl3W for ; Wed, 4 May 2016 08:35:51 -0700 (PDT) Received: from uhil19pa15.eemsg.mail.mil (uhil19pa15.eemsg.mail.mil [214.24.21.88]) by ietfa.amsl.com (Postfix) with ESMTP id 678F212D7F2 for ; Wed, 4 May 2016 08:31:32 -0700 (PDT) Received: from edge-cols03.mail.mil ([131.64.107.103]) by uhil19pa15.eemsg.mail.mil with ESMTP; 04 May 2016 15:31:31 +0000 Received: from UCOLHPPY.easf.csd.disa.mil (131.64.107.34) by edge-cols03.mail.mil (131.64.107.103) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 4 May 2016 15:31:31 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([169.254.6.80]) by UCOLHPPY.easf.csd.disa.mil ([131.64.107.34]) with mapi id 14.03.0266.001; Wed, 4 May 2016 15:31:31 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: "Ivancic, William D. (GRC-LCA0)" Thread-Topic: [manet] [Non-DoD Source] Re: Recharter Discussion Thread-Index: AQHRphjJqIAEDRSJWU6Ehw4VMzvIep+o5gkw Date: Wed, 4 May 2016 15:31:30 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDFA282BFE5@UCOLHU2J.easf.csd.disa.mil> References: <8486C8728176924BAF5BDB2F7D7EEDDFA2829F65@UCOLHU2J.easf.csd.disa.mil> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.13] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] [Non-DoD Source] Re: Recharter Discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:35:53 -0000 Hi, Will: Please inline [RRR]. BR/Radhika -----Original Message----- From: Ivancic, William D. (GRC-LCA0) [mailto:william.d.ivancic@nasa.gov]=20 Sent: Wednesday, May 04, 2016 11:22 AM To: Roy, Radhika R CIV USARMY RDECOM CERDEC (US) ; James Nguyen ; Justin Dean Cc: manet@ietf.org Subject: Re: [manet] [Non-DoD Source] Re: Recharter Discussion Radhika, To me, depending on how one looks at this, it boarders on either a research item or a deployment item (addressing schemes that work between ad-hoc and backbone, etc=A9). Can you better define what you would like out of the engineer group? Do we need a protocol that operates between the tiers? [RRR] Yes. A unicast protocol between the independent peers that form the h= ierarchical tiers (in this case, say 2-tier network: access and Backbone - = the peering nodes that form the backbone may be cluster heads). That is , w= e need a routing protocol among backbone nodes using unicast. Will On 5/4/16, 11:09 AM, "manet on behalf of Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" wrote: >Folks: > >I am also interested in the broader framework of MANETs. The framework >should include as follows: > >1. The fundamental network topology architecture of MANETs is >peer-to-peer (P2P) by definition as all nodes move from one place to >another with mobility patterns that are termed as "ad hoc" movements >where each node independently with no fixed infrastructures, and they use >the IP MANET physical routing protocols t(e.g. AODVv2) hat include >broadcast and multicast. > >2. The large-scale MANETs topology architecture will be hierarchical al >least of two tiers: Access MANETs and a Backbone MANET that connects all >access MANETs. Each access MANET may use IP MANET physical routing >protocol (e.g. AODVv2). However, the Backbone MANET may use "logical" >routing protocol (such as, Key-based Distributed Hash Table [DHT]) that >may use unicast among the backbone node peers (may cluster head). It >implies that we need to develop (or choose or modified from the existing >DHT) the Key-based DHT "logical" routing protocol with unicast that is >suitable for the Backbone MANET. > >3. It implies that there will two kinds of routing protocol: Access MANET >Physical Routing Protocol (e.g. AODVv2) and Backbone MANET Logical >Unicast Routing Protocol (e.g. DHT-based routing schemes). > >Comments will be appreciated on the above topic. > >Best regards, >Radhika=20 > >-----Original Message----- >From: manet [mailto:manet-bounces@ietf.org] On Behalf Of James Nguyen >Sent: Wednesday, May 04, 2016 10:44 AM >To: Justin Dean >Cc: manet@ietf.org >Subject: [Non-DoD Source] Re: [manet] Recharter Discussion > >All active links contained in this email were disabled. Please verify the >identity of the sender, and confirm the authenticity of all links >contained within the message prior to copying and pasting the address to >a Web browser.=20 > > >________________________________ > > > > > >On Fri, Apr 22, 2016 at 11:07 AM, Justin Dean Caution-mailto:bebemaster@gmail.com > > wrote: > > > I'll start things off by floating the draft re-charter which was >presented in Prague. >=09 >=09 > The purpose of the MANET working group is to standardize IP routing >protocol functionality suitable for wireless routing application within >both static and dynamic topologies with increased dynamics due to node >motion or other factors. Approaches are intended to be relatively >lightweight in nature, suitable for multiple hardware and wireless >environments, and address scenarios where MANETs are deployed at the >edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a >mixture of fixed and mobile routers) should also be supported by MANET >specifications and management features.The MANET WG is responsible for >the maintenance of OLSRv2, AODVv2, DLEP and NHPD. Of particular interest: >border behavior between MANET networks and fixed IP network >infrastructures, enhance AODVv2 gateway functionality; security >enhancements, encryption security extensions for RFC5444. > >> + 1 >I'm interested in "border behavior between MANET networks and fixed IP >network infrastructures." Is there any existing work on this? > > The MANET WG will standardize a multicast MANET protocol framework based >on previous work and lessons learned for scoped forwarding within MANET >networks. As part of this framework the WG will produce a well defined >MANET multicast forwarding information base. > >> +1 =20 > > > The WG will produce an informational draft outlining challenges and best >practices for deploying and managing MANET networks.The MANET WG will >interact with the PIM working group on issues relating to the multicast >work. The WG will also pay attention to other IETF and IRTF work that is >addressing topics related to MANET environments.In summary, the WG will >develop the following drafts:MANET Management Document (Informational) > >> I'm still unclear what would be the in the document. As of now, there >>isn't a clear management solution for MANET (eg.g, cloud computing, >>SDN). As for management protocols, RESTCONF will soon be standardized, >>but transport needs to be addressed for MANET. CoMI seems to be a good >>fit for MANET, but it'll be far from being matured. Anyhow, if we work >>and publish this document, it'll be out of date in a year or two. I can >>volunteer to work on this, but I need some guidance. > > >On a separate note, for all future protocols, will we continue to develop >MIB or YANG? =20 > > > MANET Maintenance - RFC5444 Security extension (Standards) - Enhanced >AODVv2 gateway extension (Standards)MANET Multicast - Multicast FIB >(Standards)This will likely be considered too broad to pass. We will >likely need to cut some and focus the work. For me personally I know I >have the time and backing to work on the Multicast piece. Justin > > _______________________________________________ > manet mailing list > manet@ietf.org < Caution-mailto:manet@ietf.org > > Caution-https://www.ietf.org/mailman/listinfo/manet < >Caution-https://www.ietf.org/mailman/listinfo/manet > >=09 >=09 > > > > >--=20 > >James Nguyen >Email: james.huy.nguyen@gmail.com < >Caution-mailto:james.huy.nguyen@gmail.com > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From nobody Wed May 4 08:43:47 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD0012D957 for ; Wed, 4 May 2016 08:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykx70SXCwXOR for ; Wed, 4 May 2016 08:43:40 -0700 (PDT) Received: from uhil19pa11.eemsg.mail.mil (uhil19pa11.eemsg.mail.mil [214.24.21.84]) by ietfa.amsl.com (Postfix) with ESMTP id B60F512D70A for ; Wed, 4 May 2016 08:37:54 -0700 (PDT) Received: from edge-cols03.mail.mil ([131.64.107.101]) by uhil19pa11.eemsg.mail.mil with ESMTP; 04 May 2016 15:37:53 +0000 Received: from UCOLHPPW.easf.csd.disa.mil (131.64.107.32) by edge-cols03.mail.mil (131.64.107.101) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 4 May 2016 15:37:53 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([169.254.6.80]) by UCOLHPPW.easf.csd.disa.mil ([131.64.107.32]) with mapi id 14.03.0266.001; Wed, 4 May 2016 15:37:53 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: "Ivancic, William D. (GRC-LCA0)" Thread-Topic: [manet] [Non-DoD Source] Re: Recharter Discussion Thread-Index: AQHRphjJqIAEDRSJWU6Ehw4VMzvIep+o5gkwgAADBuA= Date: Wed, 4 May 2016 15:37:52 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDFA282BFFF@UCOLHU2J.easf.csd.disa.mil> References: <8486C8728176924BAF5BDB2F7D7EEDDFA2829F65@UCOLHU2J.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.13] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] [Non-DoD Source] Re: Recharter Discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:43:46 -0000 Hi, Will: For further help, I am providing a reference paper to understand what I am = trying to say for standardization in this MANET WG: Shahbaz Akhtar Abid, Mazliza Othman, and Nadir Shah. 2014. A survey on DHT-= based routing for largescale mobile ad hoc networks. ACM Comput. Surv. 47, 2, Article 20 (August 2014), = 46 pages. DOI: http://dx.doi.org/10.1145/2632296 If you google it, you can retrieve the paper. BR/Radhika -----Original Message----- From: Roy, Radhika R CIV USARMY RDECOM CERDEC (US)=20 Sent: Wednesday, May 04, 2016 11:31 AM To: 'Ivancic, William D. (GRC-LCA0)' Cc: manet@ietf.org Subject: RE: [manet] [Non-DoD Source] Re: Recharter Discussion Hi, Will: Please inline [RRR]. BR/Radhika -----Original Message----- From: Ivancic, William D. (GRC-LCA0) [mailto:william.d.ivancic@nasa.gov] Sent: Wednesday, May 04, 2016 11:22 AM To: Roy, Radhika R CIV USARMY RDECOM CERDEC (US) ; James Nguyen ; Justin Dean Cc: manet@ietf.org Subject: Re: [manet] [Non-DoD Source] Re: Recharter Discussion Radhika, To me, depending on how one looks at this, it boarders on either a research= item or a deployment item (addressing schemes that work between ad-hoc and= backbone, etc=A9). Can you better define what you would like out of the engineer group? Do we= need a protocol that operates between the tiers? [RRR] Yes. A unicast protocol between the independent peers that form the h= ierarchical tiers (in this case, say 2-tier network: access and Backbone - = the peering nodes that form the backbone may be cluster heads). That is , w= e need a routing protocol among backbone nodes using unicast. Will On 5/4/16, 11:09 AM, "manet on behalf of Roy, Radhika R CIV USARMY RDECOM C= ERDEC (US)" wrote: >Folks: > >I am also interested in the broader framework of MANETs. The framework=20 >should include as follows: > >1. The fundamental network topology architecture of MANETs is=20 >peer-to-peer (P2P) by definition as all nodes move from one place to=20 >another with mobility patterns that are termed as "ad hoc" movements=20 >where each node independently with no fixed infrastructures, and they=20 >use the IP MANET physical routing protocols t(e.g. AODVv2) hat include=20 >broadcast and multicast. > >2. The large-scale MANETs topology architecture will be hierarchical al=20 >least of two tiers: Access MANETs and a Backbone MANET that connects=20 >all access MANETs. Each access MANET may use IP MANET physical routing=20 >protocol (e.g. AODVv2). However, the Backbone MANET may use "logical" >routing protocol (such as, Key-based Distributed Hash Table [DHT]) that=20 >may use unicast among the backbone node peers (may cluster head). It=20 >implies that we need to develop (or choose or modified from the=20 >existing >DHT) the Key-based DHT "logical" routing protocol with unicast that is=20 >suitable for the Backbone MANET. > >3. It implies that there will two kinds of routing protocol: Access=20 >MANET Physical Routing Protocol (e.g. AODVv2) and Backbone MANET=20 >Logical Unicast Routing Protocol (e.g. DHT-based routing schemes). > >Comments will be appreciated on the above topic. > >Best regards, >Radhika > >-----Original Message----- >From: manet [mailto:manet-bounces@ietf.org] On Behalf Of James Nguyen >Sent: Wednesday, May 04, 2016 10:44 AM >To: Justin Dean >Cc: manet@ietf.org >Subject: [Non-DoD Source] Re: [manet] Recharter Discussion > >All active links contained in this email were disabled. Please verify=20 >the identity of the sender, and confirm the authenticity of all links=20 >contained within the message prior to copying and pasting the address=20 >to a Web browser. > > >________________________________ > > > > > >On Fri, Apr 22, 2016 at 11:07 AM, Justin Dean Caution-mailto:bebemaster@gmail.com > > wrote: > > > I'll start things off by floating the draft re-charter which was=20 >presented in Prague. >=09 >=09 > The purpose of the MANET working group is to standardize IP routing=20 >protocol functionality suitable for wireless routing application within=20 >both static and dynamic topologies with increased dynamics due to node=20 >motion or other factors. Approaches are intended to be relatively=20 >lightweight in nature, suitable for multiple hardware and wireless=20 >environments, and address scenarios where MANETs are deployed at the=20 >edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a=20 >mixture of fixed and mobile routers) should also be supported by MANET=20 >specifications and management features.The MANET WG is responsible for=20 >the maintenance of OLSRv2, AODVv2, DLEP and NHPD. Of particular interest: >border behavior between MANET networks and fixed IP network=20 >infrastructures, enhance AODVv2 gateway functionality; security=20 >enhancements, encryption security extensions for RFC5444. > >> + 1 >I'm interested in "border behavior between MANET networks and fixed IP=20 >network infrastructures." Is there any existing work on this? > > The MANET WG will standardize a multicast MANET protocol framework=20 >based on previous work and lessons learned for scoped forwarding within=20 >MANET networks. As part of this framework the WG will produce a well=20 >defined MANET multicast forwarding information base. > >> +1 > > > The WG will produce an informational draft outlining challenges and best >practices for deploying and managing MANET networks.The MANET WG will >interact with the PIM working group on issues relating to the multicast >work. The WG will also pay attention to other IETF and IRTF work that is >addressing topics related to MANET environments.In summary, the WG will >develop the following drafts:MANET Management Document (Informational) > >> I'm still unclear what would be the in the document. As of now, there >>isn't a clear management solution for MANET (eg.g, cloud computing, >>SDN). As for management protocols, RESTCONF will soon be standardized, >>but transport needs to be addressed for MANET. CoMI seems to be a good >>fit for MANET, but it'll be far from being matured. Anyhow, if we work >>and publish this document, it'll be out of date in a year or two. I can >>volunteer to work on this, but I need some guidance. > > >On a separate note, for all future protocols, will we continue to develop >MIB or YANG? =20 > > > MANET Maintenance - RFC5444 Security extension (Standards) - Enhanced >AODVv2 gateway extension (Standards)MANET Multicast - Multicast FIB >(Standards)This will likely be considered too broad to pass. We will >likely need to cut some and focus the work. For me personally I know I >have the time and backing to work on the Multicast piece. Justin > > _______________________________________________ > manet mailing list > manet@ietf.org < Caution-mailto:manet@ietf.org > > Caution-https://www.ietf.org/mailman/listinfo/manet < >Caution-https://www.ietf.org/mailman/listinfo/manet > >=09 >=09 > > > > >--=20 > >James Nguyen >Email: james.huy.nguyen@gmail.com < >Caution-mailto:james.huy.nguyen@gmail.com > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From nobody Wed May 4 10:04:46 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C15B712D950; Wed, 4 May 2016 10:04:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504170444.8256.99788.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 10:04:44 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 17:04:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Rules For Designing Protocols Using the RFC 5444 Generalized Packet/ Message Format Authors : Thomas Clausen Christopher Dearlove Ulrich Herberg Henning Rogge Filename : draft-ietf-manet-rfc5444-usage-04.txt Pages : 24 Date : 2016-05-04 Abstract: RFC 5444 specifies a generalized MANET packet/message format and describes an intended use to multiplex MANET routing protocol messages that is mandated for use by RFC 5498. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses of RFC 5444 that have been suggested in various proposals, and which would have led to interoperability problems, to the impediment of protocol extension development, and to an inability to use optional generic RFC 5444 parsers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc5444-usage-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 4 10:09:06 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AAA12D7D2; Wed, 4 May 2016 10:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE23wxYu0K1X; Wed, 4 May 2016 10:09:01 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0154712D7EC; Wed, 4 May 2016 10:06:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,578,1454976000"; d="scan'208";a="34704178" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 04 May 2016 18:06:42 +0100 X-IronPort-AV: E=Sophos;i="5.24,578,1454976000"; d="scan'208";a="116709976" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 04 May 2016 18:06:43 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.88]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Wed, 4 May 2016 18:06:42 +0100 From: "Dearlove, Christopher (UK)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-04.txt Thread-Index: AQHRpicTeTYjR0Vi70eXxg54BSxPCJ+pAfqg Date: Wed, 4 May 2016 17:06:41 +0000 Message-ID: References: <20160504170444.8256.99788.idtracker@ietfa.amsl.com> In-Reply-To: <20160504170444.8256.99788.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 17:09:05 -0000 This includes all of the issues I listed in my previous email of comments m= ade at WGLC. The authors request starting all the post-WGLC things to do. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: 04 May 2016 18:05 To: i-d-announce@ietf.org Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-04.txt ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- *** WARNING *** EXTERNAL EMAIL -- This message originates from outside our organization. A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Rules For Designing Protocols Using the RFC 5444 = Generalized Packet/ Message Format Authors : Thomas Clausen Christopher Dearlove Ulrich Herberg Henning Rogge Filename : draft-ietf-manet-rfc5444-usage-04.txt Pages : 24 Date : 2016-05-04 Abstract: RFC 5444 specifies a generalized MANET packet/message format and describes an intended use to multiplex MANET routing protocol messages that is mandated for use by RFC 5498. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses of RFC 5444 that have been suggested in various proposals, and which would have led to interoperability problems, to the impediment of protocol extension development, and to an inability to use optional generic RFC 5444 parsers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc5444-usage-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From nobody Wed May 4 10:20:44 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D0C12D559 for ; Wed, 4 May 2016 10:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cococorp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kDtXmryYmkN for ; Wed, 4 May 2016 10:20:39 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F0812D0CE for ; Wed, 4 May 2016 10:20:39 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id x19so73413808oix.2 for ; Wed, 04 May 2016 10:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cococorp.com; s=google; h=from:mime-version:in-reply-to:references:date:message-id:subject:to :cc; bh=P7pTKOM1LJOULVDTsFSu0BfuD4jsh0oIEG3ELqFXH+0=; b=ip0O679xjKb+wQj5Q86gjeuDMEioq1lN2Pisb7McYIt1goKHAW+l2WApiw1takiIoE I2ZUHNn5hFvIqqOur/rsqA9Nu4iW67qRnAe9K7MqXYTGzSqjvdf7qSnYZx2kt1e6qD+4 cWWkLjsP7gTCzBX/O61ynu+sZx5qT6ARKrA1o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:in-reply-to:references:date :message-id:subject:to:cc; bh=P7pTKOM1LJOULVDTsFSu0BfuD4jsh0oIEG3ELqFXH+0=; b=DrPvAZhUmhwq2+C3icdstJZS8DriY5PxgVvEdsWRVnJsqjahxEBye54HuvPZfYqOq9 xsKjKSV6DPVO4aYq8w8Uip/H/vBX5pAnpV4CtllzENUH9B2dmbdM10BdILVZlev+lJnU B6MTp9MshHYAHA2y0lpKhtztBnAWSarOJSNudRWLoSknoRSdKCXpjN4+hUimD+sLeyfM ZSJee21RKkhzxLWrnnrL1/frMm3vNPHCWDcuBu0DIy7YMmB3QtSYA7/IcFHTYIvXoA39 Lst/kHCfZ73j8ArdBO8ROwocNzSUlFgvVQgWBd1T3uIS8HmPJp1+jQaoZ2jeaHvYxPLE RFRw== X-Gm-Message-State: AOPr4FXly1EiVOzXnY2wiCWoHW8vduiTjvR/E8ccNO3mqRC6VXNH4M9XGwIZ8+Gu+jO+6GA8JKU5AuT2usWj+1rz X-Received: by 10.202.201.197 with SMTP id z188mr4717474oif.176.1462382438732; Wed, 04 May 2016 10:20:38 -0700 (PDT) From: "A .Riley Eller" Mime-Version: 1.0 (1.0) In-Reply-To: References: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com> <2DC54CCE-46BE-48D0-9497-52D31DCB5B40@inf-net.nl> <8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> Date: Wed, 4 May 2016 10:20:37 -0700 Message-ID: <-4425690961467974600@unknownmsgid> To: Stan Ratliff Content-Type: multipart/alternative; boundary=001a1137b5bec976a905320771c8 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , MANET IETF Subject: Re: [manet] DLEP and latency metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 17:20:43 -0000 --001a1137b5bec976a905320771c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Modem-based priority queuing is a common feature with performance characteristics that may elude the ability of a router to make accurate predictions of behavior or performance. In the case of 802.11, as an example of real-world complex interactions, higher priority traffic has a significantly lower channel acquisition time (and therefore a higher frame capacity) than bulk traffic. Protocol data unit aggregation, in turn, may or may not "piggyback" lower priority packets into a frame being treated as high priority. It makes great sense to report utilization and queuing delay on a per-priority basis. In a previous heterogeneous MANET exercise, my team made very effective use of reporting utilization and queuing delay on a per-ToS basis plus a single, total link capacity. Modems lacking priority queues could report aggregates within the highest priority class. Routers lacking awareness of priority could sum the capacities and average, or select the maximum from among, the latencies. I could try my hand at editing DLEP-22 if this idea appeals to the group. On May 4, 2016, at 8:21 AM, Stan Ratliff wrote: All, That actually wasn't my proposal. I'll attempt to clarify. First off, the text from DLEP-22 on Latency, in Section 10.16: "The Latency value is reported as transmission delay. The calculation of latency is implementation dependent. For example, the latency may be a running average calculated from the internal queuing." So, the text doesn't mandate that queuing delay be included, it just lists that as an example. That being said, I'm one who doesn't see that a Latency calculation is all that interesting *UNLESS* you include queuing delay. Otherwise, to me anyway, it's along the lines of "You know Mr. Router, my normal bit-twiddling delay + Propagation Delay on this RF link is about ms. What I'll leave unsaid is how bad things get if/when a queue of traffic exists for said link, but that's OK, isn't it? What's some unknown (unreported) amount of delay between friends?" The first calculation (ignoring queuing delay) is more or less "Here's my *best case* Latency". Add "some fudge-factor" to make it anywhere close to real. So, my proposal was: 1. Leave the bandwidth definition alone, in that it does *not* include current traffic on the link. It's an indication of "how fast is the pipe". 2. Leave the Latency stuff alone as well - yes, the example includes queuing delay. But it's only an example; nothing stops a vendor from implementing Latency *without* queuing delay, although I think that's a bad idea. 3. Look at the possibility of augmenting the statistics to make everyone happy. Specifically, add a. A "Bandwidth Utilization" metric. That way, a router could see something like "CDRT on the link is 20Mbps, and the link is currently at 80% capacity). b. A "Propagation Delay" metric, that is *exactly* what John has been discussing. That metric is "modem bit-twiddling time, in case the frame has to be somehow morphed for transmission, PLUS RF propagation delay." That number would change if, for instance, the modem changes modulation techniques on the link, but would otherwise be pretty stable. OK, I'm running for the closet to jump into the flame-retardant suit... :-) Regards, Stan On Wed, May 4, 2016 at 9:08 AM, John Dowdell wrote: > > On 4 May 2016, at 13:38, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > Was the suggestion to include an empty queuing delay, i.e. it included > everything, but in the case where the queue was empty? > > > Yes that is my proposal, or actually my seconding of Stan=E2=80=99s propo= sal, > assuming I understood Stan correctly. > > Regards > John > > That sounds like a sensible approach, assuming it=E2=80=99s reasonably st= able. > > > *--* > > > > > *Christopher DearloveSenior Principal EngineerBAE Systems Applied > Intelligence Laboratories* > > *________________________________________________________________________= __* > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > *From:* manet [mailto:manet-bounces@ietf.org ] *O= n > Behalf Of *John Dowdell > *Sent:* 04 May 2016 12:43 > *To:* MANET IETF > *Subject:* Re: [manet] DLEP and latency metric > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > *Consider carefully whether you should click on any links, open any > attachments or reply.For information regarding **Red Flags** that you can > look out for in emails you receive, click here > .* > *If you feel the email is suspicious, please follow this process > .* > **** **WARNING ****** > EXTERNAL EMAIL -- This message originates from outside our organization. > > I know we=E2=80=99re all a bit tied up with various last calls but can I = ask for > adjudication on this point? The current draft is ambiguous as to whether > the latency metric includes the current queuing delay, taking account of > how full or not the queue is at the sampling instant, or a notional =E2= =80=9Cno > traffic" delay (in the same manner as for the bandwidth metric), and ther= e > are polarised views for and against. > > Just that I=E2=80=99m keen to get this one clarified one way or the other= . > > Following Stan=E2=80=99s proposal below, can I propose that the Latency M= etric is > measured in absence of traffic, and that an extension metric for Link > Utilisation (which could provide metrics plural) is written up? > > Regards > John > > > On 27 Apr 2016, at 07:43, Teco Boot wrote: > > > > Op 27 apr. 2016, om 01:16 heeft Stan Ratliff het > volgende geschreven: > > John, > > Speaking as a co-author and a DLEP implementer, > > On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell > wrote: > Hi all > > A question has arisen as to whether the Latency metric should include > queueing delay in the modem. > > It has long been held that the bandwidth metric is measured in the absenc= e > of traffic (though the metric descriptions in 10.14 and 10.15 of Current > Data Rate are ambiguous on this point), yet section 10.16 of -22 states .= .. > > Yes, that's the way my implementation went. I don't see a use case for a > bandwidth metric that attempts to take traffic into account, and it seems > to me like such a metric could (would) fluctuate wildly. From my > experience, the "interesting statistic" was always "how fast is the pipe?= " > Trying to factor traffic into account can have really weird side-effects = - > for instance, I remember a radio implementation that reported a "Current > Data Rate" of 0 on an idle link (because, after all, no traffic was > flowing)... that drove the router nuts, since it saw a "broken" (or nearl= y > broken) link. > > > > " Latency: A 64-bit unsigned integer, representing the transmission delay= , > in microseconds, that a packet encounters as it is transmitted over the > link.=E2=80=9D > > =E2=80=A6 which suggests that queuing delay should be included. > > Much as in the case above, I can't see a use case for a "Latency" metric > *without* queueing delay. > > > I don't get this. Above, you suggest traffic is not taken into account. > Here, you suggest queuing delay (caused by traffic?) is taken into accoun= t. > > I suggest packet handling delay for a single packet on an idle medium is > taken into account. Delay caused by filled up queues is not. Queue depth > would be another metric. Which would fluctuate wildly^^2. And could be a > complex composite metric when *FQ is used. See RFC 7567 / BCP 197 on what > packet forwarding devices SHOULD do. > > Teco > > > > > > There are positive and negative connotations; a modem queue that suddenly > becomes full might not have any more data queued to it, or a DLEP-powered > routing algorithm might choose another modem instead, allowing the queue = to > subside, but that might not be what the system integrator wanted to happe= n. > > And that would depend on a lot of code that outside the scope of the DLEP > spec - specifically, it depends on how an algorithm actually *deals* with > the DLEP metrics supplied. > > Having said all of that, I can see a possibility for a couple of follow-o= n > metrics for a DLEP extension - the first would be a "Link Utilization" > metric. The other would be a "Propagation delay" metric, based on the > physical properties of the transmission medium. > > Just a thought. > > Regards, > Stan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --001a1137b5bec976a905320771c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= div>Modem-based priority queuing is a common feature with performance chara= cteristics that may elude the ability of a router to make accurate predicti= ons of behavior or performance. In the case of 802.11, as an example of rea= l-world complex interactions, higher priority traffic has a significantly l= ower channel acquisition time (and therefore a higher frame capacity) than = bulk traffic. Protocol data unit aggregation, in turn, may or may not "= ;piggyback" lower priority packets into a frame being treated as high = priority. It makes great sense to report utilization and queuing delay on a= per-priority basis.

In a previous heterogeneous M= ANET exercise, my team made very effective use of reporting utilization and= queuing delay on a per-ToS basis plus a single, total link capacity.=C2=A0=

Modems lacking priority queues could report aggre= gates within the highest priority class. Routers lacking awareness of prior= ity could sum the capacities and average, or select the maximum from among,= the latencies.

I could try my hand at editing DLE= P-22 if this idea appeals to the group.


=

On May 4, 2016, at 8:21 AM, Stan Ratliff <ratliffstan@gmail.com> wrote:

All,=C2=A0

Th= at actually wasn't my proposal. I'll attempt to clarify. First off,= the text from DLEP-22 on Latency, in Section 10.16:=C2=A0

"The Latency value is reported as transmission delay. The ca= lculation
of latency is implementation dependent. For example, th= e latency may
be a running average calculated from the internal q= ueuing."

So, the text doesn't mandate tha= t queuing delay be included, it just lists that as an example. That being s= aid, I'm one who doesn't see that a Latency calculation is all that= interesting *UNLESS* you include queuing delay. Otherwise, to me anyway, i= t's along the lines of "You know Mr. Router, my normal bit-twiddli= ng delay + Propagation Delay on this RF link is about <blah> ms. What= I'll leave unsaid is how bad things get if/when a queue of traffic exi= sts for said link, but that's OK, isn't it? What's some unknown= (unreported) amount of delay between friends?"

The first calculation (ignoring queuing delay) is more or less "Her= e's my *best case* Latency". Add "some fudge-factor" to = make it anywhere close to real.=C2=A0

So, my propo= sal was:=C2=A0
1. Leave the bandwidth definition alone, in that i= t does *not* include current traffic on the link. It's an indication of= "how fast is the pipe".=C2=A0
2. Leave the Latency stu= ff alone as well - yes, the example includes queuing delay. But it's on= ly an example; nothing stops a vendor from implementing Latency *without* q= ueuing delay, although I think that's a bad idea.=C2=A0
3. Lo= ok at the possibility of augmenting the statistics to make everyone happy. = Specifically, add=C2=A0
=C2=A0 =C2=A0 a. A "Bandwidth Utiliz= ation" metric. That way, a router could see something like "CDRT = on the link is 20Mbps, and the link is currently at 80% capacity).=C2=A0
=C2=A0 =C2=A0 b. A "Propagation Delay" metric, that is *e= xactly* what John has been discussing. That metric is "modem bit-twidd= ling time, in case the frame has to be somehow morphed for transmission, PL= US RF propagation delay." That number would change if, for instance, t= he modem changes modulation techniques on the link, but would otherwise be = pretty stable.=C2=A0

OK, I'm running for the c= loset to jump into the flame-retardant suit... :-)

Regards,
Stan


On Wed, May 4, 2016 at 9:08 AM, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
=

On 4 May 2016, at 13:38, Dearlove, Christopher (UK) <chris.dearlove@baesystems.= com> wrote:

Was the suggestion to include an emp= ty queuing delay, i.e. it included everything, but in the case where the qu= eue was empty?

Ye= s that is my proposal, or actually my seconding of Stan=E2=80=99s proposal,= assuming I understood Stan correctly.

Regards
John

That sounds like = a sensible approach, assuming it=E2=80=99s reasonably stable.=
=C2=A0

--

Christopher Dearlove=
Senior Principal Engineer
BAE Systems Applied Intelligence Laborator= ies
______________________________________________= ____________________________

T= : =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E:=C2=A0chris.dearlov= e@baesystems.com

BAE Systems Applied Inte= lligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8= HN.
www.baesystems.com/ai

BAE Systems Applied Intelligence Limited
Registered in Eng= land & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford,= Surrey, GU2 7YP

=C2=A0
From:=C2=A0ma= net [mailto:manet-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0John Dowdell
S= ent:=C2=A004 May 2016 12:43
To:=C2=A0MANET IETF
Subject:=C2=A0Re: [manet] DLEP and late= ncy metric
= =C2=A0
=C2=A0
*** W= ARNING ***

This message originates from outside our organisation, either from= an external partner or the internet.
Consider carefully whether you should= click on any links, open any attachments or reply.
For information regarding=C2= =A0Red Flags<= span style=3D"font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(51,57= ,114)">=C2=A0that you can look out for in emails you receive, = click=C2=A0here.
If you feel the email= is suspicious, please follow=C2=A0this process.

***=C2=A0WARNING=C2=A0***<= /strong>
EXTERNAL E= MAIL -- This message originates from outside our organization.
=C2=A0
I know we=E2=80=99re all a bit tied up with various la= st calls but can I ask for adjudication on this point? The current draft is= ambiguous as to whether the latency metric includes the current queuing de= lay, taking account of how full or not the queue is at the sampling instant= , or a notional =E2=80=9Cno traffic" delay (in the same manner as for = the bandwidth metric), and there are polarised views for and against.
=C2=A0
<= /div>
Just that I=E2=80=99m keen to get this one= clarified one way or the other.
=C2=A0
Fo= llowing Stan=E2=80=99s proposal below, can I propose that the Latency Metri= c is measured in absence of traffic, and that an extension metric for Link = Utilisation (which could provide metrics plural) is written up?
=C2=A0
<= div>
Regards
John
= =C2=A0
On 27 Apr 2016, at 07:43, Teco Boot <teco@inf-net.nl> wrote:
<= /div>
=C2=A0

Op 27 apr. 2016, om 01:16 heeft Stan Ratliff <ratliffstan@gmail.com> het volgende geschreven:<= br>
John,

Speaking as a co-author and a DLEP implementer,

= On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
Hi all

A= question has arisen as to whether the Latency metric should include queuei= ng delay in the modem.

It has long been held that the bandwidth metr= ic is measured in the absence of traffic (though the metric descriptions in= 10.14 and 10.15 of Current Data Rate are ambiguous on this point), yet sec= tion 10.16 of -22 states ...

Yes, that's the way my implementati= on went. I don't see a use case for a bandwidth metric that attempts to= take traffic into account, and it seems to me like such a metric could (wo= uld) fluctuate wildly. From my experience, the "interesting statistic&= quot; was always "how fast is the pipe?" Trying to factor traffic= into account can have really weird side-effects - for instance, I remember= a radio implementation that reported a "Current Data Rate" of 0 = on an idle link (because, after all, no traffic was flowing)... that drove = the router nuts, since it saw a "broken" (or nearly broken) link.=



" Latency: A 64-bit unsigned integer, representing the= transmission delay, in microseconds, that a packet encounters as it is tra= nsmitted over the link.=E2=80=9D

=E2=80=A6 which suggests that queui= ng delay should be included.

Much as in the case above, I can't = see a use case for a "Latency" metric *without* queueing delay.

I don't get this. = Above, you suggest traffic is not taken into account. Here, you suggest que= uing delay (caused by traffic?) is taken into account.

I suggest pac= ket handling delay for a single packet on an idle medium is taken into acco= unt. Delay caused by filled up queues is not. Queue depth would be another = metric. Which would fluctuate wildly^^2. And could be a complex composite m= etric when *FQ is used. See RFC 7567 / BCP 197 on what packet forwarding de= vices SHOULD do.

Teco





There are posit= ive and negative connotations; a modem queue that suddenly becomes full mig= ht not have any more data queued to it, or a DLEP-powered routing algorithm= might choose another modem instead, allowing the queue to subside, but tha= t might not be what the system integrator wanted to happen.

And that= would depend on a lot of code that outside the scope of the DLEP spec - sp= ecifically, it depends on how an algorithm actually *deals* with the DLEP m= etrics supplied.

Having said all of that, I can see a possibility fo= r a couple of follow-on metrics for a DLEP extension - the first would be a= "Link Utilization" metric. The other would be a "Propagatio= n delay" metric, based on the physical properties of the transmission = medium.

Just a thought.

Regards,
Stan


_________= ______________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
=C2=A0=

***********= *********************************************************
This email and= any attachments are confidential to the intended
recipient and may also= be privileged. If you are not the intended
recipient please delete it f= rom your system and notify the sender.
You should not copy it or use it = for any purpose nor disclose or
distribute its contents to any other per= son.
*******************************************************************= *



_______________________________= ________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


___________________= ____________________________
manet mailing list
<= span>manet@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/manet">https://www.ietf.org= /mailman/listinfo/manet
--001a1137b5bec976a905320771c8-- From Neil.Viberg@gd-ms.ca Wed May 4 10:21:44 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539D712D7DF for ; Wed, 4 May 2016 10:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F92zmQSW45Be for ; Wed, 4 May 2016 10:21:41 -0700 (PDT) Received: from OTTMGC001.GDCAN.COM (smtp4.gdcanada.com [209.29.4.47]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5888112D751 for ; Wed, 4 May 2016 10:21:02 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5700,7163,8155"; a="3526690" Received: from unknown (HELO gdcanada.com) ([172.16.7.198]) by OTTMGC001.GDCAN.COM with ESMTP/TLS/AES256-SHA; 04 May 2016 13:21:00 -0400 Received: from OTTSVW201.gdcan.com ([fe80::1468:d0f5:99e5:29e0]) by ottsvw198.gdcan.com ([::1]) with mapi id 14.03.0266.001; Wed, 4 May 2016 13:20:59 -0400 From: "Viberg, Neil" To: "ratliffstan@gmail.com" Thread-Topic: Re: [manet] DLEP and latency metric Thread-Index: AdGmJy/3kbY9wQNHRVCz8yuwbvJ7KQ== Date: Wed, 4 May 2016 17:20:58 +0000 Message-ID: <4380A22D88B79C47883D0026E2CD551478723335@ottsvw201.gdcan.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.164.53] x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22300.005 x-tm-as-result: No--61.236400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_4380A22D88B79C47883D0026E2CD551478723335ottsvw201gdcanc_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 04 May 2016 10:47:34 -0700 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and latency metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 17:25:03 -0000 --_000_4380A22D88B79C47883D0026E2CD551478723335ottsvw201gdcanc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stan, I agree with your ideas about latency *if* there is only one priority. If t= here is more than one priority then a single "latency" number doesn't mean = a lot. You'd need one per priority for full characterization. For the time = being I would think a rational approach for a vendor would be to derive lat= ency *without* queueing when multiple priorities are configured. This appro= ach would suggest doing the same for a single priority for consistency but = is not a requirement. An extension for queuing delay that allows for multip= le return values could then be added at which point the latency could logic= ally be tightened to exclude queueing delay if the extension is used. I second your proposal to leave the current latency alone. Cheers, Neil > Date: Wed, 4 May 2016 11:18:54 -0400 > From: Stan Ratliff > To: John Dowdell > Cc: "Dearlove, Christopher \(UK\)" , > MANET IETF > Subject: Re: [manet] DLEP and latency metric > Message-ID: > > Content-Type: text/plain; charset=3D"utf-8" > > All, > > That actually wasn't my proposal. I'll attempt to clarify. First off, the > text from DLEP-22 on Latency, in Section 10.16: > > "The Latency value is reported as transmission delay. The calculation > of latency is implementation dependent. For example, the latency may > be a running average calculated from the internal queuing." > > So, the text doesn't mandate that queuing delay be included, it just list= s > that as an example. That being said, I'm one who doesn't see that a Laten= cy > calculation is all that interesting *UNLESS* you include queuing delay. > Otherwise, to me anyway, it's along the lines of "You know Mr. Router, my > normal bit-twiddling delay + Propagation Delay on this RF link is about > ms. What I'll leave unsaid is how bad things get if/when a queue o= f > traffic exists for said link, but that's OK, isn't it? What's some unknow= n > (unreported) amount of delay between friends?" > > The first calculation (ignoring queuing delay) is more or less "Here's my > *best case* Latency". Add "some fudge-factor" to make it anywhere close t= o > real. > > So, my proposal was: > 1. Leave the bandwidth definition alone, in that it does *not* include > current traffic on the link. It's an indication of "how fast is the pipe"= . > 2. Leave the Latency stuff alone as well - yes, the example includes > queuing delay. But it's only an example; nothing stops a vendor from > implementing Latency *without* queuing delay, although I think that's a b= ad > idea. > 3. Look at the possibility of augmenting the statistics to make everyone > happy. Specifically, add > a. A "Bandwidth Utilization" metric. That way, a router could see > something like "CDRT on the link is 20Mbps, and the link is currently at > 80% capacity). > b. A "Propagation Delay" metric, that is *exactly* what John has been > discussing. That metric is "modem bit-twiddling time, in case the frame h= as > to be somehow morphed for transmission, PLUS RF propagation delay." That > number would change if, for instance, the modem changes modulation > techniques on the link, but would otherwise be pretty stable. > > OK, I'm running for the closet to jump into the flame-retardant suit... := -) > > Regards, > Stan --_000_4380A22D88B79C47883D0026E2CD551478723335ottsvw201gdcanc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stan,

 

I agree with your ideas about latency *if* th= ere is only one priority. If there is more than one priority then a single = “latency” number doesn’t mean a lot. You’d need one= per priority for full characterization. For the time being I would think a rational approach for a vendor would be to derive latency = *without* queueing when multiple priorities are configured. This app= roach would suggest doing the same for a single priority for consistency bu= t is not a requirement. An extension for queuing delay that allows for multiple return values could then be add= ed at which point the latency could logically be tightened to exclude queue= ing delay if the extension is used.

 

I second your proposal to leave the current latency = alone.

Cheers,

Neil

 

> Date: Wed, 4 May 2016 11:18:54 -0400=

> From: Stan Ratliff <ratliffstan@gmail.com>= ;

> To: John Dowdell <john.dowdell.ietf@gmail.co= m>

> Cc: "Dearlove, Christopher \(UK\)" &l= t;chris.dearlove@baesystems.com>,

>        =      MANET IETF <manet@ietf.org>

> Subject: Re: [manet] DLEP and latency metric

> Message-ID:

>        =      <CALtoyon4OU0K0WmZDqW8kdkcQqMyW6_hjqzwyUki95hnK= 5hA=3DA@mail.gmail.com>

> Content-Type: text/plain; charset=3D"utf-8= "

> 

> All,

> 

> That actually wasn't my proposal. I'll attempt = to clarify. First off, the

> text from DLEP-22 on Latency, in Section 10.16:=

> 

> "The Latency value is reported as transmis= sion delay. The calculation

> of latency is implementation dependent. For exa= mple, the latency may

> be a running average calculated from the intern= al queuing."

> 

> So, the text doesn't mandate that queuing delay= be included, it just lists

> that as an example. That being said, I'm one wh= o doesn't see that a Latency

> calculation is all that interesting *UNLESS* yo= u include queuing delay.

> Otherwise, to me anyway, it's along the lines o= f "You know Mr. Router, my

> normal bit-twiddling delay + Propagation De= lay on this RF link is about

> <blah> ms. What I'll leave unsaid is how = bad things get if/when a queue of

> traffic exists for said link, but that's OK, is= n't it? What's some unknown

> (unreported) amount of delay between friends?&q= uot;

> 

> The first calculation (ignoring queuing delay) = is more or less "Here's my

> *best case* Latency". Add "some fudge= -factor" to make it anywhere close to

> real.

> 

> So, my proposal was:

> 1. Leave the bandwidth definition alone, in tha= t it does *not* include

> current traffic on the link. It's an indication= of "how fast is the pipe".

> 2. Leave the Latency stuff alone as well - yes,= the example includes

> queuing delay. But it's only an example; nothin= g stops a vendor from

> implementing Latency *without* queuing delay, a= lthough I think that's a bad

> idea.

> 3. Look at the possibility of augmenting the st= atistics to make everyone

> happy. Specifically, add

>     a. A "Bandwidth Ut= ilization" metric. That way, a router could see

> something like "CDRT on the link is 20Mbps= , and the link is currently at

> 80% capacity).

>     b. A "Propagation = Delay" metric, that is *exactly* what John has been

> discussing. That metric is "modem bit-twid= dling time, in case the frame has

> to be somehow morphed for transmission, PLUS RF= propagation delay." That

> number would change if, for instance, the modem= changes modulation

> techniques on the link, but would otherwise be = pretty stable.

> 

> OK, I'm running for the closet to jump into the= flame-retardant suit... :-)

> 

> Regards,

> Stan

--_000_4380A22D88B79C47883D0026E2CD551478723335ottsvw201gdcanc_-- From nobody Wed May 4 11:05:55 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CE112D147 for ; Wed, 4 May 2016 11:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGyx6e91Ruon for ; Wed, 4 May 2016 11:05:51 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3141512D113 for ; Wed, 4 May 2016 11:05:51 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id g17so108172935wme.1 for ; Wed, 04 May 2016 11:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=tN42MaQF9wxRz9e2GtQxSwBSblhi8nRdT3Dl7josLKY=; b=KTIY+uoVgBGyt5ahFlF4MUy74ESeo9kxaFyVlSaJwzo9un4sae/PTgq0BzJoRV2ibT e4ILg/J5J3H3qimHiB9w49/wXiMRdCrGnxfYY/w5MAsr3Z1CeCamdYz4uogV/Ic1C72g VQ4FyD4trKWPbw4jY35Jt7Yd+sY+/cNK4gUiGlw0ATtbCwCaKpQznQMNUgX6tzalbBks s7irH/mrACTOJxSMi4ODSbNzEknQujx7bg1Yi0IWLiolQMaVZL8tNKrwzt+ITjtSFKlb O5//UMAHhUSArpRZRqWVrKJr+JhLIKvrQarH+rk63m3MUPIfidzaQtj0eZJrI3SwRc9E YvpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=tN42MaQF9wxRz9e2GtQxSwBSblhi8nRdT3Dl7josLKY=; b=SqM+3gsV4R/qW9I+KqGHsA1qoXrJTmr8zqg+AtWKTe2Xxnxe+Qb/6nJRdhnqQMsQtf J6/uQwTaCvSJcKOsc3O1dXSb6LgyYAMqNHEynsCVnFZmskHS8GElAADhF37mIV1+5iEA JWOzs3HrRsDnU2CO8H3DGjzgsubkZjMBE/IRBBeLqoAjRubCwxZkzOjTnT/erQvT6Fir 8Yn6F2SjR8pCx0g+3AC3Rbii0+/HDR36bW53qZMMxudTQgbpl0sQqrX0rp6Uc+xAhF+W 2ignWcJdk2EuOuSM1O95Zza/rolA/QuPElbdJAow5e9EJ/5znac7AS2uAgz9H+xBx7hP Xn3g== X-Gm-Message-State: AOPr4FUSXUFGxO+rXWApodrruLaTNAYrE6Jvnkwz4RqXRM9L6Limba7nyE5/AC47mqy96g== X-Received: by 10.194.158.226 with SMTP id wx2mr9601153wjb.91.1462385149761; Wed, 04 May 2016 11:05:49 -0700 (PDT) Received: from johns-mbp-4.home (host86-155-246-227.range86-155.btcentralplus.com. [86.155.246.227]) by smtp.gmail.com with ESMTPSA id i194sm6260716wmf.6.2016.05.04.11.05.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 May 2016 11:05:48 -0700 (PDT) From: John Dowdell Content-Type: multipart/alternative; boundary="Apple-Mail=_DE4AA914-4BD2-42DA-9E32-A3EA26FD48F1" Message-Id: <9BF02D0F-1458-47C7-9A29-4A121A3E2F75@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Wed, 4 May 2016 19:05:47 +0100 References: <4380A22D88B79C47883D0026E2CD551478723335@ottsvw201.gdcan.com> To: "Viberg, Neil" , "manet@ietf.org" , Stan Ratliff In-Reply-To: <4380A22D88B79C47883D0026E2CD551478723335@ottsvw201.gdcan.com> X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [manet] DLEP and latency metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 18:05:54 -0000 --Apple-Mail=_DE4AA914-4BD2-42DA-9E32-A3EA26FD48F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 May 2016, at 18:20, Viberg, Neil wrote: >=20 > Stan, > =20 > I agree with your ideas about latency *if* there is only one priority. = If there is more than one priority then a single =E2=80=9Clatency=E2=80=9D= number doesn=E2=80=99t mean a lot. You=E2=80=99d need one per priority = for full characterization. For the time being I would think a rational = approach for a vendor would be to derive latency *without* queueing when = multiple priorities are configured. This approach would suggest doing = the same for a single priority for consistency but is not a requirement. = An extension for queuing delay that allows for multiple return values = could then be added at which point the latency could logically be = tightened to exclude queueing delay if the extension is used. There are flow control and VLAN extensions written up in individual = drafts. Check datatracker.ietf.org and search for DLEP. It therefore = makes sense to include metrics to do with priority either in those = drafts or in other extension drafts. Regards John > =20 > I second your proposal to leave the current latency alone. > Cheers, > Neil > =20 > > Date: Wed, 4 May 2016 11:18:54 -0400 > > From: Stan Ratliff > > > To: John Dowdell > > > Cc: "Dearlove, Christopher \(UK\)" >, > > MANET IETF > > > Subject: Re: [manet] DLEP and latency metric > > Message-ID: > > = > > > Content-Type: text/plain; charset=3D"utf-8" > >=20 > > All, > >=20 > > That actually wasn't my proposal. I'll attempt to clarify. First = off, the > > text from DLEP-22 on Latency, in Section 10.16: > >=20 > > "The Latency value is reported as transmission delay. The = calculation > > of latency is implementation dependent. For example, the latency may > > be a running average calculated from the internal queuing." > >=20 > > So, the text doesn't mandate that queuing delay be included, it just = lists > > that as an example. That being said, I'm one who doesn't see that a = Latency > > calculation is all that interesting *UNLESS* you include queuing = delay. > > Otherwise, to me anyway, it's along the lines of "You know Mr. = Router, my > > normal bit-twiddling delay + Propagation Delay on this RF link is = about > > ms. What I'll leave unsaid is how bad things get if/when a = queue of > > traffic exists for said link, but that's OK, isn't it? What's some = unknown > > (unreported) amount of delay between friends?" > >=20 > > The first calculation (ignoring queuing delay) is more or less = "Here's my > > *best case* Latency". Add "some fudge-factor" to make it anywhere = close to > > real. > >=20 > > So, my proposal was: > > 1. Leave the bandwidth definition alone, in that it does *not* = include > > current traffic on the link. It's an indication of "how fast is the = pipe". > > 2. Leave the Latency stuff alone as well - yes, the example includes > > queuing delay. But it's only an example; nothing stops a vendor from > > implementing Latency *without* queuing delay, although I think = that's a bad > > idea. > > 3. Look at the possibility of augmenting the statistics to make = everyone > > happy. Specifically, add > > a. A "Bandwidth Utilization" metric. That way, a router could = see > > something like "CDRT on the link is 20Mbps, and the link is = currently at > > 80% capacity). > > b. A "Propagation Delay" metric, that is *exactly* what John has = been > > discussing. That metric is "modem bit-twiddling time, in case the = frame has > > to be somehow morphed for transmission, PLUS RF propagation delay." = That > > number would change if, for instance, the modem changes modulation > > techniques on the link, but would otherwise be pretty stable. > >=20 > > OK, I'm running for the closet to jump into the flame-retardant = suit... :-) > >=20 > > Regards, > > Stan --Apple-Mail=_DE4AA914-4BD2-42DA-9E32-A3EA26FD48F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 May 2016, at 18:20, Viberg, Neil <Neil.Viberg@gd-ms.ca> wrote:

Stan,
 
I agree = with your ideas about latency *if* there is only one = priority. If there is more than one priority then a single =E2=80=9Clatenc= y=E2=80=9D number doesn=E2=80=99t mean a lot. You=E2=80=99d need one per = priority for full characterization. For the time being I would think a = rational approach for a vendor would be to derive latency *without* queueing when multiple priorities are = configured. This approach would suggest doing the same for a single = priority for consistency but is not a requirement. An extension for = queuing delay that allows for multiple return values could then be added = at which point the latency could logically be tightened to exclude = queueing delay if the extension is = used.

There are = flow control and VLAN extensions written up in individual drafts. Check = datatracker.ietf.org and search for DLEP. It therefore = makes sense to include metrics to do with priority either in those = drafts or in other extension drafts.

Regards
John
 
I second your proposal to leave the current latency = alone.
Cheers,
Neil
 
> Date: Wed, 4 May 2016 11:18:54 -0400
> = From: Stan Ratliff <ratliffstan@gmail.com>
> To: John Dowdell <john.dowdell.ietf@gmail.com>
> Cc: = "Dearlove, Christopher \(UK\)" <chris.dearlove@baesystems.com>,
>          = ;   MANET IETF <manet@ietf.org>
> Subject: Re: [manet] DLEP and = latency metric
> Message-ID:
> Content-Type: text/plain; charset=3D"utf-8"
> 
> = All,
> 
> That = actually wasn't my proposal. I'll attempt to clarify. First off, the
> text = from DLEP-22 on Latency, in Section 10.16:
> 
> "The = Latency value is reported as transmission delay. The calculation
> of = latency is implementation dependent. For example, the latency may
> be a = running average calculated from the internal queuing."
> 
> So, = the text doesn't mandate that queuing delay be included, it just = lists
> that = as an example. That being said, I'm one who doesn't see that a = Latency
> calculation is all that interesting *UNLESS* you include = queuing delay.
> Otherwise, to me anyway, it's along the lines of "You = know Mr. Router, my
> normal bit-twiddling delay + Propagation Delay on this = RF link is about
> <blah> ms. What I'll leave unsaid is how bad = things get if/when a queue of
> traffic exists for said link, but = that's OK, isn't it? What's some unknown
> (unreported) amount of delay = between friends?"
> 
> The first calculation (ignoring queuing delay) is more = or less "Here's my
> *best case* Latency". Add "some fudge-factor" to make it = anywhere close to
> real.
> 
> So, my proposal was:
> 1. Leave the bandwidth definition = alone, in that it does *not* include
> current traffic on the link. It's = an indication of "how fast is the pipe".
> 2. Leave the Latency stuff alone = as well - yes, the example includes
> queuing delay. But it's only an = example; nothing stops a vendor from
> implementing Latency *without* = queuing delay, although I think that's a bad
> = idea.
> 3. = Look at the possibility of augmenting the statistics to make = everyone
> happy. Specifically, add
>     a. A = "Bandwidth Utilization" metric. That way, a router could see
> = something like "CDRT on the link is 20Mbps, and the link is currently = at
> 80% = capacity).
>     b. A "Propagation Delay" metric, = that is *exactly* what John has been
> discussing. That metric is "modem = bit-twiddling time, in case the frame has
> to be somehow morphed for = transmission, PLUS RF propagation delay." That
> = number would change if, for instance, the modem changes modulation
> = techniques on the link, but would otherwise be pretty stable.
> 
> OK, = I'm running for the closet to jump into the flame-retardant suit... = :-)
> 
> = Regards,
> Stan

= --Apple-Mail=_DE4AA914-4BD2-42DA-9E32-A3EA26FD48F1-- From nobody Wed May 4 12:03:43 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B8612B04C for ; Wed, 4 May 2016 12:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_QQVmijaNtR for ; Wed, 4 May 2016 12:03:34 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71DD12D1E4 for ; Wed, 4 May 2016 12:03:28 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id d62so63787446iof.2 for ; Wed, 04 May 2016 12:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Yx13uQ/LfQ164j+ugms/bNxVdcSfaJidf65uiPhYMs8=; b=gqhe9vXiTZT4Yz0NPzeVGyAMtV4oJzU0GKcbXMrQK9x9PtKj820gZVWkFJvvQTv/ku sQxBbicG6GsMxR44CvgkqxSkSMwd/FLm5vb8oXz4wVNIpZnpDwKaJMw1/qvO79kClF/F aZTOqN70scDbOc1kUcKJP20+mpTfY6l4Bjg+Bphf3yyZTdsUnjopQKWr3fq41lQdruSw Gell4bNXehlLR5D6Wib9x8ixiCrfABJzmr/Q8R+uAQo//bRXAz07odZ9ra8tMYnFODEr 3GVAXpGP/GWu9I9pzArYhIOgeZAzIWRU1QNJYEK2L2cxb11N4Pfg385LPdAiFHeeETh4 oMRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Yx13uQ/LfQ164j+ugms/bNxVdcSfaJidf65uiPhYMs8=; b=dn/g3IfKIuMxBnRBIA0THR1l1c4tCJxduS3sTXfk+7SQRKubazmTLka/kPiALAWKPD PbpUjJW3j66WVjvZDECUy1HTE9sBbPhap5jgOQlqC+0LACuEyVmS9J6HlKjhaZewFXn2 I/yT/+FGnv1CETflqfQ9KPmUtEXHutrDONIacj/oHQX/cBCUhQrAPm9XlWY7xSlQ4vti M+yS9f3RJmKFyslh2NoJG0o23LN/4QbFX4+ckiZSkGvJGAUCX3GUn+6xbL/Q2YOtYn/g XxXu2nTop+ICVrBQM2uDhrP0cXM6+qx35aRzB7BqOkrsDkS2a3es0tAv0KgxDfRvgcnZ JXsg== X-Gm-Message-State: AOPr4FWEIlRg/hX+wtgNjkhgtmHVN1xWTwiI4/dkEOed76FpqOXiXUhYFwR4eFjFJ/fybkgFwSros4mM0LK7cw== MIME-Version: 1.0 X-Received: by 10.107.173.69 with SMTP id w66mr13554193ioe.182.1462388607740; Wed, 04 May 2016 12:03:27 -0700 (PDT) Received: by 10.79.72.68 with HTTP; Wed, 4 May 2016 12:03:27 -0700 (PDT) In-Reply-To: <-4425690961467974600@unknownmsgid> References: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com> <2DC54CCE-46BE-48D0-9497-52D31DCB5B40@inf-net.nl> <8E293203-E383-4E27-A3B2-511142EE3FD4@gmail.com> <-4425690961467974600@unknownmsgid> Date: Wed, 4 May 2016 15:03:27 -0400 Message-ID: From: Stan Ratliff To: "A .Riley Eller" Content-Type: multipart/alternative; boundary=001a114464f47d2677053208e16e Archived-At: Cc: "Dearlove, Christopher \(UK\)" , MANET IETF Subject: Re: [manet] DLEP and latency metric X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 19:03:42 -0000 --001a114464f47d2677053208e16e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! Response inline - Speaking as a DLEP co-author, and WG participant: On Wed, May 4, 2016 at 1:20 PM, A .Riley Eller wrote: > Modem-based priority queuing is a common feature with performance > characteristics that may elude the ability of a router to make accurate > predictions of behavior or performance. In the case of 802.11, as an > example of real-world complex interactions, higher priority traffic has a > significantly lower channel acquisition time (and therefore a higher fram= e > capacity) than bulk traffic. Protocol data unit aggregation, in turn, may > or may not "piggyback" lower priority packets into a frame being treated = as > high priority. It makes great sense to report utilization and queuing del= ay > on a per-priority basis. > > In a previous heterogeneous MANET exercise, my team made very effective > use of reporting utilization and queuing delay on a per-ToS basis plus a > single, total link capacity. > > Modems lacking priority queues could report aggregates within the highest > priority class. Routers lacking awareness of priority could sum the > capacities and average, or select the maximum from among, the latencies. > > I could try my hand at editing DLEP-22 if this idea appeals to the group. > I think, as John and Neil Viberg mentioned in another email, this is a good subject for a DLEP extension, and I'd be really interested in being involved. But process-wise, I don't think modifying DLEP-22 is the way to go. I believe this is a big enough change that we'd have to pull DLEP back from "Request to Publish" status, and I don't think it's as straightforward as it seems at first glance - I think there are some subtleties that will need to be discussed to make sure the extension applies to a broad set of modems capable of multiple priorities. So, I'm in agreement with Neil - I think we should leave the existing draft as-is, and approach this in a DLEP Extension. Other thoughts? Regards, Stan > > > > On May 4, 2016, at 8:21 AM, Stan Ratliff wrote: > > All, > > That actually wasn't my proposal. I'll attempt to clarify. First off, the > text from DLEP-22 on Latency, in Section 10.16: > > "The Latency value is reported as transmission delay. The calculation > of latency is implementation dependent. For example, the latency may > be a running average calculated from the internal queuing." > > So, the text doesn't mandate that queuing delay be included, it just list= s > that as an example. That being said, I'm one who doesn't see that a Laten= cy > calculation is all that interesting *UNLESS* you include queuing delay. > Otherwise, to me anyway, it's along the lines of "You know Mr. Router, my > normal bit-twiddling delay + Propagation Delay on this RF link is about > ms. What I'll leave unsaid is how bad things get if/when a queue o= f > traffic exists for said link, but that's OK, isn't it? What's some unknow= n > (unreported) amount of delay between friends?" > > The first calculation (ignoring queuing delay) is more or less "Here's my > *best case* Latency". Add "some fudge-factor" to make it anywhere close t= o > real. > > So, my proposal was: > 1. Leave the bandwidth definition alone, in that it does *not* include > current traffic on the link. It's an indication of "how fast is the pipe"= . > 2. Leave the Latency stuff alone as well - yes, the example includes > queuing delay. But it's only an example; nothing stops a vendor from > implementing Latency *without* queuing delay, although I think that's a b= ad > idea. > 3. Look at the possibility of augmenting the statistics to make everyone > happy. Specifically, add > a. A "Bandwidth Utilization" metric. That way, a router could see > something like "CDRT on the link is 20Mbps, and the link is currently at > 80% capacity). > b. A "Propagation Delay" metric, that is *exactly* what John has been > discussing. That metric is "modem bit-twiddling time, in case the frame h= as > to be somehow morphed for transmission, PLUS RF propagation delay." That > number would change if, for instance, the modem changes modulation > techniques on the link, but would otherwise be pretty stable. > > OK, I'm running for the closet to jump into the flame-retardant suit... := -) > > Regards, > Stan > > > On Wed, May 4, 2016 at 9:08 AM, John Dowdell > wrote: > >> >> On 4 May 2016, at 13:38, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> wrote: >> >> Was the suggestion to include an empty queuing delay, i.e. it included >> everything, but in the case where the queue was empty? >> >> >> Yes that is my proposal, or actually my seconding of Stan=E2=80=99s prop= osal, >> assuming I understood Stan correctly. >> >> Regards >> John >> >> That sounds like a sensible approach, assuming it=E2=80=99s reasonably s= table. >> >> >> *--* >> >> >> >> >> *Christopher DearloveSenior Principal EngineerBAE Systems Applied >> Intelligence Laboratories* >> >> *_______________________________________________________________________= ___* >> *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com >> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great >> Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >> >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >> >> *From:* manet [mailto:manet-bounces@ietf.org ] *= On >> Behalf Of *John Dowdell >> *Sent:* 04 May 2016 12:43 >> *To:* MANET IETF >> *Subject:* Re: [manet] DLEP and latency metric >> >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.* >> >> *Consider carefully whether you should click on any links, open any >> attachments or reply.For information regarding **Red Flags** that you >> can look out for in emails you receive, click here >> .* >> *If you feel the email is suspicious, please follow this process >> .* >> **** **WARNING ****** >> EXTERNAL EMAIL -- This message originates from outside our organization. >> >> I know we=E2=80=99re all a bit tied up with various last calls but can I= ask for >> adjudication on this point? The current draft is ambiguous as to whether >> the latency metric includes the current queuing delay, taking account of >> how full or not the queue is at the sampling instant, or a notional =E2= =80=9Cno >> traffic" delay (in the same manner as for the bandwidth metric), and the= re >> are polarised views for and against. >> >> Just that I=E2=80=99m keen to get this one clarified one way or the othe= r. >> >> Following Stan=E2=80=99s proposal below, can I propose that the Latency = Metric is >> measured in absence of traffic, and that an extension metric for Link >> Utilisation (which could provide metrics plural) is written up? >> >> Regards >> John >> >> >> On 27 Apr 2016, at 07:43, Teco Boot wrote: >> >> >> >> Op 27 apr. 2016, om 01:16 heeft Stan Ratliff het >> volgende geschreven: >> >> John, >> >> Speaking as a co-author and a DLEP implementer, >> >> On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell < >> john.dowdell.ietf@gmail.com> wrote: >> Hi all >> >> A question has arisen as to whether the Latency metric should include >> queueing delay in the modem. >> >> It has long been held that the bandwidth metric is measured in the >> absence of traffic (though the metric descriptions in 10.14 and 10.15 of >> Current Data Rate are ambiguous on this point), yet section 10.16 of -22 >> states ... >> >> Yes, that's the way my implementation went. I don't see a use case for a >> bandwidth metric that attempts to take traffic into account, and it seem= s >> to me like such a metric could (would) fluctuate wildly. From my >> experience, the "interesting statistic" was always "how fast is the pipe= ?" >> Trying to factor traffic into account can have really weird side-effects= - >> for instance, I remember a radio implementation that reported a "Current >> Data Rate" of 0 on an idle link (because, after all, no traffic was >> flowing)... that drove the router nuts, since it saw a "broken" (or near= ly >> broken) link. >> >> >> >> " Latency: A 64-bit unsigned integer, representing the transmission >> delay, in microseconds, that a packet encounters as it is transmitted ov= er >> the link.=E2=80=9D >> >> =E2=80=A6 which suggests that queuing delay should be included. >> >> Much as in the case above, I can't see a use case for a "Latency" metric >> *without* queueing delay. >> >> >> I don't get this. Above, you suggest traffic is not taken into account. >> Here, you suggest queuing delay (caused by traffic?) is taken into accou= nt. >> >> I suggest packet handling delay for a single packet on an idle medium is >> taken into account. Delay caused by filled up queues is not. Queue depth >> would be another metric. Which would fluctuate wildly^^2. And could be a >> complex composite metric when *FQ is used. See RFC 7567 / BCP 197 on wha= t >> packet forwarding devices SHOULD do. >> >> Teco >> >> >> >> >> >> There are positive and negative connotations; a modem queue that suddenl= y >> becomes full might not have any more data queued to it, or a DLEP-powere= d >> routing algorithm might choose another modem instead, allowing the queue= to >> subside, but that might not be what the system integrator wanted to happ= en. >> >> And that would depend on a lot of code that outside the scope of the DLE= P >> spec - specifically, it depends on how an algorithm actually *deals* wit= h >> the DLEP metrics supplied. >> >> Having said all of that, I can see a possibility for a couple of >> follow-on metrics for a DLEP extension - the first would be a "Link >> Utilization" metric. The other would be a "Propagation delay" metric, ba= sed >> on the physical properties of the transmission medium. >> >> Just a thought. >> >> Regards, >> Stan >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a114464f47d2677053208e16e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!=C2=A0

Response inline - Speaking as= a DLEP co-author, and WG participant:

=
On Wed, May 4, 2016 at 1:20 PM, A .Riley Eller <= span dir=3D"ltr"><reller@cococorp.com> wrote:
Modem-ba= sed priority queuing is a common feature with performance characteristics t= hat may elude the ability of a router to make accurate predictions of behav= ior or performance. In the case of 802.11, as an example of real-world comp= lex interactions, higher priority traffic has a significantly lower channel= acquisition time (and therefore a higher frame capacity) than bulk traffic= . Protocol data unit aggregation, in turn, may or may not "piggyback&q= uot; lower priority packets into a frame being treated as high priority. It= makes great sense to report utilization and queuing delay on a per-priorit= y basis.

In a previous heterogeneous MANET exercis= e, my team made very effective use of reporting utilization and queuing del= ay on a per-ToS basis plus a single, total link capacity.=C2=A0
<= br>
Modems lacking priority queues could report aggregates within= the highest priority class. Routers lacking awareness of priority could su= m the capacities and average, or select the maximum from among, the latenci= es.

I could try my hand at editing DLEP-22 if this= idea appeals to the group.

I think, as John and Neil Viberg mentioned in another email, this is a g= ood subject for a DLEP extension, and I'd be really interested in being= involved. But process-wise, I don't think modifying DLEP-22 is the way= to go. I believe this is a big enough change that we'd have to pull DL= EP back from "Request to Publish" status, and I don't think i= t's as straightforward as it seems at first glance - I think there are = some subtleties that will need to be discussed to make sure the extension a= pplies to a broad set of modems capable of multiple priorities.=C2=A0
=

So, I'm in agreement with Neil - I think we should = leave the existing draft as-is, and approach this in a DLEP Extension.=C2= =A0

Other thoughts?=C2=A0

Regards,
Stan
=C2=A0



On May 4, = 2016, at 8:21 AM, Stan Ratliff <ratliffstan@gmail.com> wrote:

All,=C2=A0

Tha= t actually wasn't my proposal. I'll attempt to clarify. First off, = the text from DLEP-22 on Latency, in Section 10.16:=C2=A0

"The Latency value is reported as transmission delay. The cal= culation
of latency is implementation dependent. For example, the= latency may
be a running average calculated from the internal qu= euing."

So, the text doesn't mandate that= queuing delay be included, it just lists that as an example. That being sa= id, I'm one who doesn't see that a Latency calculation is all that = interesting *UNLESS* you include queuing delay. Otherwise, to me anyway, it= 's along the lines of "You know Mr. Router, my normal bit-twiddlin= g delay + Propagation Delay on this RF link is about <blah> ms. What = I'll leave unsaid is how bad things get if/when a queue of traffic exis= ts for said link, but that's OK, isn't it? What's some unknown = (unreported) amount of delay between friends?"

The first calculation (ignoring queuing delay) is more or less "Here= 's my *best case* Latency". Add "some fudge-factor" to m= ake it anywhere close to real.=C2=A0

So, my propos= al was:=C2=A0
1. Leave the bandwidth definition alone, in that it= does *not* include current traffic on the link. It's an indication of = "how fast is the pipe".=C2=A0
2. Leave the Latency stuf= f alone as well - yes, the example includes queuing delay. But it's onl= y an example; nothing stops a vendor from implementing Latency *without* qu= euing delay, although I think that's a bad idea.=C2=A0
3. Loo= k at the possibility of augmenting the statistics to make everyone happy. S= pecifically, add=C2=A0
=C2=A0 =C2=A0 a. A "Bandwidth Utiliza= tion" metric. That way, a router could see something like "CDRT o= n the link is 20Mbps, and the link is currently at 80% capacity).=C2=A0
=C2=A0 =C2=A0 b. A "Propagation Delay" metric, that is *ex= actly* what John has been discussing. That metric is "modem bit-twiddl= ing time, in case the frame has to be somehow morphed for transmission, PLU= S RF propagation delay." That number would change if, for instance, th= e modem changes modulation techniques on the link, but would otherwise be p= retty stable.=C2=A0

OK, I'm running for the cl= oset to jump into the flame-retardant suit... :-)

= Regards,
Stan


On Wed, May 4, 2016 at 9:08 AM, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
=

On 4 May 2016, at 13:38, Dearlove, Christopher (UK) <chris.dearlove@baesystems.= com> wrote:

Was the suggestion to include an emp= ty queuing delay, i.e. it included everything, but in the case where the qu= eue was empty?

Ye= s that is my proposal, or actually my seconding of Stan=E2=80=99s proposal,= assuming I understood Stan correctly.

Regards
John

That sounds like = a sensible approach, assuming it=E2=80=99s reasonably stable.=
=C2=A0

--

Christopher Dearlove=
Senior Principal Engineer
BAE Systems Applied Intelligence Laborator= ies
______________________________________________= ____________________________

T= : =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E:=C2=A0chris.dearlov= e@baesystems.com

BAE Systems Applied Inte= lligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8= HN.
www.baesystems.com/ai

BAE Systems Applied Intelligence Limited
Registered in Eng= land & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford,= Surrey, GU2 7YP

=C2=A0
From:=C2=A0ma= net [mailto:manet-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0John Dowdell
S= ent:=C2=A004 May 2016 12:43
To:=C2=A0MANET IETF
Subject:=C2=A0Re: [manet] DLEP and late= ncy metric
= =C2=A0
=C2=A0
*** W= ARNING ***

This message originates from outside our organisation, either from= an external partner or the internet.
Consider carefully whether you should= click on any links, open any attachments or reply.
For information regarding=C2= =A0Red Flags<= span style=3D"font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(51,57= ,114)">=C2=A0that you can look out for in emails you receive, = click=C2=A0here.
If you feel the email= is suspicious, please follow=C2=A0this process.

***=C2=A0WARNING=C2=A0***<= /strong>
EXTERNAL E= MAIL -- This message originates from outside our organization.
=C2=A0
I know we=E2=80=99re all a bit tied up with various la= st calls but can I ask for adjudication on this point? The current draft is= ambiguous as to whether the latency metric includes the current queuing de= lay, taking account of how full or not the queue is at the sampling instant= , or a notional =E2=80=9Cno traffic" delay (in the same manner as for = the bandwidth metric), and there are polarised views for and against.
=C2=A0
<= /div>
Just that I=E2=80=99m keen to get this one= clarified one way or the other.
=C2=A0
Fo= llowing Stan=E2=80=99s proposal below, can I propose that the Latency Metri= c is measured in absence of traffic, and that an extension metric for Link = Utilisation (which could provide metrics plural) is written up?
=C2=A0
<= div>
Regards
John
= =C2=A0
On 27 Apr 2016, at 07:43, Teco Boot <teco@inf-net.nl> wrote:
<= /div>
=C2=A0

Op 27 apr. 2016, om 01:16 heeft Stan Ratliff <ratliffstan@gmail.com> het volgende geschreven:<= br>
John,

Speaking as a co-author and a DLEP implementer,

= On Tue, Apr 26, 2016 at 6:06 PM, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
Hi all

A= question has arisen as to whether the Latency metric should include queuei= ng delay in the modem.

It has long been held that the bandwidth metr= ic is measured in the absence of traffic (though the metric descriptions in= 10.14 and 10.15 of Current Data Rate are ambiguous on this point), yet sec= tion 10.16 of -22 states ...

Yes, that's the way my implementati= on went. I don't see a use case for a bandwidth metric that attempts to= take traffic into account, and it seems to me like such a metric could (wo= uld) fluctuate wildly. From my experience, the "interesting statistic&= quot; was always "how fast is the pipe?" Trying to factor traffic= into account can have really weird side-effects - for instance, I remember= a radio implementation that reported a "Current Data Rate" of 0 = on an idle link (because, after all, no traffic was flowing)... that drove = the router nuts, since it saw a "broken" (or nearly broken) link.=



" Latency: A 64-bit unsigned integer, representing the= transmission delay, in microseconds, that a packet encounters as it is tra= nsmitted over the link.=E2=80=9D

=E2=80=A6 which suggests that queui= ng delay should be included.

Much as in the case above, I can't = see a use case for a "Latency" metric *without* queueing delay.

I don't get this. = Above, you suggest traffic is not taken into account. Here, you suggest que= uing delay (caused by traffic?) is taken into account.

I suggest pac= ket handling delay for a single packet on an idle medium is taken into acco= unt. Delay caused by filled up queues is not. Queue depth would be another = metric. Which would fluctuate wildly^^2. And could be a complex composite m= etric when *FQ is used. See RFC 7567 / BCP 197 on what packet forwarding de= vices SHOULD do.

Teco





There are posit= ive and negative connotations; a modem queue that suddenly becomes full mig= ht not have any more data queued to it, or a DLEP-powered routing algorithm= might choose another modem instead, allowing the queue to subside, but tha= t might not be what the system integrator wanted to happen.

And that= would depend on a lot of code that outside the scope of the DLEP spec - sp= ecifically, it depends on how an algorithm actually *deals* with the DLEP m= etrics supplied.

Having said all of that, I can see a possibility fo= r a couple of follow-on metrics for a DLEP extension - the first would be a= "Link Utilization" metric. The other would be a "Propagatio= n delay" metric, based on the physical properties of the transmission = medium.

Just a thought.

Regards,
Stan


_________= ______________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
=C2=A0=

***********= *********************************************************
This email and= any attachments are confidential to the intended
recipient and may also= be privileged. If you are not the intended
recipient please delete it f= rom your system and notify the sender.
You should not copy it or use it = for any purpose nor disclose or
distribute its contents to any other per= son.
*******************************************************************= *



_______________________________= ________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


___________________= ____________________________
manet mailing list
<= span>manet@ietf.org=
https://www.ietf.org/mailman/listinfo/manet
<= /div>

--001a114464f47d2677053208e16e-- From nobody Wed May 4 19:55:29 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE1812D1A4 for ; Wed, 4 May 2016 19:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3rRyB2xBeeI for ; Wed, 4 May 2016 19:55:26 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE68212D18B for ; Wed, 4 May 2016 19:55:25 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id c189so10699435vkb.2 for ; Wed, 04 May 2016 19:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AOUPxuY+ztWfe7DQijGQRtygDUbhDL722B+iYI/x0TM=; b=r81E9GJw6iCln9OuVHnxpoN8JWcr0AJwo7fh/Ob0R7m8jYFAPyt6sviwgWsScAnk4d 2Yi+rHQxXsZITHobCSoLR7s1dlavUmLd1qqxTIg+mDDQ0WDahKt47FtbLu5I93w/yLgg EGUz6NClfi8WC6mpmvpeRaG7gIbnmkAucnHNk1Efaek2pckyITimvSyOWT3M9yGDBT15 5dxCNk81hGK+wFg3TbetfRkzzGzI3yv+3BEUQL7d68PDcNlOM9uD9Nv/7W6P6S3FlDrb 7rVjSQTnkydmt/g2b0vcGTl3mZl/A/+szLnEcIqbL5CqipdrGX/hdyWfuHH39IPbo8At s6hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AOUPxuY+ztWfe7DQijGQRtygDUbhDL722B+iYI/x0TM=; b=Mc1Vvz5QFdJoQXWTw3i+1VL7IkQnEvpu5bs61o1AhY3pwjbFV7dUEFLcvujhIR/1v4 6l2Wd0B2SpQUp2lE1bQyjEQtT6Sa0GuTQs59YuvhJjryVFT40hJ8B0c1Ya1Wkyukc5bV Ovq77kTqC5i7/TEZCuwCoOxSPAoxrvRcdnCdT5TLJeKtSHHHkPM6OSdaPh3UL6kgrTAt WFKWESdWYWDtSPN+TwgcgCDoAxBx3BIOQje9PdjOKp+UDZ58TbHezeKKRpn9Wa9K7jVJ 8NW/uTm1fsNaIr2mgOIG5TRnC/keRrpTtT7dBYVKJJGnKO9MnjYjaNelagobv6n3H4sE T/1A== X-Gm-Message-State: AOPr4FUuPC5ZAJQridZM6rnT5rZGaMWAUz9sa9fBIA03gHuzo0OByJfN0kC2wNNAJap7rGjnJym861aS8khK2Q== MIME-Version: 1.0 X-Received: by 10.31.5.211 with SMTP id 202mr977868vkf.12.1462416924876; Wed, 04 May 2016 19:55:24 -0700 (PDT) Received: by 10.176.4.104 with HTTP; Wed, 4 May 2016 19:55:24 -0700 (PDT) In-Reply-To: References: <20160504170444.8256.99788.idtracker@ietfa.amsl.com> Date: Wed, 4 May 2016 22:55:24 -0400 Message-ID: From: Justin Dean To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a1143ee8852276b05320f7937 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 02:55:27 -0000 --001a1143ee8852276b05320f7937 Content-Type: text/plain; charset=UTF-8 Ack. I'll talk with Stan ASAP and keep things moving. Justin On Wed, May 4, 2016 at 1:06 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > This includes all of the issues I listed in my previous email of comments > made at WGLC. > > The authors request starting all the post-WGLC things to do. > > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > __________________________________________________________________________ > > --001a1143ee8852276b05320f7937 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ack. I'll talk with Stan ASAP and keep things mov= ing.

Justin

On Wed, May 4, 2016 at 1:06 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
This includes all of the issues I listed in my previous= email of comments made at WGLC.

The authors request starting all the post-WGLC things to do.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________<= br>
--001a1143ee8852276b05320f7937-- From nobody Wed May 4 20:49:12 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFE712B05F for ; Wed, 4 May 2016 20:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBA8ESMuEDRd for ; Wed, 4 May 2016 20:49:09 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1181C12B01C for ; Wed, 4 May 2016 20:49:08 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id r16so11695173vkf.3 for ; Wed, 04 May 2016 20:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=JdDCqcLlUjW+POnvb9Qsy97jco0vd3/p+DUoZ3annkk=; b=wT0ls2+4wxFpDyQmmfgUxQz5Ncfd6FG29pROKn7miZODue+lJh+A/xsSD2OoeX+WKv ahNK/fc7D047LpTOIjby0J/kfmbvZPP7+0x0qPxUZe/NLC8c3bA6tsWlvSuY1DoTF44F Jnq+UtfzhohIUN4aZKNF9T1NZybsWadaVHEeTnM5MwUhgeed+K6v1o2lBgZaUdeGDnxD gxgoIqSn8p2LydU6Hqh7ZJVNA2+MfAmtPIsg0ZdFOjES4wyokzJOtuIziftgBOm8E/iD BrreDB2tD/a75BzCIQBxnoNSvo6ysuqEB/4iSPWA4FvsQyArXX/oZX4UzlL/Cq8+ZvYG +n2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=JdDCqcLlUjW+POnvb9Qsy97jco0vd3/p+DUoZ3annkk=; b=dMUI9vXxSlTeQSY26LwdUSRI+w4PQhzEPCbzHwPSK+w2UGBRUElwRcNec8G/OYrVyi g6pE0lPRLoG0FVceDtmxXTCDUv6wqRVY8/6UQqi8AbKIZopCKRkkdwzkQB5GX12B4FTG NNoFVhqKo1Hb3xS9bAejx8tYPV+QjjOk/acr/Vok82i0EQ2agaoh4XuSltWCfVvIvnSt 1xlLYO7FrBIm0crDivh7me1atZL1wHPlAs8PLd9JfJLUW3AY+VteQvFPPsoxrX06gWrY AdPy7sQYrU+aOoXvHr9Eh+YL19t6oC2jlYFkrVKlQXyJCfuZxM5ghbMKfL8syNbGZlg0 TeEA== X-Gm-Message-State: AOPr4FUBea+51wrgMAR4+/cbhDVjIbNwbH6MoSCg3KLyqzdfzpzcjQCkDRXFX/bdLbD9FcOyMkIvzanGhH+6Cw== MIME-Version: 1.0 X-Received: by 10.176.3.176 with SMTP id 45mr8295050uau.60.1462420147193; Wed, 04 May 2016 20:49:07 -0700 (PDT) Received: by 10.176.4.104 with HTTP; Wed, 4 May 2016 20:49:07 -0700 (PDT) Date: Wed, 4 May 2016 23:49:07 -0400 Message-ID: From: Justin Dean To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c09daf062cf2c0532103984 Archived-At: Subject: [manet] AODVv2 Decision X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 03:49:11 -0000 --94eb2c09daf062cf2c0532103984 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Working Group, I will not be passing AODVv2 out of the working group and to the IESG. This was not an easy decision, nor one made lightly. However, despite many attempts to draft this email otherwise, I found I could not justify AODVv2=E2=80=99s release. AODVv2 is released to the document editors. The f= ollowing is the rationale for my decision. There is insufficient consensus within MANET to make the passage appropriate. More importantly, perhaps, is that this lack of consensus is justified by the significance of the outstanding issues. These issues include: security, metrics, multiple interface operation with shared ip addresses, possible looping, non-symmetric links, ordering of processing operations, lack of jitter specification, removal of timeouts, and gateway limitations. Many of these issues have been discussed at length, and have apparent consensus solutions proposed and written up. In fact, the progress within the past month has been impressive. Yet, to address these issues, the underlying protocol specification operation has changed within the last call and I do not believe the document is without error. The lack of reference implementation or analysis, in simulation or otherwise, reinforces this concern. Despite these flaws, I continue to believe AODVv2 is better specified in many ways than AODV, as it acknowledges and attempts to solve issues AODV does not even mention such as: multiple interfaces (beyond a passing sentence), designed with security in mind, extendable with the use of RFC5444, metric based routing built in, gateway support (although limited), bi-directional link checking. There is value in this draft and it is my hope that it can be published in some form. I am personally willing to help make that happen. To the editors who worked so hard, you were given an impossible task: to address WG concerns, form consensus and provide verifiable fixes within the timeframe provided. When issuing the last call and doing my review I was not sure that it was impossible, and held out hope until the very moment of this decision that it wasn=E2=80=99t. I am sorry that I was mistaken. The amount of work produced in the last month has been impressive but at this time I=E2=80=99m not willing to pass it out of the working group. Justin --94eb2c09daf062cf2c0532103984 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Working Group,

I will not be passing AODVv2 out of = the working group and to the IESG.=C2=A0 This was not an easy decision, nor= one made lightly. However, despite many attempts to draft this email other= wise, I found I could not justify AODVv2=E2=80=99s release. AODVv2 is relea= sed to the document editors. The following is the rationale for my decision= .

There is insufficient consensus within MANET to make the passage a= ppropriate.=C2=A0 More importantly, perhaps, is that this lack of consensus= is justified by the significance of the outstanding issues.=C2=A0 These is= sues include: security, metrics, multiple interface operation with shared i= p addresses, possible looping, non-symmetric links, ordering of processing = operations, lack of jitter specification, removal of timeouts, and gateway = limitations.=C2=A0 Many of these issues have been discussed at length, and = have apparent consensus solutions proposed and written up.=C2=A0 In fact, t= he progress within the past month has been impressive.=C2=A0 Yet, to addres= s these issues, the underlying protocol specification operation has changed= within the last call and I do not believe the document is without error.= =C2=A0 The lack of reference implementation or analysis, in simulation or o= therwise, reinforces this concern. =C2=A0

Despite these flaws, I con= tinue to believe AODVv2 is better specified in many ways than AODV, as it a= cknowledges and attempts to solve issues AODV does not even mention such as= : multiple interfaces (beyond a passing sentence), designed with security i= n mind, extendable with the use of RFC5444, metric based routing built in, = gateway support (although limited), bi-directional link checking.=C2=A0 The= re is value in this draft and it is my hope that it can be published in som= e form. I am personally willing to help make that happen.

To the edi= tors who worked so hard, you were given an impossible task: to address WG c= oncerns, form consensus and provide verifiable fixes within the timeframe p= rovided.=C2=A0 When issuing the last call and doing my review I was not sur= e that it was impossible, and held out hope until the very moment of this d= ecision that it wasn=E2=80=99t.=C2=A0 I am sorry that I was mistaken.
The amount of work produced in the last month has been impressive but at = this time I=E2=80=99m not willing to pass it out of the working group.
<= br>Justin
--94eb2c09daf062cf2c0532103984-- From nobody Wed May 4 22:32:01 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE79D12D54C for ; Wed, 4 May 2016 22:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=herberg.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNzz53XKjJoo for ; Wed, 4 May 2016 22:31:59 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3414012D542 for ; Wed, 4 May 2016 22:31:59 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id u185so86734806iod.3 for ; Wed, 04 May 2016 22:31:59 -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; bh=e5pbsxGQ0I+HHp2rPiImKio1S4F5GBpuslxNCHxzMqc=; b=ugyn/9/gJZcCYJTaM4r1He/5QRHiPWhRdU5J/DJ7eq+gBPVERlZwp4FC0O6BnUsLRn vnEGPQzVb/7FhEMpgXOWt7XTgn6f4hSF+tyx5Vd772SywViNcIwZfI0jpimrXvfIgJ9g 9QpZFmud3f/YMel8hJNvrKordMblY8I2KkBrE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=e5pbsxGQ0I+HHp2rPiImKio1S4F5GBpuslxNCHxzMqc=; b=N4IAnIpeo8XyIYABxEeIHoHu+QtBMiEOTfdrdOLoUSXtZ4MCJrQKEVMSsVDiqtFJe+ OyBFBgvsbMXjo4Rt7liUS/gHaVmiOxXtDRWHFJ/Gywytw2JFTcMOw3YswDF8/kLrWWv1 HGkPZW+7rx484BW5JAabe8PSuIdyySobPSfKDBh2mQYqLSHumMCXsx9pi/fDP1vaM4Pk b69rcIgS4Or4IYFp1+OFl2S8ZZuD2P1BcK+VaMi/gQrcTRn0F3oIHtZRiVjH8HtRy/lp hU9P+0MzHHJdkXcFiZqAjZp04w8pYJLiNKiCkT29xR0meaHqnNIcb/ud/lpTIEsdyU0s /Hkw== X-Gm-Message-State: AOPr4FXeEEpMaY6g8FSJEEOedoxSCNJuCsrMgg/p7CtsBD7XuiUsSy/yeW9k39Uhf4KqynrUMaOXRMUrVbT4Zw== MIME-Version: 1.0 X-Received: by 10.107.168.85 with SMTP id r82mr14802587ioe.179.1462426318564; Wed, 04 May 2016 22:31:58 -0700 (PDT) Received: by 10.36.86.142 with HTTP; Wed, 4 May 2016 22:31:58 -0700 (PDT) In-Reply-To: References: <20160504170444.8256.99788.idtracker@ietfa.amsl.com> Date: Wed, 4 May 2016 22:31:58 -0700 Message-ID: From: Ulrich Herberg To: Justin Dean Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 05:32:01 -0000 Thanks! On Wed, May 4, 2016 at 7:55 PM, Justin Dean wrote: > Ack. I'll talk with Stan ASAP and keep things moving. > > Justin > > On Wed, May 4, 2016 at 1:06 PM, Dearlove, Christopher (UK) > wrote: >> >> This includes all of the issues I listed in my previous email of comments >> made at WGLC. >> >> The authors request starting all the post-WGLC things to do. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> __________________________________________________________________________ >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed May 4 23:57:14 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC85B12D0D3 for ; Wed, 4 May 2016 23:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPGHNhadjtdV for ; Wed, 4 May 2016 23:57:10 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B8212B065 for ; Wed, 4 May 2016 23:57:10 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id x7so38386760qkd.3 for ; Wed, 04 May 2016 23:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=O02nYxmHd4GWxVlW/gINnV3PzU2Ae5Rp3fO8+AgbKCk=; b=dFx9bNLwYJWoLkpLaK6GnHpgMZVZEEnbepCJnZ9A2G+xjckxGnxCzyLSToGCOHmebo mJyavVpCNLLO8h+5AjLROo8dwzSPhRlL/26T0qo1QTsWqBD3Ns149ayHKU2jeODizDqL dcZtz8KIheIdqcON/BKteF9vPpUAlrNn+aeFi2OFF4hsv7D2BjyqJxJ/SzQwRVBR9wSa L130N/37Cbezw+1cvZOtAFyC8wpIMN7W2UuL3MsHWyrI9eq6Ynu7CWqYF6Qf/fVMTPrv MgucMlOrDjid0LNkOm/7K1UfR4KJ4wKlScWA5Qxwp8cBwOPFN3VQlNw/W/c8NqojDjip voSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=O02nYxmHd4GWxVlW/gINnV3PzU2Ae5Rp3fO8+AgbKCk=; b=YCYIAhrbgc2i9N8EBr42kd8+1QsIbOAS6IxC3PCeSvKzuNcBh9DPVxIMQnLCmQ2qmc 0ad9MYq7ktjlJHTL68aYWRKnJSexuxgR3+9huUD0pBp7zFoPDBl26fjnMLUk3i8Tddxt 2xu2qZX0Aaqf699bmxJ+1rkyk1uh470VDVDaQ3sni5FUEaG7oJWXAYj0qM3lqvUmcaNF Th4FFSBkrxtWNfDojZkKcEPe8P2IZ+D4JFLk/Be1wxH33/xL231W/vd8b0EeUPudW6cs A1fz54RDktZYZi8idfgOTfoF36JLPe/sAc6dcCZtodwrmQQN0x6KxU+FyGXANzTtMr6P cLzA== X-Gm-Message-State: AOPr4FVeG7mRVw7Sh/8SEKbBUrpjRTEUgy5tjp4ZENfI0INnELuyImmBeEysysJjC4ea6q8/Vt8dF+b6/k/Xbg== MIME-Version: 1.0 X-Received: by 10.55.75.12 with SMTP id y12mr12887002qka.73.1462431429492; Wed, 04 May 2016 23:57:09 -0700 (PDT) Received: by 10.140.43.52 with HTTP; Wed, 4 May 2016 23:57:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 May 2016 08:57:09 +0200 Message-ID: From: Abdussalam Baryun To: Justin Dean Content-Type: multipart/alternative; boundary=001a114a8282dd0644053212d99f Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] AODVv2 Decision X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 06:57:13 -0000 --001a114a8282dd0644053212d99f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Justin, and All, I think the main reason of AODVv2 delay or WG long-argument, is due to the design of packet before designing the protocol. I was against designing the packet before the protocol but the WG continued. It worked for OLSRv2 because the authors of rfc5444 are authoring that proactive-protocol and that the both designs worked in parallel for that protocol completion, but AODVv2 did not work in parallel, and part of the WG argued to follow the packet design. However, I will suggest that the draft of using the rfc5444 should not go and leave it after recharter, because there are many issues not discussed/agreed in using rfc5444 for reactive protocols. AB On Thu, May 5, 2016 at 5:49 AM, Justin Dean wrote: > Working Group, > > I will not be passing AODVv2 out of the working group and to the IESG. > This was not an easy decision, nor one made lightly. However, despite man= y > attempts to draft this email otherwise, I found I could not justify > AODVv2=E2=80=99s release. AODVv2 is released to the document editors. The= following > is the rationale for my decision. > > There is insufficient consensus within MANET to make the passage > appropriate. More importantly, perhaps, is that this lack of consensus i= s > justified by the significance of the outstanding issues. These issues > include: security, metrics, multiple interface operation with shared ip > addresses, possible looping, non-symmetric links, ordering of processing > operations, lack of jitter specification, removal of timeouts, and gatewa= y > limitations. Many of these issues have been discussed at length, and hav= e > apparent consensus solutions proposed and written up. In fact, the > progress within the past month has been impressive. Yet, to address thes= e > issues, the underlying protocol specification operation has changed withi= n > the last call and I do not believe the document is without error. The la= ck > of reference implementation or analysis, in simulation or otherwise, > reinforces this concern. > > Despite these flaws, I continue to believe AODVv2 is better specified in > many ways than AODV, as it acknowledges and attempts to solve issues AODV > does not even mention such as: multiple interfaces (beyond a passing > sentence), designed with security in mind, extendable with the use of > RFC5444, metric based routing built in, gateway support (although limited= ), > bi-directional link checking. There is value in this draft and it is my > hope that it can be published in some form. I am personally willing to he= lp > make that happen. > > To the editors who worked so hard, you were given an impossible task: to > address WG concerns, form consensus and provide verifiable fixes within t= he > timeframe provided. When issuing the last call and doing my review I was > not sure that it was impossible, and held out hope until the very moment = of > this decision that it wasn=E2=80=99t. I am sorry that I was mistaken. > > The amount of work produced in the last month has been impressive but at > this time I=E2=80=99m not willing to pass it out of the working group. > > Justin > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a114a8282dd0644053212d99f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Justin, and All,

I think th= e main reason of AODVv2 delay or WG long-argument, is due to the design of = packet before designing the protocol. I was against designing the packet be= fore the protocol but the WG continued. It worked for OLSRv2 because the au= thors of rfc5444 are authoring that proactive-protocol and that the both de= signs worked in parallel for that protocol completion, but AODVv2 did not w= ork in parallel, and part of the WG argued to follow the packet design. How= ever, I will suggest that the draft of using the rfc5444 should not go and = leave it after recharter, because there are many issues not discussed/agree= d in using rfc5444 for reactive protocols.
=C2=A0
AB=C2= =A0

On = Thu, May 5, 2016 at 5:49 AM, Justin Dean <bebemaster@gmail.com><= /span> wrote:
Working Gr= oup,

I will not be passing AODVv2 out of the working group and to th= e IESG.=C2=A0 This was not an easy decision, nor one made lightly. However,= despite many attempts to draft this email otherwise, I found I could not j= ustify AODVv2=E2=80=99s release. AODVv2 is released to the document editors= . The following is the rationale for my decision.

There is insuffici= ent consensus within MANET to make the passage appropriate.=C2=A0 More impo= rtantly, perhaps, is that this lack of consensus is justified by the signif= icance of the outstanding issues.=C2=A0 These issues include: security, met= rics, multiple interface operation with shared ip addresses, possible loopi= ng, non-symmetric links, ordering of processing operations, lack of jitter = specification, removal of timeouts, and gateway limitations.=C2=A0 Many of = these issues have been discussed at length, and have apparent consensus sol= utions proposed and written up.=C2=A0 In fact, the progress within the past= month has been impressive.=C2=A0 Yet, to address these issues, the underly= ing protocol specification operation has changed within the last call and I= do not believe the document is without error.=C2=A0 The lack of reference = implementation or analysis, in simulation or otherwise, reinforces this con= cern. =C2=A0

Despite these flaws, I continue to believe AODVv2 is be= tter specified in many ways than AODV, as it acknowledges and attempts to s= olve issues AODV does not even mention such as: multiple interfaces (beyond= a passing sentence), designed with security in mind, extendable with the u= se of RFC5444, metric based routing built in, gateway support (although lim= ited), bi-directional link checking.=C2=A0 There is value in this draft and= it is my hope that it can be published in some form. I am personally willi= ng to help make that happen.

To the editors who worked so hard, you = were given an impossible task: to address WG concerns, form consensus and p= rovide verifiable fixes within the timeframe provided.=C2=A0 When issuing t= he last call and doing my review I was not sure that it was impossible, and= held out hope until the very moment of this decision that it wasn=E2=80=99= t.=C2=A0 I am sorry that I was mistaken.

The amount of work produced= in the last month has been impressive but at this time I=E2=80=99m not wil= ling to pass it out of the working group.

Justin

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a114a8282dd0644053212d99f-- From nobody Thu May 5 01:50:23 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4687112D561 for ; Thu, 5 May 2016 01:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.139 X-Spam-Level: *** X-Spam-Status: No, score=3.139 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvteovksHmq3 for ; Thu, 5 May 2016 01:50:20 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9935812B011 for ; Thu, 5 May 2016 01:50:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: "'Stan Ratliff'" , "'MANET IETF'" References: In-Reply-To: Date: Thu, 5 May 2016 04:50:22 -0400 Message-ID: <064201d1a6ab$298cd950$7ca68bf0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0643_01D1A689.A27CBFF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKibbHKy5KEZVLVrCE2PCbzWp6TN54Iet9w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [manet] Interim call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 08:50:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0643_01D1A689.A27CBFF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Stan:=20 =20 I would be interested in a call.=20 =20 Sue=20 =20 From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff Sent: Tuesday, April 26, 2016 9:32 AM To: MANET IETF Subject: [manet] Interim call =20 WG,=20 =20 I asked a few days ago about an interim telecon to discuss recharter. = Justin also sent the last copy of the new charter we were working on in = Prague. So far, the silence has been deafening...=20 =20 Does the lack of discussion here on-list indicate that the members of = the WG have no interest in a re-charter effort? Or is this (hopefully) a = case of having "bigger fish to fry"?=20 =20 Please indicate your interest in having a call to discuss the charter - = I'd like to schedule a call around May 10 (2 weeks from today). =20 Regards, Stan =20 ------=_NextPart_000_0643_01D1A689.A27CBFF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Stan:

 

I would be interested in a call.

 

Sue

 

From:= = manet [mailto:manet-bounces@ietf.org] On Behalf Of Stan = Ratliff
Sent: Tuesday, April 26, 2016 9:32 AM
To: = MANET IETF
Subject: [manet] Interim = call

 

WG, 

 

I = asked a few days ago about an interim telecon to discuss recharter. = Justin also sent the last copy of the new charter we were working on in = Prague. So far, the silence has been = deafening... 

 

Does the lack of discussion here on-list indicate that = the members of the WG have no interest in a re-charter effort? Or is = this (hopefully) a case of having "bigger fish to = fry"? 

 

Please indicate your interest in having a call to = discuss the charter - I'd like to schedule a call around May 10 (2 weeks = from today).

 

Regards,

Stan

 

------=_NextPart_000_0643_01D1A689.A27CBFF0-- From nobody Thu May 5 03:30:50 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2F212D563 for ; Thu, 5 May 2016 03:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7x3woB8ji3H for ; Thu, 5 May 2016 03:30:43 -0700 (PDT) Received: from antispam02.uminho.pt (antispam02.uminho.pt [193.137.9.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E6C12D0AF for ; Thu, 5 May 2016 03:30:42 -0700 (PDT) Received: from antispam02.uminho.pt (localhost [127.0.0.1]) by antispam02.uminho.pt (Postfix) with ESMTP id 3r0rlh15Xwz11Ck for ; Thu, 5 May 2016 11:30:40 +0100 (WEST) Received: from SRV-EXCH-CAS-02.uminho.pt (unknown [10.10.60.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by antispam02.uminho.pt (Postfix) with ESMTPS id 3r0rlg6K12z11BN for ; Thu, 5 May 2016 11:30:39 +0100 (WEST) Received: from fab (193.136.19.77) by mail.uminho.pt (10.10.102.81) with Microsoft SMTP Server id 14.3.195.1; Thu, 5 May 2016 11:30:01 +0100 From: To: Message-ID: <843467284.24.1462444176469.JavaMail.Fabio@fab> MIME-Version: 1.0 Content-Type: text/plain; charset="Cp1252" Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 160505-0, 05/05/2016), Outbound message X-Antivirus-Status: Clean Date: Thu, 5 May 2016 11:30:01 +0100 X-Originating-IP: [193.136.19.77] Archived-At: Subject: [manet] Call for Papers - International Workshop on Computation Sustainability, Technologies and Applications (CoSTA'2016) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 10:30:46 -0000 --------------------------------- CALL FOR PAPERS --------------------------------- International Workshop on Computation Sustainability, Technologies and Appl= ications (CoSTA'2016) 12-13 September 2016 - London http://islab.di.uminho.pt/CoSTA2016/ --------------------------------- SCOPE --------------------------------- The more connected the world gets, the more data and information becomes av= ailable not only to monitor, but act upon the world and society. Addressing= the needs of this society without burdening it is a complex task which req= uires different approaches. The field of computational sustainability altho= ugh new in nomenclature has been applied in our society since the use of op= timisation strategies and efficiency planning in computer science itself. N= evertheless, the current developments in the internet of things, smart-citi= es and intelligent environments propose new opportunities which can be used= to the benefit of this society. Topics that can address computational sustainability are characterised by t= he dimensions that they act upon. Taking the definition of Sustainability t= hese are environment, economic and social. However, it not uncommon that ap= plications span across dimensions such as human well-being, human behaviour= and activity tracking, city transportation systems, city buildings managem= ent, renewable energy and energy efficiency. In order to achieve these solu= tions, approaches from computational sustainability often include machine l= earning, constraint reasoning and optimisation, sensor fusion, autonomous s= ystems, among others. This workshop has, as its main objective, to demonstrate new and original r= esearch on the topics related to computational sustainability applied to in= telligent environments and smart-cities. Furthermore, techniques for design= , assessment, monitoring and actuation to increase efficiency and optimisat= ion are expected as general contributions. ---------------------------------------------------------------------------= ------------------------ Topics of interest include, although are not limited to: ---------------------------------------------------------------------------= ------------------------ Computational Sustainability; Smart-Cities; User-Awareness; Information Diffusion; Ubiquitous Computing; Sensor Networks; Energy Efficiency; Planning and Scheduling; Game Theory and Economic, Environmental and Social Paradigms; Applications for Computational Sustainability; Multi-agent Systems; Human-Computation; Participatory sensing --------------------------------- Important Dates --------------------------------- Paper submission: 1st March 2016 Notification of acceptance: 29 Apr 2016 Camera Ready: 20 May 2016 --------------------------------- Submission Guidelines: --------------------------------- Authors are invited to submit regular full papers no more than twelve (12) = pages (including any data, figures and references) formatted using the IOS= Press style instructions http://www.iospress.nl/service/authors/latex-and-= word-tools-for-book-authors. All papers accepted for publication in this Workshop will be published as a= volume of the Ambient Intelligence and Smart Environments Series of IOS Pr= ess and electronically available through ACM Digital Library. These proceedings are expected to be ISI indexed. --------------------------------- Organizing Committee: --------------------------------- F=E1bio Silva, University of Minho, Portugal Shin'ichi Konomi, University of Tokyo, Japan Rui Costa, Ubiwhere, Portugal Cesar Analide, University of Minho, Portugal Paulo Novais, University of Minho, Portugal From nobody Thu May 5 03:35:06 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4DC12D563 for ; Thu, 5 May 2016 03:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsU1V9jhuS24 for ; Thu, 5 May 2016 03:34:59 -0700 (PDT) Received: from antispam01.uminho.pt (antispam01.uminho.pt [193.137.9.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A49612D0AF for ; Thu, 5 May 2016 03:34:59 -0700 (PDT) Received: from antispam01.uminho.pt (localhost [127.0.0.1]) by antispam01.uminho.pt (Postfix) with ESMTP id 3r0rrd1qFdz7w69 for ; Thu, 5 May 2016 11:34:57 +0100 (WEST) Received: from SRV-EXCH-CAS-02.uminho.pt (unknown [10.10.60.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by antispam01.uminho.pt (Postfix) with ESMTPS id 3r0rrd1mjnz7w5s for ; Thu, 5 May 2016 11:34:57 +0100 (WEST) Received: from fab (193.136.19.77) by mail.uminho.pt (10.10.102.81) with Microsoft SMTP Server id 14.3.195.1; Thu, 5 May 2016 11:33:39 +0100 From: To: Message-ID: <843467284.24.1462444394215.JavaMail.Fabio@fab> MIME-Version: 1.0 Content-Type: text/plain; charset="Cp1252" Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 160505-0, 05/05/2016), Outbound message X-Antivirus-Status: Clean Date: Thu, 5 May 2016 11:33:39 +0100 X-Originating-IP: [193.136.19.77] Archived-At: Subject: [manet] Call for Papers - International Workshop on Computation Sustainability, Technologies and Applications (CoSTA'2016) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 10:35:03 -0000 (Sorry for multiple posting, information has been corrected!) --------------------------------- CALL FOR PAPERS --------------------------------- International Workshop on Computation Sustainability, Technologies and Appl= ications (CoSTA'2016) 12-13 September 2016 - London http://islab.di.uminho.pt/CoSTA2016/ --------------------------------- SCOPE --------------------------------- The more connected the world gets, the more data and information becomes av= ailable not only to monitor, but act upon the world and society. Addressing= the needs of this society without burdening it is a complex task which req= uires different approaches. The field of computational sustainability altho= ugh new in nomenclature has been applied in our society since the use of op= timisation strategies and efficiency planning in computer science itself. N= evertheless, the current developments in the internet of things, smart-citi= es and intelligent environments propose new opportunities which can be used= to the benefit of this society. Topics that can address computational sustainability are characterised by t= he dimensions that they act upon. Taking the definition of Sustainability t= hese are environment, economic and social. However, it not uncommon that ap= plications span across dimensions such as human well-being, human behaviour= and activity tracking, city transportation systems, city buildings managem= ent, renewable energy and energy efficiency. In order to achieve these solu= tions, approaches from computational sustainability often include machine l= earning, constraint reasoning and optimisation, sensor fusion, autonomous s= ystems, among others. This workshop has, as its main objective, to demonstrate new and original r= esearch on the topics related to computational sustainability applied to in= telligent environments and smart-cities. Furthermore, techniques for design= , assessment, monitoring and actuation to increase efficiency and optimisat= ion are expected as general contributions. ---------------------------------------------------------------------------= ------------------------ Topics of interest include, although are not limited to: ---------------------------------------------------------------------------= ------------------------ Computational Sustainability; Smart-Cities; User-Awareness; Information Diffusion; Ubiquitous Computing; Sensor Networks; Energy Efficiency; Planning and Scheduling; Game Theory and Economic, Environmental and Social Paradigms; Applications for Computational Sustainability; Multi-agent Systems; Human-Computation; Participatory sensing --------------------------------- Important Dates --------------------------------- Paper submission: 16th May 2016 Notification of acceptance: 10th June 2016 Camera Ready: 20th June 2016 --------------------------------- Submission Guidelines: --------------------------------- Authors are invited to submit regular full papers no more than twelve (12) = pages (including any data, figures and references) formatted using the IOS = Press style instructions http://www.iospress.nl/service/authors/latex-and-w= ord-tools-for-book-authors.=20 The papers should be submitted through the easychair website for this works= hop: https://easychair.org/conferences/?conf=3Dcosta2016 All papers accepted for publication in this Workshop will be published as a= volume of the Ambient Intelligence and Smart Environments Series of IOS Pr= ess and electronically available through ACM Digital Library. These proceedings are expected to be ISI indexed. --------------------------------- Organizing Committee: --------------------------------- F=E1bio Silva, University of Minho, Portugal Shin'ichi Konomi, University of Tokyo, Japan Rui Costa, Ubiwhere, Portugal Cesar Analide, University of Minho, Portugal Paulo Novais, University of Minho, Portugal From nobody Thu May 5 07:11:52 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EBE12D8C2 for ; Thu, 5 May 2016 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEMwN1xKacUa for ; Thu, 5 May 2016 07:11:49 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE3812D8E7 for ; Thu, 5 May 2016 07:06:22 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id m64so97124124lfd.1 for ; Thu, 05 May 2016 07:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=P2/I1L/L/nhlrwCnYyNgbgW35qJDAyQ+RBfRGUnQeio=; b=kTvCCYXJtCJIKqCfn0guV+b6k9hv0Wo4CE4MXzBEcE7Dvulqm6J4/lK0Ssnpx3LFYT bMWi7UE8RiBLdiuHDmvcHfGCOQVK8Nng4pug9uiXC1PpHkiGxju+jiTYSrgn8NVpOEaH OYry1z82M5wnw2057kIkU4m4icEsGEJSBHG2AM18VF+IMfPjGAs1t3Wj+zJ/EL6kkD2T DHWGXgIoqXsEJRIQr2GVBsGomnpOEljRanS6y4M8I/SKjyMxuydYk9wgk2Hd3c/sRw1V FQ+/3R93fbMLN+6KHadKsHv4mO+wj4Yql/lmZR1QWvYsWd4InbpiHyBLVkSXly7p6E1B 8QvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=P2/I1L/L/nhlrwCnYyNgbgW35qJDAyQ+RBfRGUnQeio=; b=eDJJHyFa0UIreaL1A5cdure5fWez3bvKFXurP5/kIhxDeXtbuFHHsDi9xDUXl/DJyF Mt1/dq96PQ7IuJZJefwHaChTVAqEUbeO+smmr/1xd9gIYqbsk+AqxH3hRcFwMKRMFEBx SYju68A6QVz5N1Uyf+9YHDMFTujtRQ+sbSfdAQm3jJU5nA4/mocq/FmZvZnzDzaFomH2 NoLe1DrPOu7UA0aTOj1YVpbBhUXUimluxHmR/xxemZ2oba5bHY9W7lHh+jxUI0oF0VXp yut7qTzZGC5cvyD883cfv9AVgDI53y9ynqf+FH9zbGFdDo7PDVHALfG0nfxNeOa+Q4vx PMBg== X-Gm-Message-State: AOPr4FUV2l0oUPqbBPB8qK5vzHjcsAXkth440z2al8GUOHfNvs3tYbCW7DNNlq+h+bEsRMA3KPV4SDingQllBA== MIME-Version: 1.0 X-Received: by 10.25.78.68 with SMTP id c65mr4522426lfb.21.1462457180125; Thu, 05 May 2016 07:06:20 -0700 (PDT) Received: by 10.112.204.200 with HTTP; Thu, 5 May 2016 07:06:20 -0700 (PDT) In-Reply-To: <064201d1a6ab$298cd950$7ca68bf0$@ndzh.com> References: <064201d1a6ab$298cd950$7ca68bf0$@ndzh.com> Date: Thu, 5 May 2016 10:06:20 -0400 Message-ID: From: James Nguyen To: MANET IETF Content-Type: multipart/alternative; boundary=001a11419e1cb88264053218d835 Archived-At: Subject: Re: [manet] Interim call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:11:51 -0000 --001a11419e1cb88264053218d835 Content-Type: text/plain; charset=UTF-8 I'm also in interested. JN On Thu, May 5, 2016 at 4:50 AM, Susan Hares wrote: > Stan: > > > > I would be interested in a call. > > > > Sue > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Stan Ratliff > *Sent:* Tuesday, April 26, 2016 9:32 AM > *To:* MANET IETF > *Subject:* [manet] Interim call > > > > WG, > > > > I asked a few days ago about an interim telecon to discuss recharter. > Justin also sent the last copy of the new charter we were working on in > Prague. So far, the silence has been deafening... > > > > Does the lack of discussion here on-list indicate that the members of the > WG have no interest in a re-charter effort? Or is this (hopefully) a case > of having "bigger fish to fry"? > > > > Please indicate your interest in having a call to discuss the charter - > I'd like to schedule a call around May 10 (2 weeks from today). > > > > Regards, > > Stan > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > -- James Nguyen Email: james.huy.nguyen@gmail.com --001a11419e1cb88264053218d835 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm also in interested.=C2=A0

JN

On Thu, Ma= y 5, 2016 at 4:50 AM, Susan Hares <shares@ndzh.com> wrote:
=

Stan: =

= =C2=A0

I= would be interested in a call.

=C2=A0

Sue

=C2=A0

From: manet [mai= lto:manet-bounc= es@ietf.org] On Behalf Of Stan Ratliff
Sent: Tuesday, = April 26, 2016 9:32 AM
To: MANET IETF
Subj= ect: [manet] Interim call

=C2=A0

WG,=C2=A0

=C2= =A0

I asked a few days ago abou= t an interim telecon to discuss recharter. Justin also sent the last copy o= f the new charter we were working on in Prague. So far, the silence has bee= n deafening...=C2=A0

= =C2=A0

Does the lack of dis= cussion here on-list indicate that the members of the WG have no interest i= n a re-charter effort? Or is this (hopefully) a case of having "bigger= fish to fry"?=C2=A0

=C2=A0

Please indicate= your interest in having a call to discuss the charter - I'd like to sc= hedule a call around May 10 (2 weeks from today).

=C2=A0

Regards,

Stan

=C2=A0

<= /div>

____________________________________= ___________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




--
James Nguyen
Email: james.huy.nguyen@gmail.com
--001a11419e1cb88264053218d835-- From nobody Thu May 5 07:39:21 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F68912D8DC for ; Thu, 5 May 2016 07:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWOgOEVUF0vX for ; Thu, 5 May 2016 07:39:13 -0700 (PDT) Received: from uhil19pa12.eemsg.mail.mil (uhil19pa12.eemsg.mail.mil [214.24.21.85]) by ietfa.amsl.com (Postfix) with ESMTP id A262712D69A for ; Thu, 5 May 2016 07:31:33 -0700 (PDT) Received: from edge-cols03.mail.mil ([131.64.107.103]) by uhil19pa12.eemsg.mail.mil with ESMTP; 05 May 2016 14:31:32 +0000 Received: from UCOLHPQQ.easf.csd.disa.mil (131.64.107.43) by edge-cols03.mail.mil (131.64.107.103) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 5 May 2016 14:31:32 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([169.254.6.122]) by UCOLHPQQ.easf.csd.disa.mil ([131.64.107.43]) with mapi id 14.03.0266.001; Thu, 5 May 2016 14:31:31 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: MANET IETF Thread-Topic: [Non-DoD Source] Re: [manet] Interim call Thread-Index: AQHRptgiO19/rK78vEagZDp++attqZ+qZ6xA Date: Thu, 5 May 2016 14:31:31 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDFA283687A@UCOLHU2J.easf.csd.disa.mil> References: <064201d1a6ab$298cd950$7ca68bf0$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] [Non-DoD Source] Re: Interim call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:39:20 -0000 SGksIFN0YW46DQoNCkkgd291bGQgYmUgaW50ZXJlc3RlZC4NCg0KQlIvUmFkaGlrYQ0KCSANCg0K CUZyb206IG1hbmV0IFtDYXV0aW9uLW1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnIDwgQ2F1 dGlvbi1tYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZyA+IF0gT24gQmVoYWxmIE9mIFN0YW4g UmF0bGlmZg0KCVNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI2LCAyMDE2IDk6MzIgQU0NCglUbzogTUFO RVQgSUVURg0KCVN1YmplY3Q6IFttYW5ldF0gSW50ZXJpbSBjYWxsDQoNCgkgDQoNCglXRywgDQoN CgkgDQoNCglJIGFza2VkIGEgZmV3IGRheXMgYWdvIGFib3V0IGFuIGludGVyaW0gdGVsZWNvbiB0 byBkaXNjdXNzIHJlY2hhcnRlci4gSnVzdGluIGFsc28gc2VudCB0aGUgbGFzdCBjb3B5IG9mIHRo ZSBuZXcgY2hhcnRlciB3ZSB3ZXJlIHdvcmtpbmcgb24gaW4gUHJhZ3VlLiBTbyBmYXIsIHRoZSBz aWxlbmNlIGhhcyBiZWVuIGRlYWZlbmluZy4uLiANCg0KCSANCg0KCURvZXMgdGhlIGxhY2sgb2Yg ZGlzY3Vzc2lvbiBoZXJlIG9uLWxpc3QgaW5kaWNhdGUgdGhhdCB0aGUgbWVtYmVycyBvZiB0aGUg V0cgaGF2ZSBubyBpbnRlcmVzdCBpbiBhIHJlLWNoYXJ0ZXIgZWZmb3J0PyBPciBpcyB0aGlzICho b3BlZnVsbHkpIGEgY2FzZSBvZiBoYXZpbmcgImJpZ2dlciBmaXNoIHRvIGZyeSI/IA0KDQoJIA0K DQoJUGxlYXNlIGluZGljYXRlIHlvdXIgaW50ZXJlc3QgaW4gaGF2aW5nIGEgY2FsbCB0byBkaXNj dXNzIHRoZSBjaGFydGVyIC0gSSdkIGxpa2UgdG8gc2NoZWR1bGUgYSBjYWxsIGFyb3VuZCBNYXkg MTAgKDIgd2Vla3MgZnJvbSB0b2RheSkuDQoNCgkgDQoNCglSZWdhcmRzLA0KDQoJU3Rhbg0KDQoJ IA0KDQoNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K CW1hbmV0IG1haWxpbmcgbGlzdA0KCW1hbmV0QGlldGYub3JnIDwgQ2F1dGlvbi1tYWlsdG86bWFu ZXRAaWV0Zi5vcmcgPiANCglDYXV0aW9uLWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWFuZXQgPCBDYXV0aW9uLWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWFuZXQgPiANCgkNCgkNCg0KDQoNCg0KLS0gDQoNCkphbWVzIE5ndXllbg0KRW1haWw6IGph bWVzLmh1eS5uZ3V5ZW5AZ21haWwuY29tIDwgQ2F1dGlvbi1tYWlsdG86amFtZXMuaHV5Lm5ndXll bkBnbWFpbC5jb20gPiANCg== From nobody Fri May 6 05:35:34 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CA512D0FF for ; Fri, 6 May 2016 05:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm4POp9arydJ for ; Fri, 6 May 2016 05:35:29 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6227F12D11D for ; Fri, 6 May 2016 05:35:27 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u46CZNdA008285; Fri, 6 May 2016 13:35:23 +0100 Received: from 950129200 ([92.207.169.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u46CZLO9008257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 6 May 2016 13:35:22 +0100 From: "Adrian Farrel" To: "'Justin Dean'" References: In-Reply-To: Date: Fri, 6 May 2016 13:35:18 +0100 Message-ID: <0c1f01d1a793$bff91be0$3feb53a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C20_01D1A79C.21BFF4E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzWPHFpj2GPAXBQXdFEpRNg1MQvp9oc/Cg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22304.007 X-TM-AS-Result: No--18.055-10.0-31-10 X-imss-scan-details: No--18.055-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO2PrjM/ltMU+RMMmcrjEONd50koXQIlRsrjsTquy0JRi4qC QGiQ6WakUf+5gcEpbB38hjN4ObtrTSOkbQIOJ8v5Vo6mn+xXmdVKDzk/xkzLhrrfxlRjqBJ3z3u 9xAVUCw7ar26XlfJS0fx0rDB24Bx9DXVj0zMhpTbmAId+2bAQwi4tncCojEfctXl9IxEPXOpXY6 IbFNKd2/xJ0zLe6h8yHHurRnywZ2oihjhlMTu+HCYRREGYqtmU0w14HFJQjaNUJ1Tm/k9y8aPQG i9+++Wrp8Etj0HS05iyTb6BiiAkhObq4hXTNQb/M10nOFd6RPZG6AM+g4nIaLKeTtOdjMy6CS6I UmxCo5EGKH7gleyvn2r3YS3z8PzgJi9i1QCk0I+zI1v7J4hECkbbuL7Y47c0ERHkysQaiHkD5OW hgbnCK1uLNdP3lWylJsblGaCcX/yIKJlk4vuhndPNaYYJeRf5uOTg6eySPL4/gf7afIrQUzUi2r TIOxGG/wT9u33XJZOgON7U+kuPmAwIsQZbtzZw/Sl5cYQQGW+DddlymG7iS1cbfIj2Ta9sgC46p yJTSnTV4yn6Kf1r098KgvULLt4X/fqypUX9VmhLc5N+0s1+DZT1elWqouGw8cWgFw6wp7OI+yd4 8zjY3SWuqxiUeEX6MLog80/xRYlR4vrwuhcS/AVOLlPuctdqLdLfmiFS7fuSs1st/hpgblzOKVR 59i8DP5mpBtPr/e7et/aEQRVJHkNKRRr2LbXrWCjDJRYeAZ0BL/XzNFFmHxS11FlOYRohT3bHVz oTp+QXlh2Nyyp8x7Rd0WwZSVdNNJyAyqAmcb+eAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCspjgfkqiqsbrAzNnfpGQaV3FfPtgnGfk8BkEkjvvhMOPNkUSDDq742k= Archived-At: Cc: manet@ietf.org Subject: Re: [manet] AODVv2 Decision X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 12:35:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0C20_01D1A79C.21BFF4E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, =20 I have been largely outside MANET since stepping down as AD, but I want = to thank you for the clarity of this decision and the time I know you = have put in to making it the right decision. =20 As you say, the team working on AODVv2, and Charlie in particular, = cannot be faulted for the long hours of technical work they have put in = over the years. The challenge was formidable, and the support in the = working group somewhat light. And I agree with you that AODVv2 as it = stands is a big step forward from AODV.=20 =20 I don't see the current situation as a failure and I would urge the = authors to discuss with the AD how best to convert this work into an RFC = (perhaps as an Experimental document that is AD sponsored or published = through the ISE). That would represent a stake in the ground and a = reference point for future work. It would also allow everyone (WG and = authors) to move on. =20 Again, Justin, thanks for your leadership. =20 Adrian =20 From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean Sent: 05 May 2016 04:49 To: manet@ietf.org Subject: [manet] AODVv2 Decision =20 Working Group, I will not be passing AODVv2 out of the working group and to the IESG. = This was not an easy decision, nor one made lightly. However, despite = many attempts to draft this email otherwise, I found I could not justify = AODVv2=E2=80=99s release. AODVv2 is released to the document editors. = The following is the rationale for my decision. There is insufficient consensus within MANET to make the passage = appropriate. More importantly, perhaps, is that this lack of consensus = is justified by the significance of the outstanding issues. These = issues include: security, metrics, multiple interface operation with = shared ip addresses, possible looping, non-symmetric links, ordering of = processing operations, lack of jitter specification, removal of = timeouts, and gateway limitations. Many of these issues have been = discussed at length, and have apparent consensus solutions proposed and = written up. In fact, the progress within the past month has been = impressive. Yet, to address these issues, the underlying protocol = specification operation has changed within the last call and I do not = believe the document is without error. The lack of reference = implementation or analysis, in simulation or otherwise, reinforces this = concern. =20 Despite these flaws, I continue to believe AODVv2 is better specified in = many ways than AODV, as it acknowledges and attempts to solve issues = AODV does not even mention such as: multiple interfaces (beyond a = passing sentence), designed with security in mind, extendable with the = use of RFC5444, metric based routing built in, gateway support (although = limited), bi-directional link checking. There is value in this draft = and it is my hope that it can be published in some form. I am personally = willing to help make that happen. To the editors who worked so hard, you were given an impossible task: to = address WG concerns, form consensus and provide verifiable fixes within = the timeframe provided. When issuing the last call and doing my review = I was not sure that it was impossible, and held out hope until the very = moment of this decision that it wasn=E2=80=99t. I am sorry that I was = mistaken. The amount of work produced in the last month has been impressive but at = this time I=E2=80=99m not willing to pass it out of the working group. Justin ------=_NextPart_000_0C20_01D1A79C.21BFF4E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Justin,

 

I have been largely outside = MANET since stepping down as AD, but I want to thank you for the clarity = of this decision and the time I know you have put in to making it the = right decision.

 

As you say, the team working = on AODVv2, and Charlie in particular, cannot be faulted for the long = hours of technical work they have put in over the years. The challenge = was formidable, and the support in the working group somewhat light. And = I agree with you that AODVv2 as it stands is a big step forward from = AODV.

 

I don't see the current = situation as a failure and I would urge the authors to discuss with the = AD how best to convert this work into an RFC (perhaps as an Experimental = document that is AD sponsored or published through the ISE). That would = represent a stake in the ground and a reference point for future work. = It would also allow everyone (WG and authors) to move = on.

 

Again, Justin, thanks for your = leadership.

 

Adrian

 

From: manet = [mailto:manet-bounces@ietf.org] On Behalf Of Justin = Dean
Sent: 05 May 2016 04:49
To: = manet@ietf.org
Subject: [manet] AODVv2 = Decision

 

Working = Group,

I will not be passing AODVv2 out of the working group and = to the IESG.  This was not an easy decision, nor one made lightly. = However, despite many attempts to draft this email otherwise, I found I = could not justify AODVv2=E2=80=99s release. AODVv2 is released to the = document editors. The following is the rationale for my = decision.

There is insufficient consensus within MANET to make = the passage appropriate.  More importantly, perhaps, is that this = lack of consensus is justified by the significance of the outstanding = issues.  These issues include: security, metrics, multiple = interface operation with shared ip addresses, possible looping, = non-symmetric links, ordering of processing operations, lack of jitter = specification, removal of timeouts, and gateway limitations.  Many = of these issues have been discussed at length, and have apparent = consensus solutions proposed and written up.  In fact, the progress = within the past month has been impressive.  Yet, to address these = issues, the underlying protocol specification operation has changed = within the last call and I do not believe the document is without = error.  The lack of reference implementation or analysis, in = simulation or otherwise, reinforces this concern.  

Despite = these flaws, I continue to believe AODVv2 is better specified in many = ways than AODV, as it acknowledges and attempts to solve issues AODV = does not even mention such as: multiple interfaces (beyond a passing = sentence), designed with security in mind, extendable with the use of = RFC5444, metric based routing built in, gateway support (although = limited), bi-directional link checking.  There is value in this = draft and it is my hope that it can be published in some form. I am = personally willing to help make that happen.

To the editors who = worked so hard, you were given an impossible task: to address WG = concerns, form consensus and provide verifiable fixes within the = timeframe provided.  When issuing the last call and doing my review = I was not sure that it was impossible, and held out hope until the very = moment of this decision that it wasn=E2=80=99t.  I am sorry that I = was mistaken.

The amount of work produced in the last month has = been impressive but at this time I=E2=80=99m not willing to pass it out = of the working = group.

Justin

------=_NextPart_000_0C20_01D1A79C.21BFF4E0-- From nobody Fri May 6 10:03:30 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00DD12D50F for ; Fri, 6 May 2016 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X44hgwRlneAE for ; Fri, 6 May 2016 10:03:26 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E2212D50B for ; Fri, 6 May 2016 10:03:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 98B2178004C; Fri, 6 May 2016 10:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1462554205; bh=Xd6MgyXXwdiOUeXXxklpFr18Zz67wWWLvTlMvmntJXw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=SxImrjFse2eK9cMWFthPwDvEdsdYJQZVvVWaq2pY6P3VUUZCqg0p5y5vlg4oCYk8X I2om7HLh7qC6DFQlAEuInfd38VwNsdm2NCSVSmPtP1egUNbR8mryUjFHM+xo5BpmNh hrF7Y6f7VYM3jshLJK2k0nHpahfhmPP16TbhKAo8= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [129.104.89.231] (unknown [129.104.89.231]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6950A1C01DB; Fri, 6 May 2016 10:03:24 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_B3F9D9B7-B614-40B1-9596-E11268141D48" From: ietf@thomasclausen.org In-Reply-To: <0c1f01d1a793$bff91be0$3feb53a0$@olddog.co.uk> Date: Fri, 6 May 2016 19:03:21 +0200 Sendlaterdate: Fri, 6 May 2016 19:03:21 +0200 Message-Id: <030BAD33-362B-4B44-B957-A1D9B838D3E6@thomasclausen.org> References: <0c1f01d1a793$bff91be0$3feb53a0$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] AODVv2 Decision X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 17:03:29 -0000 --Apple-Mail=_B3F9D9B7-B614-40B1-9596-E11268141D48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adrian, I cannot let you get away with saying that there "the support in the = working group [has been] somewhat light=E2=80=9D =E2=80=94 that's simply = not true, given the numerous, frequent, detailed, massive, and = constructive reviews that have been offered over the years by Ulrich, = Jiazi, Chris, Justin, and others (including myself). These reviews largely have gone unanswered by the authors for months, = years, even decades at length =E2=80=94 for which you can fault the = authors, or the WG chairs (and the rest of the leadership) for not = holding the authors feet to the fire. =E2=80=A6but you do not get to pass blame off to the WG here. As Mr. = Dean has reported, the work on this specification has largely happened = outside, and detached from, the WG. Best, Thomas > On 06 May 2016, at 14:35, Adrian Farrel wrote: >=20 > Hi Justin, > =20 > I have been largely outside MANET since stepping down as AD, but I = want to thank you for the clarity of this decision and the time I know = you have put in to making it the right decision. > =20 > As you say, the team working on AODVv2, and Charlie in particular, = cannot be faulted for the long hours of technical work they have put in = over the years. The challenge was formidable, and the support in the = working group somewhat light. And I agree with you that AODVv2 as it = stands is a big step forward from AODV.=20 > =20 > I don't see the current situation as a failure and I would urge the = authors to discuss with the AD how best to convert this work into an RFC = (perhaps as an Experimental document that is AD sponsored or published = through the ISE). That would represent a stake in the ground and a = reference point for future work. It would also allow everyone (WG and = authors) to move on. > =20 > Again, Justin, thanks for your leadership. > =20 > Adrian > =20 > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean > Sent: 05 May 2016 04:49 > To: manet@ietf.org > Subject: [manet] AODVv2 Decision > =20 > Working Group, >=20 > I will not be passing AODVv2 out of the working group and to the IESG. = This was not an easy decision, nor one made lightly. However, despite = many attempts to draft this email otherwise, I found I could not justify = AODVv2=E2=80=99s release. AODVv2 is released to the document editors. = The following is the rationale for my decision. >=20 > There is insufficient consensus within MANET to make the passage = appropriate. More importantly, perhaps, is that this lack of consensus = is justified by the significance of the outstanding issues. These = issues include: security, metrics, multiple interface operation with = shared ip addresses, possible looping, non-symmetric links, ordering of = processing operations, lack of jitter specification, removal of = timeouts, and gateway limitations. Many of these issues have been = discussed at length, and have apparent consensus solutions proposed and = written up. In fact, the progress within the past month has been = impressive. Yet, to address these issues, the underlying protocol = specification operation has changed within the last call and I do not = believe the document is without error. The lack of reference = implementation or analysis, in simulation or otherwise, reinforces this = concern. =20 >=20 > Despite these flaws, I continue to believe AODVv2 is better specified = in many ways than AODV, as it acknowledges and attempts to solve issues = AODV does not even mention such as: multiple interfaces (beyond a = passing sentence), designed with security in mind, extendable with the = use of RFC5444, metric based routing built in, gateway support (although = limited), bi-directional link checking. There is value in this draft = and it is my hope that it can be published in some form. I am personally = willing to help make that happen. >=20 > To the editors who worked so hard, you were given an impossible task: = to address WG concerns, form consensus and provide verifiable fixes = within the timeframe provided. When issuing the last call and doing my = review I was not sure that it was impossible, and held out hope until = the very moment of this decision that it wasn=E2=80=99t. I am sorry = that I was mistaken. >=20 > The amount of work produced in the last month has been impressive but = at this time I=E2=80=99m not willing to pass it out of the working = group. >=20 > Justin > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_B3F9D9B7-B614-40B1-9596-E11268141D48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Adrian,

I cannot let you get away with = saying that there "the support in the working group [has been] somewhat = light=E2=80=9D =E2=80=94 that's simply not true, given the numerous, = frequent, detailed, massive, and constructive reviews that have been = offered over the years by Ulrich, Jiazi, Chris, Justin, and others = (including myself).

These reviews largely have gone = unanswered by the authors for months, years, even decades at length =E2=80= =94 for which you can fault the authors, or the WG chairs (and the rest = of the leadership) for not holding the authors feet to the = fire.
=E2=80=A6but you do not get to pass blame off to the WG here. = As Mr. Dean has reported, the work on this specification has largely = happened outside, and detached from, the WG.

Best,

Thomas



On 06 May 2016, at 14:35, = Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi Justin,
 
I have been largely = outside MANET since stepping down as AD, but I want to thank you for the = clarity of this decision and the time I know you have put in to making = it the right decision.
 
As you say, the team = working on AODVv2, and Charlie in particular, cannot be faulted for the = long hours of technical work they have put in over the years. The = challenge was formidable, and the support in the working group somewhat = light. And I agree with you that AODVv2 as it stands is a big step = forward from AODV. 
 
I don't see the current = situation as a failure and I would urge the authors to discuss with the = AD how best to convert this work into an RFC (perhaps as an Experimental = document that is AD sponsored or published through the ISE). That would = represent a stake in the ground and a reference point for future work. = It would also allow everyone (WG and authors) to move on.
 
Again, Justin, thanks = for your leadership.
 
Adrian
 
From: manet [mailto:manet-bounces@ietf.org] On Behalf = Of Justin Dean
Sent: 05 May 2016 04:49
To: manet@ietf.org
Subject: [manet] AODVv2 Decision
 
Working Group,

I will not be passing AODVv2 out of the working group and to = the IESG.  This was not an easy decision, nor one made lightly. = However, despite many attempts to draft this email otherwise, I found I = could not justify AODVv2=E2=80=99s release. AODVv2 is released to the = document editors. The following is the rationale for my decision.

There is insufficient consensus within MANET = to make the passage appropriate.  More importantly, perhaps, is = that this lack of consensus is justified by the significance of the = outstanding issues.  These issues include: security, metrics, = multiple interface operation with shared ip addresses, possible looping, = non-symmetric links, ordering of processing operations, lack of jitter = specification, removal of timeouts, and gateway limitations.  Many = of these issues have been discussed at length, and have apparent = consensus solutions proposed and written up.  In fact, the progress = within the past month has been impressive.  Yet, to address these = issues, the underlying protocol specification operation has changed = within the last call and I do not believe the document is without = error.  The lack of reference implementation or analysis, in = simulation or otherwise, reinforces this concern.  
Despite these flaws, I continue to believe AODVv2 is better = specified in many ways than AODV, as it acknowledges and attempts to = solve issues AODV does not even mention such as: multiple interfaces = (beyond a passing sentence), designed with security in mind, extendable = with the use of RFC5444, metric based routing built in, gateway support = (although limited), bi-directional link checking.  There is value = in this draft and it is my hope that it can be published in some form. I = am personally willing to help make that happen.

To the editors who worked so hard, you were given an = impossible task: to address WG concerns, form consensus and provide = verifiable fixes within the timeframe provided.  When issuing the = last call and doing my review I was not sure that it was impossible, and = held out hope until the very moment of this decision that it = wasn=E2=80=99t.  I am sorry that I was mistaken.

The amount of work produced in the last month has been = impressive but at this time I=E2=80=99m not willing to pass it out of = the working group.

Justin
_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

= --Apple-Mail=_B3F9D9B7-B614-40B1-9596-E11268141D48-- From nobody Fri May 6 10:28:01 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA6012D15C for ; Fri, 6 May 2016 10:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eRpp4-NVNWI for ; Fri, 6 May 2016 10:27:57 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84CD12D0C5 for ; Fri, 6 May 2016 10:27:56 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id m9so46307150ige.1 for ; Fri, 06 May 2016 10:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=bxw9Ypjbi2xQGsXT/217fAPhUih82yilwmijRqOaD6k=; b=eTdbabvXQPzQ2FWaTMZ7hvtykJKBNizIQjfCzGBXgXsyw0DPpf0nRZxdq9df01N/Rm B30ASXLNMRdGF45XtBzCwVDD6iT8AeaOvYS2r/zxeKFaIBGLxTneCPA1PKLgxuMXy+pN v9whqRLNqHRshYO8WbzYI4L7f2ZJGWFxTfBMgkYcAgQd62XtE7Zo4k/t/8gI5Qmma9vp ArO+XWMIRDWh0SoQck1oIo3P9Vn8R5ntYq0RJIQuAJacOTVuGUV8jE2D3gqN3leTpfLu /xWGKwPHlk/GoEV1UX4XPNE6A5aEPst1H7m3UAHn12rfeByYGba8JM6PPJ/aaLk3NAZB EctA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=bxw9Ypjbi2xQGsXT/217fAPhUih82yilwmijRqOaD6k=; b=DaLm0HlHWgx5LBRgywpmU3JC55cU1XsaTYfoAUvf1RM6gK6ktOfs+BYx4lJXDKKoh2 xoTXYQSnn1GttTVlYFpxzMOZlwBii2sMreQYh9uCuyBzMH2geMyj/Z0UkFoBfNcPqxBo 5sih2FSn+JiGSfxPiMohq/wGTaUNIY/THVXtkLwxlmMXk1hRR42JwOE3yo/1694hqIQy VWJ5MyISC4rmM/Y8StHcYTFjFB4ejQ4HROL+FL/K94j3T7DnoLBcksd52jpzqKo/8xwk nAUBsVBJ7xSrgHwYkrJkyMsKgIneyTcjudbDXlzQ4qrvlrPv/aKgwuhTQpTmUaNlNQu+ SLDw== X-Gm-Message-State: AOPr4FVhNVJsII2QaJEOpoZ9TOMLefFJAOlpMRCw0PNSBgkDMV15+lJ6bUe1sn52yO95drMmSxj/T0d7l3eAHQ== MIME-Version: 1.0 X-Received: by 10.50.23.196 with SMTP id o4mr11493922igf.36.1462555676259; Fri, 06 May 2016 10:27:56 -0700 (PDT) Received: by 10.79.72.134 with HTTP; Fri, 6 May 2016 10:27:56 -0700 (PDT) Date: Fri, 6 May 2016 13:27:56 -0400 Message-ID: From: Stan Ratliff To: MANET IETF Content-Type: multipart/alternative; boundary=14dae93b57128c40e005322fc70b Archived-At: Subject: [manet] Reminder about MANET WebEx meeting X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 17:27:59 -0000 --14dae93b57128c40e005322fc70b Content-Type: text/plain; charset=UTF-8 Hello everyone, Just a reminder that we have a WebEx scheduled to discuss a potential MANET WG recharter. Please attend if you can. Regards, Stan ---------- Forwarded message ---------- > > > *MANET* > > Thursday, May 12, 2016 > > 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs > > > > > > > > *Join WebEx meeting* > > > > > Meeting number: > > 646 870 685 > > Meeting password: > > GSwbmUQu > > > > > > > > *Join by phone* > > *1-877-668-4493 <1-877-668-4493>* Call-in toll free number (US/Canada) > > *1-650-479-3208 <1-650-479-3208>* Call-in toll number (US/Canada) > > Access code: 646 870 685 > > Toll-free calling restrictions > > > > > > > > > Add this meeting > > to your calendar. (Cannot add from mobile devices.) > > > > > > > > Can't join the meeting? Contact support. > > > > > > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. By joining this session, you automatically > consent to such recordings. If you do not consent to being recorded, > discuss your concerns with the host or do not join the session. > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --14dae93b57128c40e005322fc70b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone,=C2=A0

Just a reminder t= hat we have a WebEx scheduled to discuss a potential MANET WG recharter. Pl= ease attend if you can.=C2=A0

Regards,
Stan



-------= --- Forwarded message ----------

=C2=A0

MANET

Thursday, May 12, 2016

10:00 am=C2=A0=C2=A0|=C2=A0=C2=A0Eastern Daylight Time (New York, GMT-04:00= )=C2=A0=C2=A0|=C2=A0=C2=A02 hrs

=C2=A0

=C2=A0

=C2=A0

Join WebEx meeting

=C2=A0

Meeting number:

646 870 685

Meeting password:

GSwbmUQu

=C2=A0

=C2=A0

=C2=A0

Join by phone

1-877-668-4493= =C2=A0Call-in toll free number (US/Canada)

1-650-479-3208= =C2=A0Call-in toll number (US/Canada)

Access code:=C2=A0646 870 685

= Toll-free calling restrictions

=C2=A0

=C2=A0

=C2=A0

Add this meeting to your= calendar. (Cannot add from mobile devices.)

=C2=A0

=C2=A0

=C2=A0

Can't join the meeting? Contact support.

=C2=A0

=C2=A0

=C2=A0

IMPORTANT NOTICE: Please note= that this WebEx service allows audio and other information sent during the= session to be recorded, which may be discoverable in a legal matter. By jo= ining this session, you automatically consent to such recordings. If you do not consent to being recorded, discu= ss your concerns with the host or do not join the session.

=C2=A0



_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--14dae93b57128c40e005322fc70b-- From nobody Sun May 8 03:09:03 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794512D12B for ; Sun, 8 May 2016 03:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_05fMV66SCA for ; Sun, 8 May 2016 03:08:59 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96DCA12B05C for ; Sun, 8 May 2016 03:08:59 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id n62so9529357qkc.2 for ; Sun, 08 May 2016 03:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Hyhn6xqlWHoqQAczbS2IDS8EsJfWWatf24fu+RWUWQg=; b=bEjcROSFBr3Z7g9s/u4QwkBvMUwSr4IIz3Wy0mIy4F5YzgNdV/5OWjmkqyaBU9bAmJ NtoEcr+UMY2RgBq4FeTD4wShQv15E/DsuuG5/yce7K7AMPcTBq0VMozoShCPiqevJKX2 h0E09WVPtczy8bvu8sCATBC5ewVwjX3ZfTOMRYox4lweMVu1XUedmEmtKQIIEpSXHwQy rFyjEOFyE8G/xdEKhi8JHozI5Z3BWqvNdGYjbXvenG760C20L5jhq/2j03kmEHCc0/aT PvHin5/VcDkDQGqe9XMmdSywDs89++v6myajtambJoLRbowoOdTb8eV7V2l1TK0OpfKA 6I0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Hyhn6xqlWHoqQAczbS2IDS8EsJfWWatf24fu+RWUWQg=; b=X07rEBnf91l1WoWvA+OMfATnTvTJmeF2jm+8MSyPPzK6EFm0bZdScdL9U30dQU7B4J lxEhsQ+dMax3Bvd3nNlDIZjoaMFLCOwsxYgb2bf7qqB/Vo8XXbHLm23vOBtVeyT3dQFq GL064ELtBcV1jk20V8UUEQjSTcu/OoF5gzPd6FSYb/RrFDVWCW8h7H75Ki4Q6bui8grg l60PJzTsJpIqdyRnMBHfKvubDSIRvl55PYW/HT3ZwFyeAbT1R55k/RyACKZkGdXHjlAD AH/8y0h34nPerM4j1RvBe2Pf+TKZeJK67t8U5w02epmFxPMHiV36Pog8cCdreRa9v2Y2 AziQ== X-Gm-Message-State: AOPr4FX/MBkLRY8H11CCLDAnb66lkJqRrDKoX4+b8ZMvZiIV0Bwg5SVE/1eTryqc98OhHoalHCtlyZoNF5TBYQ== MIME-Version: 1.0 X-Received: by 10.55.18.9 with SMTP id c9mr13398045qkh.158.1462702138766; Sun, 08 May 2016 03:08:58 -0700 (PDT) Received: by 10.140.43.52 with HTTP; Sun, 8 May 2016 03:08:58 -0700 (PDT) In-Reply-To: <0c1f01d1a793$bff91be0$3feb53a0$@olddog.co.uk> References: <0c1f01d1a793$bff91be0$3feb53a0$@olddog.co.uk> Date: Sun, 8 May 2016 12:08:58 +0200 Message-ID: From: Abdussalam Baryun To: adrian Content-Type: multipart/alternative; boundary=001a1147636464d8c5053251e134 Archived-At: Cc: manet Subject: Re: [manet] AODVv2 Decision X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 10:09:02 -0000 --001a1147636464d8c5053251e134 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian, Thanks for your suggestion, I support that this work needs to be used in IETF as RFC, because the authors can take it to another standard organisation but I think it is better if they complete it with IETF. However, it is the authors decision that I hope they submit on this list so we can know the direction or we can follow up. AB On Fri, May 6, 2016 at 2:35 PM, Adrian Farrel wrote: > Hi Justin, > > > > I have been largely outside MANET since stepping down as AD, but I want t= o > thank you for the clarity of this decision and the time I know you have p= ut > in to making it the right decision. > > > > As you say, the team working on AODVv2, and Charlie in particular, cannot > be faulted for the long hours of technical work they have put in over the > years. The challenge was formidable, and the support in the working group > somewhat light. And I agree with you that AODVv2 as it stands is a big st= ep > forward from AODV. > > > > I don't see the current situation as a failure and I would urge the > authors to discuss with the AD how best to convert this work into an RFC > (perhaps as an Experimental document that is AD sponsored or published > through the ISE). That would represent a stake in the ground and a > reference point for future work. It would also allow everyone (WG and > authors) to move on. > > > > Again, Justin, thanks for your leadership. > > > > Adrian > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean > *Sent:* 05 May 2016 04:49 > *To:* manet@ietf.org > *Subject:* [manet] AODVv2 Decision > > > > Working Group, > > I will not be passing AODVv2 out of the working group and to the IESG. > This was not an easy decision, nor one made lightly. However, despite man= y > attempts to draft this email otherwise, I found I could not justify > AODVv2=E2=80=99s release. AODVv2 is released to the document editors. The= following > is the rationale for my decision. > > There is insufficient consensus within MANET to make the passage > appropriate. More importantly, perhaps, is that this lack of consensus i= s > justified by the significance of the outstanding issues. These issues > include: security, metrics, multiple interface operation with shared ip > addresses, possible looping, non-symmetric links, ordering of processing > operations, lack of jitter specification, removal of timeouts, and gatewa= y > limitations. Many of these issues have been discussed at length, and hav= e > apparent consensus solutions proposed and written up. In fact, the > progress within the past month has been impressive. Yet, to address thes= e > issues, the underlying protocol specification operation has changed withi= n > the last call and I do not believe the document is without error. The la= ck > of reference implementation or analysis, in simulation or otherwise, > reinforces this concern. > > Despite these flaws, I continue to believe AODVv2 is better specified in > many ways than AODV, as it acknowledges and attempts to solve issues AODV > does not even mention such as: multiple interfaces (beyond a passing > sentence), designed with security in mind, extendable with the use of > RFC5444, metric based routing built in, gateway support (although limited= ), > bi-directional link checking. There is value in this draft and it is my > hope that it can be published in some form. I am personally willing to he= lp > make that happen. > > To the editors who worked so hard, you were given an impossible task: to > address WG concerns, form consensus and provide verifiable fixes within t= he > timeframe provided. When issuing the last call and doing my review I was > not sure that it was impossible, and held out hope until the very moment = of > this decision that it wasn=E2=80=99t. I am sorry that I was mistaken. > > The amount of work produced in the last month has been impressive but at > this time I=E2=80=99m not willing to pass it out of the working group. > > Justin > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a1147636464d8c5053251e134 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

Thanks for your suggesti= on, I support that this work needs to be used in IETF as RFC, because the a= uthors can take it to another standard organisation but I think it is bette= r if they complete it with IETF. However, it is the authors decision that I= hope they submit on this list so we can know the direction or we can follo= w up.

AB

On Fri, May 6, 2016 at 2:35 PM, Adrian Farrel <= adrian@olddog.co.uk> wrote:

Hi Justin,

=C2=A0

I have been largely outside= MANET since stepping down as AD, but I want to thank you for the clarity o= f this decision and the time I know you have put in to making it the right = decision.

=C2=A0

As you say, the team working on AODVv2, and Charlie in part= icular, cannot be faulted for the long hours of technical work they have pu= t in over the years. The challenge was formidable, and the support in the w= orking group somewhat light. And I agree with you that AODVv2 as it stands = is a big step forward from AODV.

=C2=A0

I don't see the current situatio= n as a failure and I would urge the authors to discuss with the AD how best= to convert this work into an RFC (perhaps as an Experimental document that= is AD sponsored or published through the ISE). That would represent a stak= e in the ground and a reference point for future work. It would also allow = everyone (WG and authors) to move on.

=C2=A0

Again, Justin, thanks for your l= eadership.

=C2=A0

Adrian

=C2=A0

<= p class=3D"MsoNormal">From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin = Dean
Sent: 05 May 2016 04:49
To: manet@ietf.org
Subject: [manet]= AODVv2 Decision

=C2=A0

Working Group,

I will not be passing AODVv2 out of the working grou= p and to the IESG.=C2=A0 This was not an easy decision, nor one made lightl= y. However, despite many attempts to draft this email otherwise, I found I = could not justify AODVv2=E2=80=99s release. AODVv2 is released to the docum= ent editors. The following is the rationale for my decision.

There i= s insufficient consensus within MANET to make the passage appropriate.=C2= =A0 More importantly, perhaps, is that this lack of consensus is justified = by the significance of the outstanding issues.=C2=A0 These issues include: = security, metrics, multiple interface operation with shared ip addresses, p= ossible looping, non-symmetric links, ordering of processing operations, la= ck of jitter specification, removal of timeouts, and gateway limitations.= =C2=A0 Many of these issues have been discussed at length, and have apparen= t consensus solutions proposed and written up.=C2=A0 In fact, the progress = within the past month has been impressive.=C2=A0 Yet, to address these issu= es, the underlying protocol specification operation has changed within the = last call and I do not believe the document is without error.=C2=A0 The lac= k of reference implementation or analysis, in simulation or otherwise, rein= forces this concern. =C2=A0

Despite these flaws, I continue to belie= ve AODVv2 is better specified in many ways than AODV, as it acknowledges an= d attempts to solve issues AODV does not even mention such as: multiple int= erfaces (beyond a passing sentence), designed with security in mind, extend= able with the use of RFC5444, metric based routing built in, gateway suppor= t (although limited), bi-directional link checking.=C2=A0 There is value in= this draft and it is my hope that it can be published in some form. I am p= ersonally willing to help make that happen.

To the editors who worke= d so hard, you were given an impossible task: to address WG concerns, form = consensus and provide verifiable fixes within the timeframe provided.=C2=A0= When issuing the last call and doing my review I was not sure that it was = impossible, and held out hope until the very moment of this decision that i= t wasn=E2=80=99t.=C2=A0 I am sorry that I was mistaken.

The amount o= f work produced in the last month has been impressive but at this time I=E2= =80=99m not willing to pass it out of the working group.

Justin


______________________= _________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a1147636464d8c5053251e134-- From nobody Mon May 9 03:46:20 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DF012D0E0 for ; Mon, 9 May 2016 03:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPTqLwujHFIj for ; Mon, 9 May 2016 03:46:11 -0700 (PDT) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A36112D122 for ; Mon, 9 May 2016 03:46:09 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,600,1454976000"; d="scan'208,217"; a="34928861" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 09 May 2016 11:46:09 +0100 X-IronPort-AV: E=Sophos;i="5.24,600,1454976000"; d="scan'208,217";a="117229029" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 09 May 2016 11:46:07 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.88]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Mon, 9 May 2016 11:46:07 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: [manet] AODVv2 Decision Thread-Index: AQHRpoEZUsi8wlvJUkaIdO4+oBQJKp+rybgAgAAcs8CABIAacA== Date: Mon, 9 May 2016 10:46:06 +0000 Message-ID: References: <0c1f01d1a793$bff91be0$3feb53a0$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B3A15GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] AODVv2 Decision X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 10:46:16 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B3A15GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSBhbSBvZiB0aGUgdmlldyB0aGF0IHRoaXMgdW5kZXJlc3RpbWF0ZXMgdGhlIFdHIGNvbnRyaWJ1 dGlvbiwgYW5kIGFsc28gdGhhdCBvZiB0aGUgbW9yZSByZWNlbnQgbWVtYmVycyBvZiB0aGUgQU9E VnYyIHRlYW0sIHdobyBJIHRoaW5rIHJlYWxseSBoZWxwZWQgcHVzaCBpdCBmcm9tIGRlZmluaXRl bHkgdW5wdWJsaXNoYWJsZSB0byBnZXR0aW5nIHRoZXJlIChFeHBlcmltZW50YWwpLCBidXQgbm90 IHRoZXJlIHlldC4gQnV0IEnigJltIG5vdCBnb2luZyB0byBkaWcgaW50byB3aGF0IHNob3VsZCBv ciBzaG91bGQgbm90IGhhdmUgaGFwcGVuZWQuDQoNCk1vcmUgaW1wb3J0YW50bHksIGdvaW5nIGZv cndhcmQsIEkgdGhpbmsgdGhhdCBhIGJhZCBhcHByb2FjaCB0byB0aGVyZSBiZWluZyBhIGdvb2Qg c3BlY2lmaWNhdGlvbiBvZiBhIHJlYWN0aXZlIHJvdXRpbmcgcHJvdG9jb2wgYXMgYW4gUkZDIHdv dWxkIGJlIGlmICB0aGUgQU9EVnYyIGF1dGhvcnMgKGN1cnJlbnQgb3IgbW9kaWZpZWQgZ3JvdXAp IGRlY2lkZWQgdGhhdCBBT0R2djIgc2hvdWxkIGJlIHRoYXQgcHJvdG9jb2wgYnV0IHRoYXQgdGhl eSBubyBsb25nZXIgbmVlZGVkIC0gb3IganVzdCBubyBsb25nZXIgZ290IC0gdGhlIGlucHV0cyB0 aGF0IG90aGVycyAodXAgdG8gbm93LCB0aHJvdWdoIHRoZSBXRykgaGF2ZSBwcm92aWRlZCwgZXNw ZWNpYWxseSByZWNlbnRseS4gVGhlcmXigJlzIG5vIHN1Z2dlc3Rpb24gYmVlbiBtYWRlIHRoYXQg SeKAmXZlIHNlZW4gdGhhdCB0aGlzIGlzIHRoZSBwbGFuLCBidXQgd2l0aG91dCB0aGUgV0cgYXMg YSBzdHJ1Y3R1cmUgZm9yIHRoYXQsIEnigJltIG5vdCBzdXJlIGhvdyBvdXRzaWRlIGlucHV0IHNo b3VsZC93aWxsIGhhcHBlbi4gSSBub3RlIHRoYXQgZGV0YWlsZWQgY29tbWVudHMgZnJvbSBKdXN0 aW4sIFRob21hcywgVWxyaWNoIGFuZCBKaWF6aSwgYW5kIHNvbWUgb2JzZXJ2YXRpb25zIGZyb20g b3RoZXJzIChpbmNsdWRpbmcgbWUpIGFyZSBsYXJnZWx5IGZvY3Vzc2VkIG9uIHRoZSBzYW1lIGFy ZWFzLCB3aGljaCBKdXN0aW4gaGlnaGxpZ2h0ZWQgaW4gaGlzIHJlY2VudCBkZWNpc2lvbi4NCg0K T24gQU9EVnYyIGJlaW5nIGFuIGFkdmFuY2Ugb24gQU9EViwgYSBzdW1tYXJ5IG9mIHRoZSBpbXBy b3ZlbWVudHMgd291bGRu4oCZdCBnbyBhbWlzcywgcHJlc2VudGVkIHNvbWV3aGVyZS4NCg0KLS0N CkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3Rl bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVh dCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20v YWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50 ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMz NzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQs IFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQpTZW50OiAwNiBNYXkgMjAxNiAxMzoz NQ0KVG86ICdKdXN0aW4gRGVhbicNCkNjOiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21hbmV0XSBBT0RWdjIgRGVjaXNpb24NCg0KKioqIFdBUk5J TkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91 dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2Fn ZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBh biBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3 aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50 cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91 IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6 Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdo dHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMg c3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVu dC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMv RGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQpIaSBKdXN0aW4sDQoN CkkgaGF2ZSBiZWVuIGxhcmdlbHkgb3V0c2lkZSBNQU5FVCBzaW5jZSBzdGVwcGluZyBkb3duIGFz IEFELCBidXQgSSB3YW50IHRvIHRoYW5rIHlvdSBmb3IgdGhlIGNsYXJpdHkgb2YgdGhpcyBkZWNp c2lvbiBhbmQgdGhlIHRpbWUgSSBrbm93IHlvdSBoYXZlIHB1dCBpbiB0byBtYWtpbmcgaXQgdGhl IHJpZ2h0IGRlY2lzaW9uLg0KDQpBcyB5b3Ugc2F5LCB0aGUgdGVhbSB3b3JraW5nIG9uIEFPRFZ2 MiwgYW5kIENoYXJsaWUgaW4gcGFydGljdWxhciwgY2Fubm90IGJlIGZhdWx0ZWQgZm9yIHRoZSBs b25nIGhvdXJzIG9mIHRlY2huaWNhbCB3b3JrIHRoZXkgaGF2ZSBwdXQgaW4gb3ZlciB0aGUgeWVh cnMuIFRoZSBjaGFsbGVuZ2Ugd2FzIGZvcm1pZGFibGUsIGFuZCB0aGUgc3VwcG9ydCBpbiB0aGUg d29ya2luZyBncm91cCBzb21ld2hhdCBsaWdodC4gQW5kIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBB T0RWdjIgYXMgaXQgc3RhbmRzIGlzIGEgYmlnIHN0ZXAgZm9yd2FyZCBmcm9tIEFPRFYuDQoNCkkg ZG9uJ3Qgc2VlIHRoZSBjdXJyZW50IHNpdHVhdGlvbiBhcyBhIGZhaWx1cmUgYW5kIEkgd291bGQg dXJnZSB0aGUgYXV0aG9ycyB0byBkaXNjdXNzIHdpdGggdGhlIEFEIGhvdyBiZXN0IHRvIGNvbnZl cnQgdGhpcyB3b3JrIGludG8gYW4gUkZDIChwZXJoYXBzIGFzIGFuIEV4cGVyaW1lbnRhbCBkb2N1 bWVudCB0aGF0IGlzIEFEIHNwb25zb3JlZCBvciBwdWJsaXNoZWQgdGhyb3VnaCB0aGUgSVNFKS4g VGhhdCB3b3VsZCByZXByZXNlbnQgYSBzdGFrZSBpbiB0aGUgZ3JvdW5kIGFuZCBhIHJlZmVyZW5j ZSBwb2ludCBmb3IgZnV0dXJlIHdvcmsuIEl0IHdvdWxkIGFsc28gYWxsb3cgZXZlcnlvbmUgKFdH IGFuZCBhdXRob3JzKSB0byBtb3ZlIG9uLg0KDQpBZ2FpbiwgSnVzdGluLCB0aGFua3MgZm9yIHlv dXIgbGVhZGVyc2hpcC4NCg0KQWRyaWFuDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBEZWFuDQpTZW50OiAwNSBNYXkgMjAx NiAwNDo0OQ0KVG86IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFttYW5ldF0gQU9EVnYyIERlY2lzaW9uDQoNCldvcmtpbmcgR3JvdXAsDQoNCkkgd2lsbCBu b3QgYmUgcGFzc2luZyBBT0RWdjIgb3V0IG9mIHRoZSB3b3JraW5nIGdyb3VwIGFuZCB0byB0aGUg SUVTRy4gIFRoaXMgd2FzIG5vdCBhbiBlYXN5IGRlY2lzaW9uLCBub3Igb25lIG1hZGUgbGlnaHRs eS4gSG93ZXZlciwgZGVzcGl0ZSBtYW55IGF0dGVtcHRzIHRvIGRyYWZ0IHRoaXMgZW1haWwgb3Ro ZXJ3aXNlLCBJIGZvdW5kIEkgY291bGQgbm90IGp1c3RpZnkgQU9EVnYy4oCZcyByZWxlYXNlLiBB T0RWdjIgaXMgcmVsZWFzZWQgdG8gdGhlIGRvY3VtZW50IGVkaXRvcnMuIFRoZSBmb2xsb3dpbmcg aXMgdGhlIHJhdGlvbmFsZSBmb3IgbXkgZGVjaXNpb24uDQoNClRoZXJlIGlzIGluc3VmZmljaWVu dCBjb25zZW5zdXMgd2l0aGluIE1BTkVUIHRvIG1ha2UgdGhlIHBhc3NhZ2UgYXBwcm9wcmlhdGUu ICBNb3JlIGltcG9ydGFudGx5LCBwZXJoYXBzLCBpcyB0aGF0IHRoaXMgbGFjayBvZiBjb25zZW5z dXMgaXMganVzdGlmaWVkIGJ5IHRoZSBzaWduaWZpY2FuY2Ugb2YgdGhlIG91dHN0YW5kaW5nIGlz c3Vlcy4gIFRoZXNlIGlzc3VlcyBpbmNsdWRlOiBzZWN1cml0eSwgbWV0cmljcywgbXVsdGlwbGUg aW50ZXJmYWNlIG9wZXJhdGlvbiB3aXRoIHNoYXJlZCBpcCBhZGRyZXNzZXMsIHBvc3NpYmxlIGxv b3BpbmcsIG5vbi1zeW1tZXRyaWMgbGlua3MsIG9yZGVyaW5nIG9mIHByb2Nlc3Npbmcgb3BlcmF0 aW9ucywgbGFjayBvZiBqaXR0ZXIgc3BlY2lmaWNhdGlvbiwgcmVtb3ZhbCBvZiB0aW1lb3V0cywg YW5kIGdhdGV3YXkgbGltaXRhdGlvbnMuICBNYW55IG9mIHRoZXNlIGlzc3VlcyBoYXZlIGJlZW4g ZGlzY3Vzc2VkIGF0IGxlbmd0aCwgYW5kIGhhdmUgYXBwYXJlbnQgY29uc2Vuc3VzIHNvbHV0aW9u cyBwcm9wb3NlZCBhbmQgd3JpdHRlbiB1cC4gIEluIGZhY3QsIHRoZSBwcm9ncmVzcyB3aXRoaW4g dGhlIHBhc3QgbW9udGggaGFzIGJlZW4gaW1wcmVzc2l2ZS4gIFlldCwgdG8gYWRkcmVzcyB0aGVz ZSBpc3N1ZXMsIHRoZSB1bmRlcmx5aW5nIHByb3RvY29sIHNwZWNpZmljYXRpb24gb3BlcmF0aW9u IGhhcyBjaGFuZ2VkIHdpdGhpbiB0aGUgbGFzdCBjYWxsIGFuZCBJIGRvIG5vdCBiZWxpZXZlIHRo ZSBkb2N1bWVudCBpcyB3aXRob3V0IGVycm9yLiAgVGhlIGxhY2sgb2YgcmVmZXJlbmNlIGltcGxl bWVudGF0aW9uIG9yIGFuYWx5c2lzLCBpbiBzaW11bGF0aW9uIG9yIG90aGVyd2lzZSwgcmVpbmZv cmNlcyB0aGlzIGNvbmNlcm4uDQoNCkRlc3BpdGUgdGhlc2UgZmxhd3MsIEkgY29udGludWUgdG8g YmVsaWV2ZSBBT0RWdjIgaXMgYmV0dGVyIHNwZWNpZmllZCBpbiBtYW55IHdheXMgdGhhbiBBT0RW LCBhcyBpdCBhY2tub3dsZWRnZXMgYW5kIGF0dGVtcHRzIHRvIHNvbHZlIGlzc3VlcyBBT0RWIGRv ZXMgbm90IGV2ZW4gbWVudGlvbiBzdWNoIGFzOiBtdWx0aXBsZSBpbnRlcmZhY2VzIChiZXlvbmQg YSBwYXNzaW5nIHNlbnRlbmNlKSwgZGVzaWduZWQgd2l0aCBzZWN1cml0eSBpbiBtaW5kLCBleHRl bmRhYmxlIHdpdGggdGhlIHVzZSBvZiBSRkM1NDQ0LCBtZXRyaWMgYmFzZWQgcm91dGluZyBidWls dCBpbiwgZ2F0ZXdheSBzdXBwb3J0IChhbHRob3VnaCBsaW1pdGVkKSwgYmktZGlyZWN0aW9uYWwg bGluayBjaGVja2luZy4gIFRoZXJlIGlzIHZhbHVlIGluIHRoaXMgZHJhZnQgYW5kIGl0IGlzIG15 IGhvcGUgdGhhdCBpdCBjYW4gYmUgcHVibGlzaGVkIGluIHNvbWUgZm9ybS4gSSBhbSBwZXJzb25h bGx5IHdpbGxpbmcgdG8gaGVscCBtYWtlIHRoYXQgaGFwcGVuLg0KDQpUbyB0aGUgZWRpdG9ycyB3 aG8gd29ya2VkIHNvIGhhcmQsIHlvdSB3ZXJlIGdpdmVuIGFuIGltcG9zc2libGUgdGFzazogdG8g YWRkcmVzcyBXRyBjb25jZXJucywgZm9ybSBjb25zZW5zdXMgYW5kIHByb3ZpZGUgdmVyaWZpYWJs ZSBmaXhlcyB3aXRoaW4gdGhlIHRpbWVmcmFtZSBwcm92aWRlZC4gIFdoZW4gaXNzdWluZyB0aGUg bGFzdCBjYWxsIGFuZCBkb2luZyBteSByZXZpZXcgSSB3YXMgbm90IHN1cmUgdGhhdCBpdCB3YXMg aW1wb3NzaWJsZSwgYW5kIGhlbGQgb3V0IGhvcGUgdW50aWwgdGhlIHZlcnkgbW9tZW50IG9mIHRo aXMgZGVjaXNpb24gdGhhdCBpdCB3YXNu4oCZdC4gIEkgYW0gc29ycnkgdGhhdCBJIHdhcyBtaXN0 YWtlbi4NCg0KVGhlIGFtb3VudCBvZiB3b3JrIHByb2R1Y2VkIGluIHRoZSBsYXN0IG1vbnRoIGhh cyBiZWVuIGltcHJlc3NpdmUgYnV0IGF0IHRoaXMgdGltZSBJ4oCZbSBub3Qgd2lsbGluZyB0byBw YXNzIGl0IG91dCBvZiB0aGUgd29ya2luZyBncm91cC4NCg0KSnVzdGluDQoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpU aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50 ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3Rl bSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0 IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B3A15GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JIGFtIG9mIHRoZSB2aWV3IHRoYXQgdGhpcyB1bmRlcmVzdGltYXRlcyB0aGUgV0cgY29udHJp YnV0aW9uLCBhbmQgYWxzbyB0aGF0IG9mIHRoZSBtb3JlIHJlY2VudCBtZW1iZXJzIG9mIHRoZSBB T0RWdjIgdGVhbSwgd2hvIEkgdGhpbmsgcmVhbGx5IGhlbHBlZCBwdXNoIGl0DQogZnJvbSBkZWZp bml0ZWx5IHVucHVibGlzaGFibGUgdG8gZ2V0dGluZyB0aGVyZSAoRXhwZXJpbWVudGFsKSwgYnV0 IG5vdCB0aGVyZSB5ZXQuIEJ1dCBJ4oCZbSBub3QgZ29pbmcgdG8gZGlnIGludG8gd2hhdCBzaG91 bGQgb3Igc2hvdWxkIG5vdCBoYXZlIGhhcHBlbmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TW9yZSBpbXBvcnRhbnRs eSwgZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+b2lu ZyBmb3J3YXJkLCBJIHRoaW5rIHRoYXQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+YSBiYWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5hcHByb2FjaDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPnRvPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4gdGhlcmUgYmVpbmcgYSBnb29kIHNwZWNpZmljYXRpb24gb2YgYSByZWFjdGl2ZSByb3V0aW5n IHByb3RvY29sIGFzIGFuIFJGQyB3b3VsZA0KIGJlIGlmPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7dGhlDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFPRFZ2Mg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hdXRob3JzDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihjdXJyZW50IG9yIG1vZGlmaWVkIGdyb3VwKQ0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5kZWNpZGVk IHRoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hdCBB T0R2djIgc2hvdWxkIGJlIHRoYXQgcHJvdG9jb2wgYnV0IHRoYXQgdGhleQ0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ubyBsb25nZXIgbmVlZGVkPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4gLSBvciBqdXN0 IG5vIGxvbmdlciBnb3QgLTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+DQogdGhlIGlucHV0cyB0aGF0IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+b3RoZXJzICh1cCB0byBub3csIHRocm91Z2ggdGhlIFdHKTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+IGhhPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj52ZTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+DQogcHJvdmlkZWQ8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiwgZXNwZWNpYWxseSBy ZWNlbnRseTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Lg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVy ZeKAmXMgbm8gc3VnZ2VzdGlvbiBiZWVuIG1hZGUgdGhhdCBJ4oCZdmUgc2VlbiB0aGF0IHRoaXMg aXMgdGhlIHBsYW4sIGJ1dCB3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5pdGhvdXQgdGhlDQogV0cgYXMgYSBzdHJ1Y3R1cmUgZm9yIHRoYXQsIEnigJlt IG5vdCBzdXJlIGhvdyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPm91dHNpZGUgaW5wdXQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+c2hvdWxkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4vd2lsbDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+DQogaGFwcGVuLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgbm90ZSB0aGF0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4gZGV0YWlsZWQgY29tbWVudHMgZnJvbSBKdXN0aW4sIFRob21h cywgVWxyaWNoIGFuZCBKaWF6aSwgYW5kIHNvbWUNCiBvYnNlcnZhdGlvbnMgZnJvbSBvdGhlcnMg KGluY2x1ZGluZyBtZSkgYXJlIGxhcmdlbHkgZm9jdXNzZWQgb24gdGhlIHNhbWUgYXJlYXMsIHdo aWNoIEp1c3RpbiBoaWdobGlnaHRlZCBpbiBoaXMgcmVjZW50IGRlY2lzaW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ T24gQU9EVnYyIGJlaW5nIGFuIGFkdmFuY2Ugb24gQU9EViwgYSBzdW1tYXJ5IG9mIHRoZSBpbXBy b3ZlbWVudHMgd291bGRu4oCZdCBnbyBhbWlzcywgcHJlc2VudGVkIHNvbWV3aGVyZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVy IERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1z IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxi cj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7 JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8L2I+PGEgaHJlZj0i bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNB OEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5v bG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0K PGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4gc3R5bGU9ImNvbG9y OiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+ DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJl ZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZ UDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBtYW5ldCBbPGEgaHJlZj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5v cmciPm1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+QWRyaWFuIEZhcnJlbDxicj4NCjxiPlNlbnQ6PC9iPiAwNiBNYXkgMjAxNiAxMzozNTxicj4N CjxiPlRvOjwvYj4gJ0p1c3RpbiBEZWFuJzxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRv Om1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFttYW5ldF0gQU9EVnYyIERlY2lzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpj ZW50ZXIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPio8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKg0KPC9zcGFuPjwvc3Ryb25n Pjwvc3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldBUk5JTkcNCjwvc3Bh bj48L3N0cm9uZz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKio8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91 ciBvcmdhbml6YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3Bh ZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu dGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxl bT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBv cmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBl eHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lk ZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4g YW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9u Zz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFu PjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcy Ij4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xp Y2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+ Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+ PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywg cGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNv bS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGgl MjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2Vt Pjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rpbiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgaGF2ZSBiZWVuIGxhcmdlbHkgb3V0c2lkZSBNQU5FVCBzaW5jZSBzdGVwcGluZyBk b3duIGFzIEFELCBidXQgSSB3YW50IHRvIHRoYW5rIHlvdSBmb3IgdGhlIGNsYXJpdHkgb2YgdGhp cyBkZWNpc2lvbiBhbmQgdGhlIHRpbWUgSSBrbm93IHlvdSBoYXZlIHB1dCBpbiB0bw0KIG1ha2lu ZyBpdCB0aGUgcmlnaHQgZGVjaXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyB5b3Ugc2F5LCB0aGUgdGVhbSB3 b3JraW5nIG9uIEFPRFZ2MiwgYW5kIENoYXJsaWUgaW4gcGFydGljdWxhciwgY2Fubm90IGJlIGZh dWx0ZWQgZm9yIHRoZSBsb25nIGhvdXJzIG9mIHRlY2huaWNhbCB3b3JrIHRoZXkgaGF2ZSBwdXQg aW4gb3ZlciB0aGUgeWVhcnMuIFRoZQ0KIGNoYWxsZW5nZSB3YXMgZm9ybWlkYWJsZSwgYW5kIHRo ZSBzdXBwb3J0IGluIHRoZSB3b3JraW5nIGdyb3VwIHNvbWV3aGF0IGxpZ2h0LiBBbmQgSSBhZ3Jl ZSB3aXRoIHlvdSB0aGF0IEFPRFZ2MiBhcyBpdCBzdGFuZHMgaXMgYSBiaWcgc3RlcCBmb3J3YXJk IGZyb20gQU9EVi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb24ndCBzZWUgdGhlIGN1cnJlbnQgc2l0dWF0aW9u IGFzIGEgZmFpbHVyZSBhbmQgSSB3b3VsZCB1cmdlIHRoZSBhdXRob3JzIHRvIGRpc2N1c3Mgd2l0 aCB0aGUgQUQgaG93IGJlc3QgdG8gY29udmVydCB0aGlzIHdvcmsgaW50byBhbiBSRkMgKHBlcmhh cHMgYXMgYW4NCiBFeHBlcmltZW50YWwgZG9jdW1lbnQgdGhhdCBpcyBBRCBzcG9uc29yZWQgb3Ig cHVibGlzaGVkIHRocm91Z2ggdGhlIElTRSkuIFRoYXQgd291bGQgcmVwcmVzZW50IGEgc3Rha2Ug aW4gdGhlIGdyb3VuZCBhbmQgYSByZWZlcmVuY2UgcG9pbnQgZm9yIGZ1dHVyZSB3b3JrLiBJdCB3 b3VsZCBhbHNvIGFsbG93IGV2ZXJ5b25lIChXRyBhbmQgYXV0aG9ycykgdG8gbW92ZSBvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkFnYWluLCBKdXN0aW4sIHRoYW5rcyBmb3IgeW91ciBsZWFkZXJzaGlwLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QWRyaWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWFuZXQgWzxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkp1c3RpbiBEZWFuPGJyPg0KPGI+U2VudDo8L2I+IDA1IE1heSAyMDE2IDA0 OjQ5PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0 QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbWFuZXRdIEFPRFZ2MiBEZWNpc2lv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X b3JraW5nIEdyb3VwLDxicj4NCjxicj4NCkkgd2lsbCBub3QgYmUgcGFzc2luZyBBT0RWdjIgb3V0 IG9mIHRoZSB3b3JraW5nIGdyb3VwIGFuZCB0byB0aGUgSUVTRy4mbmJzcDsgVGhpcyB3YXMgbm90 IGFuIGVhc3kgZGVjaXNpb24sIG5vciBvbmUgbWFkZSBsaWdodGx5LiBIb3dldmVyLCBkZXNwaXRl IG1hbnkgYXR0ZW1wdHMgdG8gZHJhZnQgdGhpcyBlbWFpbCBvdGhlcndpc2UsIEkgZm91bmQgSSBj b3VsZCBub3QganVzdGlmeSBBT0RWdjLigJlzIHJlbGVhc2UuIEFPRFZ2MiBpcyByZWxlYXNlZCB0 byB0aGUNCiBkb2N1bWVudCBlZGl0b3JzLiBUaGUgZm9sbG93aW5nIGlzIHRoZSByYXRpb25hbGUg Zm9yIG15IGRlY2lzaW9uLjxicj4NCjxicj4NClRoZXJlIGlzIGluc3VmZmljaWVudCBjb25zZW5z dXMgd2l0aGluIE1BTkVUIHRvIG1ha2UgdGhlIHBhc3NhZ2UgYXBwcm9wcmlhdGUuJm5ic3A7IE1v cmUgaW1wb3J0YW50bHksIHBlcmhhcHMsIGlzIHRoYXQgdGhpcyBsYWNrIG9mIGNvbnNlbnN1cyBp cyBqdXN0aWZpZWQgYnkgdGhlIHNpZ25pZmljYW5jZSBvZiB0aGUgb3V0c3RhbmRpbmcgaXNzdWVz LiZuYnNwOyBUaGVzZSBpc3N1ZXMgaW5jbHVkZTogc2VjdXJpdHksIG1ldHJpY3MsIG11bHRpcGxl IGludGVyZmFjZQ0KIG9wZXJhdGlvbiB3aXRoIHNoYXJlZCBpcCBhZGRyZXNzZXMsIHBvc3NpYmxl IGxvb3BpbmcsIG5vbi1zeW1tZXRyaWMgbGlua3MsIG9yZGVyaW5nIG9mIHByb2Nlc3Npbmcgb3Bl cmF0aW9ucywgbGFjayBvZiBqaXR0ZXIgc3BlY2lmaWNhdGlvbiwgcmVtb3ZhbCBvZiB0aW1lb3V0 cywgYW5kIGdhdGV3YXkgbGltaXRhdGlvbnMuJm5ic3A7IE1hbnkgb2YgdGhlc2UgaXNzdWVzIGhh dmUgYmVlbiBkaXNjdXNzZWQgYXQgbGVuZ3RoLCBhbmQgaGF2ZSBhcHBhcmVudA0KIGNvbnNlbnN1 cyBzb2x1dGlvbnMgcHJvcG9zZWQgYW5kIHdyaXR0ZW4gdXAuJm5ic3A7IEluIGZhY3QsIHRoZSBw cm9ncmVzcyB3aXRoaW4gdGhlIHBhc3QgbW9udGggaGFzIGJlZW4gaW1wcmVzc2l2ZS4mbmJzcDsg WWV0LCB0byBhZGRyZXNzIHRoZXNlIGlzc3VlcywgdGhlIHVuZGVybHlpbmcgcHJvdG9jb2wgc3Bl Y2lmaWNhdGlvbiBvcGVyYXRpb24gaGFzIGNoYW5nZWQgd2l0aGluIHRoZSBsYXN0IGNhbGwgYW5k IEkgZG8gbm90IGJlbGlldmUgdGhlIGRvY3VtZW50DQogaXMgd2l0aG91dCBlcnJvci4mbmJzcDsg VGhlIGxhY2sgb2YgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIG9yIGFuYWx5c2lzLCBpbiBzaW11 bGF0aW9uIG9yIG90aGVyd2lzZSwgcmVpbmZvcmNlcyB0aGlzIGNvbmNlcm4uICZuYnNwOzxicj4N Cjxicj4NCkRlc3BpdGUgdGhlc2UgZmxhd3MsIEkgY29udGludWUgdG8gYmVsaWV2ZSBBT0RWdjIg aXMgYmV0dGVyIHNwZWNpZmllZCBpbiBtYW55IHdheXMgdGhhbiBBT0RWLCBhcyBpdCBhY2tub3ds ZWRnZXMgYW5kIGF0dGVtcHRzIHRvIHNvbHZlIGlzc3VlcyBBT0RWIGRvZXMgbm90IGV2ZW4gbWVu dGlvbiBzdWNoIGFzOiBtdWx0aXBsZSBpbnRlcmZhY2VzIChiZXlvbmQgYSBwYXNzaW5nIHNlbnRl bmNlKSwgZGVzaWduZWQgd2l0aCBzZWN1cml0eSBpbiBtaW5kLA0KIGV4dGVuZGFibGUgd2l0aCB0 aGUgdXNlIG9mIFJGQzU0NDQsIG1ldHJpYyBiYXNlZCByb3V0aW5nIGJ1aWx0IGluLCBnYXRld2F5 IHN1cHBvcnQgKGFsdGhvdWdoIGxpbWl0ZWQpLCBiaS1kaXJlY3Rpb25hbCBsaW5rIGNoZWNraW5n LiZuYnNwOyBUaGVyZSBpcyB2YWx1ZSBpbiB0aGlzIGRyYWZ0IGFuZCBpdCBpcyBteSBob3BlIHRo YXQgaXQgY2FuIGJlIHB1Ymxpc2hlZCBpbiBzb21lIGZvcm0uIEkgYW0gcGVyc29uYWxseSB3aWxs aW5nIHRvIGhlbHAgbWFrZQ0KIHRoYXQgaGFwcGVuLjxicj4NCjxicj4NClRvIHRoZSBlZGl0b3Jz IHdobyB3b3JrZWQgc28gaGFyZCwgeW91IHdlcmUgZ2l2ZW4gYW4gaW1wb3NzaWJsZSB0YXNrOiB0 byBhZGRyZXNzIFdHIGNvbmNlcm5zLCBmb3JtIGNvbnNlbnN1cyBhbmQgcHJvdmlkZSB2ZXJpZmlh YmxlIGZpeGVzIHdpdGhpbiB0aGUgdGltZWZyYW1lIHByb3ZpZGVkLiZuYnNwOyBXaGVuIGlzc3Vp bmcgdGhlIGxhc3QgY2FsbCBhbmQgZG9pbmcgbXkgcmV2aWV3IEkgd2FzIG5vdCBzdXJlIHRoYXQg aXQgd2FzIGltcG9zc2libGUsIGFuZA0KIGhlbGQgb3V0IGhvcGUgdW50aWwgdGhlIHZlcnkgbW9t ZW50IG9mIHRoaXMgZGVjaXNpb24gdGhhdCBpdCB3YXNu4oCZdC4mbmJzcDsgSSBhbSBzb3JyeSB0 aGF0IEkgd2FzIG1pc3Rha2VuLjxicj4NCjxicj4NClRoZSBhbW91bnQgb2Ygd29yayBwcm9kdWNl ZCBpbiB0aGUgbGFzdCBtb250aCBoYXMgYmVlbiBpbXByZXNzaXZlIGJ1dCBhdCB0aGlzIHRpbWUg SeKAmW0gbm90IHdpbGxpbmcgdG8gcGFzcyBpdCBvdXQgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuPGJy Pg0KPGJyPg0KSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cD4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKjxicj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFz ZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZ b3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Ns b3NlIG9yPGJyPgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxi cj4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKio8L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B3A15GLKXM0002VGREEN_-- From nobody Mon May 9 04:35:33 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A489912B05C for ; Mon, 9 May 2016 04:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydP_p05f9vRB for ; Mon, 9 May 2016 04:35:29 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B37D12D128 for ; Mon, 9 May 2016 04:26:50 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id u64so196781222lff.3 for ; Mon, 09 May 2016 04:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=dp79Gv6gsKohSNYIA/mshbWCji/juGaHh94QiRgiIec=; b=tEH5hKNHbSdL6KioIsEX6Abao67kKQFqHCIjS1v0l3u15Rc0PXD9k27mUEf3aQGeoD JnOC70Hd4j53ung1yUibkdwqYV6ASVbzeJHl9L4EwBSboTH9NTBnCa7ybuPnDTNagvOL 4IPBpf0KC0FPj0a/pdb9fMMPTNXMv8AjA/rj7WTmi6724hAe4tJXMtq+E3Nlxm4/QMh4 b8mNBl9hBbdlwu9r1UMh5eyGH8nvPSnWO9P8bBk7ZthpY878GBzCuCfFtoBk6nd/moQm WlbkngSORMhjMAMzMpBMQgOjS5hPg9go024QdTphbMdyPzIN631TTcdWo6jq4Sg+CTi6 m2xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dp79Gv6gsKohSNYIA/mshbWCji/juGaHh94QiRgiIec=; b=WQJlQnejntyGnVf0zS6O//CbqlcrtPDKcJSsdMO9C8LT6reYP/EgggHSM3HFMMNyF5 jdFckFAuFvgxkksHv2ThHA8ZepSzyZPTWTDouFQPE19Dv4sbNBgmmkRgb+3EeDRyKKx6 KDXTgoDBwu92G7JNUhp5U0Gc0o9skFFaAqMozMwt/nIuQaOMyOOWDU6DuHeXDCMAYJSb 4nsHIaTGgqRWkCH0CwHEU/r0z1oUiIBi+COqcxleOIRMxZGYIyfqWpCH9DfEimDw2Sl8 +XSX5IVQ9DLFRDeRPmQ8UHV4ZqgTq0wncUu6K5xbPYb0j8IDcBwkFhX4hfFpHIDb8j/b rzuQ== X-Gm-Message-State: AOPr4FWsIPB5MW+gj+gRB7vBDZQlzSQzYE73EeVYstriUk5o5NkLT8A9JE+GEBOI4aCuAOw+BFBlF3e8NKiQKw== MIME-Version: 1.0 X-Received: by 10.112.181.196 with SMTP id dy4mr14796543lbc.42.1462793208463; Mon, 09 May 2016 04:26:48 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.114.77.4 with HTTP; Mon, 9 May 2016 04:26:48 -0700 (PDT) In-Reply-To: References: <82679804-2647-4913-ACF3-18E4FFF731A8@thomasclausen.org> Date: Mon, 9 May 2016 13:26:48 +0200 X-Google-Sender-Auth: rt4Sa_d5sacJl-1pf8b8UoPTys0 Message-ID: From: Jiazi YI To: Stan Ratliff Content-Type: multipart/alternative; boundary=001a11c36f5c920cc60532671572 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Recharter Discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 11:35:33 -0000 --001a11c36f5c920cc60532671572 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Wed, May 4, 2016 at 2:30 AM, Stan Ratliff wrote: > Christopher/All, > > Time to pick this discussion up again. What type of buy-in do you think i= s > necessary? On the one hand, you discuss a "small team of authors"; on the > other, you mention that we're "way short of what we really need in terms = of > buy-in". > > There has been interest expressed in addressing the MCAST issue, and > volunteers (specifically, Justin, and probably Brian) to submit work. The= re > is also a small number of potential authors interested in a few (three or > so) DLEP extensions. Is there any OLSRv2 work on the horizon? > Personally, I have interests in OLSRv2 source-destination routing, and possible extensions to make OLSRv2 more scalable (fish-eye? or even hierarchical)? The multipath extension is for experimental track -- hopefully it can be last called soon. If there are interests on it, we can think about the possibility of pushing it towards standard track after the experimental RFC is published. I will try to participate the interim meeting, but not sure yet. cheers Jiazi > Is there a definable, manageable problem space for things like > cryptographic key management in ad hoc networks? > > We need to either come to consensus on a 12-18 month charter, or be > prepared to close the WG. What is the interest level? > > Regards, > Stan > > > > On Wed, Apr 27, 2016 at 12:35 PM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > >> OK, you know there are some people at NRL. Good. But still quite a way >> short of what we really need in terms of buy-in. (I=E2=80=99m assuming t= he people >> at NRL are represented by you and/or Brian, as otherwise even they aren= =E2=80=99t >> showing up.) >> >> >> >> *-- * >> >> >> >> >> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied >> Intelligence Laboratories * >> *_______________________________________________________________________= ___ >> * >> *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com >> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great >> Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >> >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >> >> >> >> *From:* Justin Dean [mailto:bebemaster@gmail.com] >> *Sent:* 27 April 2016 16:45 >> *To:* Dearlove, Christopher (UK) >> *Cc:* Thomas Heide Clausen; manet@ietf.org >> *Subject:* Re: [manet] Recharter Discussion >> >> >> >> >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.* >> >> * Consider carefully whether you should click on any links, open any >> attachments or reply. For information regarding **Red Flags** that you >> can look out for in emails you receive, click here >> .* >> * If you feel the email is suspicious, please follow this process >> .* >> >> >> >> >> >> On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> wrote: >> >> The key points as I see it are: >> >> - We shouldn=E2=80=99t wait for telecon, and can=E2=80=99t rely on telec= on and cut out >> list. >> >> I agree. We shouldn't wait for the telecon. I'll continue to engage >> everyone on this list about what people are willing to work on. >> >> >> - We are very short of contributors. Many who have contributed have >> dropped away. And those who have been main creators of WG RFCs (looking = at >> statistics, Clausen and Dearlove in particular, but also others - but no= t a >> lot of others, especially after the first batch of Experimental RFCs) ma= y >> or may not be contributing. >> >> We are short contributors and we may be able to get more by focusing the >> group on specific issues and possibly creating new focused groups to inv= ite >> a larger/wider IETF involvement. Security being the one coming to mind. >> Your mention on the list about security stuff that you are interested in >> hasn't brought a lot of discussion on this list but it very well may bri= ng >> a lot of interest from the larger ietf community. >> >> >> >> - But even more importantly we need real people (preferably companies >> with products) using our protocols with real problems. DLEP I think has >> some real adaptors, though I think most are waiting for an RFC. OLSRv2 i= s >> short on companies advertising they are using it - I wish some would (I= =E2=80=99m >> told they exist, but couldn=E2=80=99t name any). AODVv2 (which may or ma= y not be in >> scope) appears not to have even up to date experimental code (please >> correct if wrong). >> >> - Hence although we may have some great ideas, it=E2=80=99s not yet clea= r people >> want them and we can deliver - DLEP maintenance being I think closest to >> contradicting that, at least publicly. >> >> Well I KNOW that here at NRL we have the real people and prototype >> products relating to the multicast issue that it can happen. The key iss= ue >> is making sure there are enough people willing to contribute and enginee= r a >> solution to an issue that needs solving. >> >> >> >> There is the horrible warning of Autoconf that went wrong in several >> ways, but at the end, had no one who would do the work (which is a lot o= f >> work, taking longer than you expect) to create a draft and take it all t= he >> way. And that means a small team of actual authors, plus wider input. >> >> >> >> Incidentally the autoconf problem is still real, but was too narrow. Tha= t >> was considering address autoconfiguration (though the WG never actually = got >> there). As I see it, there=E2=80=99s an inseparable (in terms of thinkin= g about it, >> drafts may of course separate out details) issue that is of address >> assignment, identity assignment/management, cryptographic key management= , >> and other forms of management (network management). And several chicken = and >> egg problems that arise in them, especially in ad hoc networks. >> >> I think the issue with autoconf is that it was attempting to solve to >> broad a problem. There were demonstratable solutions to very specific >> problems (e.g. multihop DHCP) but then there were more exotic solutions = to >> more complex problems like DAD in disconnected partitioning/merging >> networks. If we can focus on a specific well defined problem space I thi= nk >> we'll be fine. >> >> >> >> *-- * >> >> >> >> >> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied >> Intelligence Laboratories * >> *_______________________________________________________________________= ___ >> * >> *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com >> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great >> Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >> >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >> >> >> >> *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Thomas >> Heide Clausen >> *Sent:* 26 April 2016 22:01 >> *To:* Justin Dean >> *Cc:* manet@ietf.org >> *Subject:* Re: [manet] Recharter Discussion >> >> >> >> >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.* >> >> * Consider carefully whether you should click on any links, open any >> attachments or reply. For information regarding **Red Flags** that you >> can look out for in emails you receive, click here >> .* >> * If you feel the email is suspicious, please follow this process >> .* >> >> **** **WARNING ****** >> EXTERNAL EMAIL -- This message originates from outside our organization. >> >> >> >> >> >> >> On 26 avr. 2016, at 22:21, Justin Dean wrote: >> >> Thomas I understand your concerns but we have mostly gone over this >> before in previous meetings. >> >> >> >> The IETF conducts is business on mailing lists. >> >> >> >> My recollection is that the strawman charter was presented once in a WG >> meeting, then the chairs did not animate any charter discussion for seve= ral >> IETFs, on the list (nor was the charter discussed in subsequent meetings= ) - >> until this present "urgency" was declared (by the chairs) to the WG. >> >> >> >> The AD will not allow us to meet at the next IETF meeting if we do not >> have a new charter and new work items. >> >> >> >> That does not negate my point, however, which was that: >> >> >> >> it should be established on the list that there are *meaningful things >> to do*, and there's a *meaningful critical mass of people to be doing >> those things*, before a (virtual) interim is called. Brainstorming on a >> teleconference is rarely a constructive way to spend time >> >> >> >> >> >> Thomas >> >> >> >> To your point it's imparative that the discussion continues on list abou= t >> the charter. With that in mind here is a suggested edit of the previous= ly >> floated charter, with comments in () with JWD tags. >> >> The purpose of the MANET working group is to standardize IP routing prot= ocol functionality suitable for wireless routing application within both st= atic and dynamic topologies with increased dynamics due to node motion or o= ther factors. >> >> >> >> Approaches are intended to be relatively lightweight in nature, suitable= for multiple hardware and wireless environments, and address scenarios whe= re MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh in= frastructures (e.g., a mixture of fixed and mobile routers) should also be = supported by MANET specifications and management features. >> >> >> >> The MANET WG is responsible for the maintenance of OLSRv2, AODVv2 (JWD T= BD), DLEP and NHPD. Of particular interest: security enhancements, and encr= yption security extensions for RFC5444. (JWD we may want to break this out = of the WG and make a new MANET Sec working group to grab the attention of t= hose interested in security and get their participation.) >> >> >> >> The MANET WG will standardize a multicast MANET protocol framework based= on previous work and lessons learned for scoped forwarding within MANET ne= tworks. As part of this framework the WG will produce a well defined MANET= multicast forwarding information base. >> >> >> >> The WG will produce an informational draft outlining challenges and best= practices for deploying and managing MANET networks. >> >> >> >> The MANET WG will interact with the PIM working group on issues relating= to the multicast work. The WG will also pay attention to other IETF and I= RTF work that is addressing topics related to MANET environments. >> >> >> >> In summary, the WG will develop the following drafts: >> >> >> >> MANET Management Document (Informational) >> >> MANET Maintenance >> >> - RFC5444 Security extension (Standards) (JWD possibly move this to new= working group) >> >> MANET Multicast >> >> - Multicast FIB (Standards) >> >> >> >> >> >> >> >> On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen >> wrote: >> >> Hi, >> >> >> >> I believe that an virtual interim is premature: a teleconference is, >> mechanically, less inclusive than are mailing list discussions (time-zon= es, >> other commitments, requirement of synchronicity of participation, etc.). >> >> >> >> Furthermore.... >> >> >> >> Until such time that a strawman charter is proposed, *updated to reflect >> the reality of the group* as stipulated by the AD and by Mr. Dean, as >> well as additional charter items emerging on the list, and *with >> relatively broad and deep support* for the included items by the working >> group, having an interim - virtual or otherwise - is not constructive. >> >> >> >> In other words, it should be established on the list that there are *mea= ningful >> things to do*, and there's a *meaningful critical mass of people to be >> doing those things*, before a (virtual) interim is called. Brainstorming >> on a teleconference is rarely a constructive way to spend time. >> >> >> >> Best, >> >> >> >> Thomas >> >> >> >> Sent from my iPad >> >> >> >> On 22 Apr 2016, at 17:50, Stan Ratliff wrote: >> >> Hello WG, >> >> >> >> Do we need to hold an interim meeting (via WebEX) to discuss? I'd like t= o >> get opinions on the list about that. We'll need a couple of weeks to >> schedule, but we can do that. >> >> >> >> One other point inline: >> >> >> >> On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> wrote: >> >> Multicast is the obvious top item. Lots of possible approaches, time to >> discuss. >> >> >> >> Gateways for AODVv2 at Standard is obviously not possible since AODVv2 i= s >> going to be Experimental at most. >> >> >> >> Management we did of course have an NHDP/OLSRv2 draft killed by AD. Whic= h >> since NHDP/OLSRv2 us all we have (SMF excepted) that was a bit tricky. >> >> >> >> I would have to make an IPR declaration to say some of what I might have >> to say about encryption. Not today. >> >> >> >> Understood. But please remember - there's only about a 5-week gap now >> before the charter needs to be complete in order for the WG to meet in >> Berlin. >> >> >> >> Regards, >> >> Stan >> >> >> >> >> >> >> >> >> >> Missing from the list is any work on OLSRv2 (or NHDP). MT-OLSRv2 is >> experimental. That would need implementation tests to advance to PS. Any= one >> interested in that (I=E2=80=99m not saying I can)? >> >> >> >> More broadly on OLSRv2 there are various things that could be done, but >> what is really needed is people with a real application. Any that exist >> were frightened away from this group. >> >> >> >> *-- * >> >> >> >> >> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied >> Intelligence Laboratories * >> *_______________________________________________________________________= ___ >> * >> *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com >> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great >> Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >> >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >> >> >> >> *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean >> *Sent:* 22 April 2016 16:07 >> *To:* manet@ietf.org >> *Subject:* [manet] Recharter Discussion >> >> >> >> >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.* >> >> * Consider carefully whether you should click on any links, open any >> attachments or reply. For information regarding **Red Flags** that you >> can look out for in emails you receive, click here >> .* >> * If you feel the email is suspicious, please follow this process >> .* >> >> **** **WARNING ****** >> EXTERNAL EMAIL -- This message originates from outside our organization. >> >> >> >> I'll start things off by floating the draft re-charter which was >> presented in Prague. >> >> The purpose of the MANET working group is to standardize IP routing prot= ocol functionality suitable for wireless routing application within both st= atic and dynamic topologies with increased dynamics due to node motion or o= ther factors. >> >> >> >> Approaches are intended to be relatively lightweight in nature, suitable= for multiple hardware and wireless environments, and address scenarios whe= re MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh in= frastructures (e.g., a mixture of fixed and mobile routers) should also be = supported by MANET specifications and management features. >> >> >> >> The MANET WG is responsible for the maintenance of OLSRv2, AODVv2, DLEP = and NHPD. Of particular interest: border behavior between MANET networks an= d fixed IP network infrastructures, enhance AODVv2 gateway functionality; s= ecurity enhancements, encryption security extensions for RFC5444. >> >> >> >> The MANET WG will standardize a multicast MANET protocol framework based= on previous work and lessons learned for scoped forwarding within MANET ne= tworks. As part of this framework the WG will produce a well defined MANET= multicast forwarding information base. >> >> >> >> The WG will produce an informational draft outlining challenges and best= practices for deploying and managing MANET networks. >> >> >> >> The MANET WG will interact with the PIM working group on issues relating= to the multicast work. The WG will also pay attention to other IETF and I= RTF work that is addressing topics related to MANET environments. >> >> >> >> In summary, the WG will develop the following drafts: >> >> >> >> MANET Management Document (Informational) >> >> MANET Maintenance >> >> - RFC5444 Security extension (Standards) >> >> - Enhanced AODVv2 gateway extension (Standards) >> >> MANET Multicast >> >> - Multicast FIB (Standards) >> >> >> >> >> >> This will likely be considered too broad to pass. We will likely need t= o cut some and focus the work. For me personally I know I have the time an= d backing to work on the Multicast piece. >> >> >> >> Justin >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11c36f5c920cc60532671572 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

On Wed, May 4, 2016 at 2:30 AM, Stan Ratliff <ratliffstan= @gmail.com> wrote:
Christopher/All,

Time to pi= ck this discussion up again. What type of buy-in do you think is necessary?= On the one hand, you discuss a "small team of authors"; on the o= ther, you mention that we're "way short of what we really need in = terms of buy-in".

There has been interest expressed in a= ddressing the MCAST issue, and volunteers (specifically, Justin, and probab= ly Brian) to submit work. There is also a small number of potential authors= interested in a few (three or so) DLEP extensions. Is there any OLSRv2 wor= k on the horizon?

= Personally, I have interests in OLSRv2 source-destination routing, and poss= ible extensions to make OLSRv2 more scalable (fish-eye? or even hierarchica= l)?=C2=A0
The multipath extension is for experimental track -- ho= pefully it can be last called soon. If there are interests on it, we can th= ink about the possibility of pushing it towards standard track after the ex= perimental RFC is published.=C2=A0

I will try to p= articipate the interim meeting, but not sure yet.=C2=A0

cheers

Jiazi


=C2=A0
<= div>
Is there a definable, manageable problem space for things like cry= ptographic key management in ad hoc networks?

We need to eith= er come to consensus on a 12-18 month charter, or be prepared to close the = WG. What is the interest level?

Regards,
Stan



On Wed, Apr 27, 2016 at 12:35 PM, Dear= love, Christopher (UK) <chris.dearlove@baesystems.com><= /span> wrote:

OK, you know there are so= me people at NRL. Good. But still quite a way short of what we really need = in terms of buy-in. (I=E2=80=99m assuming the people at NRL are represented by you and/or Brian, as otherwise even they aren=E2=80=99t sho= wing up.)

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: Justin Dean [mailto:bebemaster@gmail.com]
Sent: 27 April 2016 16:45
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; manet@ietf.org
Subject: Re: [manet] Recharter Discussion

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments= or reply.
For= information regarding Red Flags that you can look out for in emails you receive, click here.
If = you feel the email is suspicious, please follow this process.<= /u>

=C2=A0

=C2=A0

On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

The key points as I see i= t are:

- We shouldn=E2=80=99t wa= it for telecon, and can=E2=80=99t rely on telecon and cut out list.<= u>

I agree.=C2=A0 We shouldn't wait for the telecon= .=C2=A0 I'll continue to engage everyone on this list about what people= are willing to work on.
=C2=A0

- We are very short of co= ntributors. Many who have contributed have dropped away. And those who have been main creators of WG RFCs (looking at statistics, Clausen and Dearlove= in particular, but also others - but not a lot of others, especially after= the first batch of Experimental RFCs) may or may not be contributing.

We are short contributors and we may be able to get = more by focusing the group on specific issues and possibly creating new foc= used groups to invite a larger/wider IETF involvement.=C2=A0 Security being= the one coming to mind.=C2=A0 Your mention on the list about security stuff that you are interested in hasn't bro= ught a lot of discussion on this list but it very well may bring a lot of i= nterest from the larger ietf community.=C2=A0

=C2=A0

- But even more important= ly we need real people (preferably companies with products) using our proto= cols with real problems. DLEP I think has some real adaptors, though I think mo= st are waiting for an RFC. OLSRv2 is short on companies advertising they ar= e using it - I wish some would (I=E2=80=99m told they exist, but couldn=E2= =80=99t name any). AODVv2 (which may or may not be in scope) appears not to have even up to date experimental code (please co= rrect if wrong).

- Hence although we may h= ave some great ideas, it=E2=80=99s not yet clear people want them and we ca= n deliver - DLEP maintenance being I think closest to contradicting that, at least p= ublicly.

Well I KNOW that here at NRL we have the real people= and prototype products relating to the multicast issue that it can happen.= The key issue is making sure there are enough people willing to contribute= and engineer a solution to an issue that needs solving.

=C2=A0=C2=A0

There is the horrible war= ning of Autoconf that went wrong in several ways, but at the end, had no one who would do the work (which is a lot of work, taking longer than you = expect) to create a draft and take it all the way. And that means a small t= eam of actual authors, plus wider input.

=C2=A0

Incidentally the autoconf= problem is still real, but was too narrow. That was considering address autoconfiguration (though the WG never actually got there). As I see it, t= here=E2=80=99s an inseparable (in terms of thinking about it, drafts may of= course separate out details) issue that is of address assignment, identity= assignment/management, cryptographic key management, and other forms of management (network management). And severa= l chicken and egg problems that arise in them, especially in ad hoc network= s.

I think the issue with autoconf is that it was attem= pting to solve to broad a problem.=C2=A0 There were demonstratable solution= s to very specific problems (e.g. multihop DHCP) but then there were more e= xotic solutions to more complex problems like DAD in disconnected partitioning/merging networks. If we can focus on= a specific well defined problem space I think we'll be fine. =C2=A0=C2= =A0

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)12= 45 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: manet [mailto:manet-= bounces@ietf.org] On Behalf Of Thomas Heide Clausen
Sent: 26 April 2016 22:01
To: Justin Dean
Cc: manet@ietf.o= rg
Subject: Re: [manet] Recharter Discussion

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments= or reply.
For= information regarding Red Flags that you can look out for in emails you receive, click here.
If = you feel the email is suspicious, please follow this process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside ou= r organization.

=C2=A0

=C2=A0<= /p>


On 26 avr. 2016, at 22:21, Justin Dean <bebemaster@gmail.com> wrote:=

Thomas I understand your concerns but we have mostly= gone over this before in previous meetings.

=C2=A0

The IETF conducts is business on mailing lists.

=C2=A0

My recollection is that the strawman charter was pre= sented once in a WG meeting, then the chairs did not animate any charter di= scussion for several IETFs, on the list (nor was the charter discussed in subsequent meetings) - until this present "urgen= cy" was declared (by the chairs) to the WG.

=C2=A0<= /p>

The AD will not allow us to meet at the next IETF me= eting if we do not have a new charter and new work items.=C2=A0

=C2=A0

That does not negate my point, however, which was th= at:

=C2=A0

it should be established= on the list that there are=C2=A0meaningful things to do, and= there's a=C2=A0meaningful critical mass of people to be doing those things, before a (virtual) interim is called. Brainsto= rming on a teleconference is rarely a constructive way to spend time=

=C2=A0

=C2=A0

Thomas

=C2=A0<= /p>

To your point it'= s imparative that the discussion continues on list about the charter.=C2=A0= With that in mind here is a suggested edit of the previously floated chart= er, with comments in () with JWD tags.

The purpose of the MANET working group is =
to standardize IP routing protocol functionality suitable for wireless rout=
ing application within both static and dynamic topologies with increased dy=
namics due to node motion or other factors.=C2=A0 

=C2=A0


Approaches are intended to be relatively l=
ightweight in nature, suitable for multiple hardware and wireless environme=
nts, and address scenarios where MANETs are deployed at the edges of an IP =
infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and m=
obile routers) should also be supported by MANET specifications and managem=
ent features.


=C2=A0


The MANET WG is responsible for the mainte=
nance of OLSRv2, AODVv2 (JWD TBD), DLEP and NHPD. Of particular interest: s=
ecurity enhancements, and encryption security extensions for RFC5444. (JWD =
we may want to break this out of the WG and make a new MANET Sec working gr=
oup to grab the attention of those interested in security and get their par=
ticipation.)


=C2=A0


The MANET WG will standardize a multicast =
MANET protocol framework based on previous work and lessons learned for sco=
ped forwarding within MANET networks.=C2=A0 As part of this framework the W=
G will produce a well defined MANET multicast forwarding information base.<=
/span>


=C2=A0


The WG will produce an informational draft=
 outlining challenges and best practices for deploying and managing MANET n=
etworks. 


=C2=A0


The MANET WG will interact with the PIM wo=
rking group on issues relating to the multicast work.=C2=A0 The WG will als=
o pay attention to other IETF and IRTF work that is addressing topics relat=
ed to MANET environments.


=C2=A0


In summary, the WG will develop the follow=
ing drafts:


=C2=A0


MANET Management Document (Informational)<=
/span>


MANET Maintenance 

=C2=A0- RFC5444 Security extension (Standa=
rds) (JWD possibly move this to new working group)

MANET Multicast


 - Multicast FIB (Standards)=





=C2=A0






=C2=A0

=C2=A0

On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen <= ietf@thomasclau= sen.org> wrote:

Hi,

=C2=A0

I believe that an virtual interim is premature: a te= leconference is, mechanically, less inclusive than are mailing list discuss= ions (time-zones, other commitments, requirement of synchronicity of participation, etc.).

=C2=A0

Furthermore....

=C2=A0

Until such time that a strawman charter is proposed, updated to reflect the reality of the group as stipulated by = the AD and by Mr. Dean, as well as additional charter items emerging on the= list, =C2=A0and with relatively broad and deep support for the included items= by the working group, having an interim - virtual or otherwise - is not co= nstructive.

=C2=A0

In other words, it should be established on the list= that there are meaningful things to do, and there's a meaningful c= ritical mass of people to be doing those things, before a (virtual)= interim is called. Brainstorming on a teleconference is rarely a construct= ive way to spend time.

=C2=A0<= /p>

Best,

=C2=A0<= /p>

Thomas

=C2=A0

Sent from my iPad

=C2=A0

On 22 Apr 2016, at 17= :50, Stan Ratliff <ratliffstan@gmail.com> wrote:

Hello WG,=C2=A0

=C2=A0

Do we need to hold an interim meeting (via WebEX) to= discuss? I'd like to get opinions on the list about that. We'll ne= ed a couple of weeks to schedule, but we can do that.=C2=A0

=C2=A0

One other point inline:=C2=A0

=C2=A0

On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christop= her (UK) <chris.dearlove@baesystems.com> wrote:

Multicast is the obvious = top item. Lots of possible approaches, time to discuss.

=C2=A0

Gateways for AODVv2 at St= andard is obviously not possible since AODVv2 is going to be Experimental at most.

=C2=A0

Management we did of cour= se have an NHDP/OLSRv2 draft killed by AD. Which since NHDP/OLSRv2 us all we have (SMF excepted) that was a bit tricky.

=C2=A0

I would have to make an I= PR declaration to say some of what I might have to say about encryption. Not today.

=C2=A0

Understood. But please remember - there's only a= bout a 5-week gap now before the charter needs to be complete in order for = the WG to meet in Berlin.=C2=A0

=C2=A0

Regards,

Stan

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Missing from the list is = any work on OLSRv2 (or NHDP). MT-OLSRv2 is experimental. That would need implementation tests to advance to PS. Anyone interested in that (I=E2=80= =99m not saying I can)?

=C2=A0

More broadly on OLSRv2 th= ere are various things that could be done, but what is really needed is people with a real application. Any that exist were frightened away from t= his group.

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)12= 45 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: manet [mailto:manet-= bounces@ietf.org] On Behalf Of Justin Dean
Sent: 22 April 2016 16:07
To: manet@ietf.o= rg
Subject: [manet] Recharter Discussion

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments= or reply.
For= information regarding Red Flags that you can look out for in emails you receive, click here.
If = you feel the email is suspicious, please follow this process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside ou= r organization.

=C2=A0

I'll start things= off by floating the draft re-charter which was presented in Prague. =C2=A0= 

The purpose of the MANET working group is =
to standardize IP routing protocol functionality suitable for wireless rout=
ing application within both static and dynamic topologies with increased dy=
namics due to node motion or other factors.=C2=A0 

=C2=A0


Approaches are intended to be relatively l=
ightweight in nature, suitable for multiple hardware and wireless environme=
nts, and address scenarios where MANETs are deployed at the edges of an IP =
infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and m=
obile routers) should also be supported by MANET specifications and managem=
ent features.


=C2=A0


The MANET WG is responsible for the mainte=
nance of OLSRv2, AODVv2, DLEP and NHPD. Of particular interest: border beha=
vior between MANET networks and fixed IP network infrastructures, enhance A=
ODVv2 gateway functionality; security enhancements, encryption security ext=
ensions for RFC5444. 


=C2=A0


The MANET WG will standardize a multicast =
MANET protocol framework based on previous work and lessons learned for sco=
ped forwarding within MANET networks.=C2=A0 As part of this framework the W=
G will produce a well defined MANET multicast forwarding information base.<=
/span>


=C2=A0


The WG will produce an informational draft=
 outlining challenges and best practices for deploying and managing MANET n=
etworks.


=C2=A0


The MANET WG will interact with the PIM wo=
rking group on issues relating to the multicast work.=C2=A0 The WG will als=
o pay attention to other IETF and IRTF work that is addressing topics relat=
ed to MANET environments.


=C2=A0


In summary, the WG will develop the follow=
ing drafts:


=C2=A0


MANET Management Document (Informational)<=
/span>


MANET Maintenance 

=C2=A0- RFC5444 Security extension (Standa=
rds)


 - Enhanced AODVv2 gateway extension (Stan=
dards)


MANET Multicast


 - Multicast FIB (Standards)=



=C2=A0


=C2=A0


This will likely be considered too broad t=
o pass.=C2=A0 We will likely need to cut some and focus the work.=C2=A0 For=
 me personally I know I have the time and backing to work on the Multicast =
piece.=C2=A0 


=C2=A0


Justin

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************=


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

=C2=A0

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


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

=C2=A0

=C2=A0


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


=

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a11c36f5c920cc60532671572-- From nobody Mon May 9 04:42:31 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC4412B006; Mon, 9 May 2016 04:42:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509114229.4871.9582.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 04:42:29 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-sec-threats-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 11:42:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Thomas Clausen Ulrich Herberg Jiazi Yi Filename : draft-ietf-manet-olsrv2-sec-threats-02.txt Pages : 23 Date : 2016-05-09 Abstract: This document analyzes common security threats of the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It then analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2, and how the vulnerabilities are mitigated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-sec-threats-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-sec-threats-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 9 05:05:35 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170D212D0BE for ; Mon, 9 May 2016 05:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FscabQDWHVVI for ; Mon, 9 May 2016 05:05:32 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722CF12B05C for ; Mon, 9 May 2016 05:05:32 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id y84so197943103lfc.0 for ; Mon, 09 May 2016 05:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EgH7YNq6exNoV9ThCUG8HQ5ED7FqrlfhcG8zNFh8eEw=; b=H6SsrSF9HsGRPlEkk/sbSbMijwQ9HKd0CHx6RfNpjAMC+EXKcX1sFvL9q5KLSgIEFZ QS+goRrr1KinCchsMxkKokUupA+BEoZ6utqlMyYKQlCIJhGRlEEkYUIwZsXfNVx3TUsh d4Aka8xlhwC0tDHhmnSGNpdr62idblCc7WoBy5clU++RXlMWZK98r3XyeQM+MUObEqdG ZfTFf46w5U1EzH/1spij1nWjTS0FaXs9H/PgEt4gvUoofAfdI5l35WIgwJxszlaWKjL4 fAP8zEjM0sBvjfkOplkeLTZQpb1lPVxzAgv3I01T41/ztRGSEe3eJPqbPlXh5Jk3kEl4 Ob6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EgH7YNq6exNoV9ThCUG8HQ5ED7FqrlfhcG8zNFh8eEw=; b=jKOWEgkjAXpcGbjHOCM5o7dAGNMVw8gjjKkqok/G92iL12yqFXv3RNPIfOUqJomtdy tIfgu3S6wjUwC1N5xUdI6cLEPrPP1s7i6qCvzggTMW4UXNqWz2Q9fyeJag0YsGR2kQBK nnzLbZnk2sVjGD6Zp91pYhUAFTaed9LHYuFR9wmZxkga/4nIq6TR1z0kppD9trq/YSTZ S46CKUJRKh8kudE4E3VrTcVST2Yta3UzD+3D5h4QczgHfny9ATxSciEsPpY8V4bLN4s0 CoSLBVJ8smA6JpMaf0oXmbcjqkhHkzn8u9lxgDb8dwQfjtPe9cYW5qYaSedoLyBg/CHV qgRw== X-Gm-Message-State: AOPr4FWO/uTvQliCr3pnVzIn+R9H1/T4o47YAueyWFp97jwXDwdmVX/TLy2lmggvnCiSZQILIP2r30QOVe9UzQ== X-Received: by 10.112.129.103 with SMTP id nv7mr6490738lbb.66.1462795530731; Mon, 09 May 2016 05:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.24.42 with HTTP; Mon, 9 May 2016 05:05:01 -0700 (PDT) In-Reply-To: References: <82679804-2647-4913-ACF3-18E4FFF731A8@thomasclausen.org> From: Henning Rogge Date: Mon, 9 May 2016 14:05:01 +0200 Message-ID: To: Jiazi YI Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Recharter Discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 12:05:35 -0000 On Mon, May 9, 2016 at 1:26 PM, Jiazi YI wrote: > Hi, > Personally, I have interests in OLSRv2 source-destination routing, I have a working implementation for this so I would also be interested. > and > possible extensions to make OLSRv2 more scalable (fish-eye? or even > hierarchical)? Fisheye is a crude hack, but sometimes necessary unless we think about something better. Henning Rogge From nobody Mon May 9 05:24:57 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AAD12D105 for ; Mon, 9 May 2016 05:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8Tgm74IWCw7 for ; Mon, 9 May 2016 05:24:47 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B915C12B00D for ; Mon, 9 May 2016 05:24:46 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id a17so183926727wme.0 for ; Mon, 09 May 2016 05:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:subject:references:from:mime-version :in-reply-to:message-id:date:cc:to; bh=BSweqKl7DxvNni4Jeidf95lIEB1oaviXD9tav5/IsSw=; b=kamPPHgLLWAgnGAJx4jSZ2kb+A+kF4023UxKUcIbdSnmRdaMtiEU6qgeknj+9hnhqG rRQ3eV80peGWoDyW5wLzx4sFGF2uo9WgQ8pfRQxLR2UkcFojf3rsWJyNDv2NHaBUc3MQ inT6lGb9uYku0I0Ax147mWhEPmwUqiN55e9wrbPZrAJQR46ApHoVPa/wsdIZPIhS2DYv 0HEuEH2W+8zDzz2dk8B/kU16dyoVw0uUX4JDE4oi1mNAH/Kg4KfoGO9hKVa2geSuezmo Q0jj8xGWs22ViFtwRTbcRJkyt3JXSOIuAuVA6KbBj0ntdvvONxOD318Z5kDeINilWIQ2 ZW5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:subject:references :from:mime-version:in-reply-to:message-id:date:cc:to; bh=BSweqKl7DxvNni4Jeidf95lIEB1oaviXD9tav5/IsSw=; b=db4em+G+fkkHNGNHDDLO+hxl5pDK8ZJ/voqXAtYiS2e3+sqv/ExPquGjP9n5rZU0U/ 0BPXmWPt0hu1c/l6VUdMH/Lbs/rx+PVoGFflapzPoliufmnossrVb2sPWEFD3SjNtLQI lpjdNVX2wq6FnUQSMx7+CqfZyH8DCSwye7+viAMGzYS0EYd+3yG89R3sQeo3bJ89q8Fy SQLNbpbb5LYL/i7c/YsrZkidvEaeGvVLAzwkFqkYRpvaA92wLD8NTnuu6ydyMHJmv2VQ KTRA+aUTSSGpXUSgefKhzRrNZZXVB6eAlqVFEiM8K/vA+d0w4UPBYFlUKw2Niw3ijvHy JqGA== X-Gm-Message-State: AOPr4FVgInT0HEHcKnjVJ+mp0e37Bg7POybmsn7r/B+y3uA9poQpffVHvRCvfNGjrv4svA== X-Received: by 10.28.156.86 with SMTP id f83mr10292206wme.45.1462796685033; Mon, 09 May 2016 05:24:45 -0700 (PDT) Received: from [10.1.218.144] (82-132-236-152.dab.02.net. [82.132.236.152]) by smtp.gmail.com with ESMTPSA id vu4sm30798317wjc.27.2016.05.09.05.24.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2016 05:24:43 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-73ACF7A0-E03D-4C75-A53F-6D7080595BC5 Content-Transfer-Encoding: 7bit References: <82679804-2647-4913-ACF3-18E4FFF731A8@thomasclausen.org> From: Christopher Dearlove Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: Date: Mon, 9 May 2016 13:10:37 +0100 To: Jiazi YI X-Mailer: iPhone Mail (13E238) Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Recharter Discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 12:24:55 -0000 --Apple-Mail-73ACF7A0-E03D-4C75-A53F-6D7080595BC5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fish-eye is already supported in OLSRv2. We wrote 5497 to add the final need= ed detail. However we didn't really call it out (or some other similarly sup= ported features) in 7181. We have various bits of unpublished material descr= ibing this. I might have mentioned it in my one published paper on OLSRv2 (i= t's in a NATO conference). Or might not, I don't have access this minute. Hierarchical on the other hand is a different question. There were some Cana= dians who looked at this, but it was some time ago. I think you'd want to st= art from a clean sheet to design though. --=20 Christopher Dearlove > On 9 May 2016, at 12:26, Jiazi YI wrote: >=20 > Hi,=20 >=20 >> On Wed, May 4, 2016 at 2:30 AM, Stan Ratliff wrot= e: >> Christopher/All,=20 >>=20 >> Time to pick this discussion up again. What type of buy-in do you think i= s necessary? On the one hand, you discuss a "small team of authors"; on the o= ther, you mention that we're "way short of what we really need in terms of b= uy-in".=20 >>=20 >> There has been interest expressed in addressing the MCAST issue, and volu= nteers (specifically, Justin, and probably Brian) to submit work. There is a= lso a small number of potential authors interested in a few (three or so) DL= EP extensions. Is there any OLSRv2 work on the horizon? >=20 > Personally, I have interests in OLSRv2 source-destination routing, and pos= sible extensions to make OLSRv2 more scalable (fish-eye? or even hierarchica= l)?=20 > The multipath extension is for experimental track -- hopefully it can be l= ast called soon. If there are interests on it, we can think about the possib= ility of pushing it towards standard track after the experimental RFC is pub= lished.=20 >=20 > I will try to participate the interim meeting, but not sure yet.=20 >=20 > cheers >=20 > Jiazi >=20 >=20 > =20 >> Is there a definable, manageable problem space for things like cryptograp= hic key management in ad hoc networks?=20 >>=20 >> We need to either come to consensus on a 12-18 month charter, or be prepa= red to close the WG. What is the interest level?=20 >>=20 >> Regards, >> Stan >>=20 >>=20 >>=20 >>> On Wed, Apr 27, 2016 at 12:35 PM, Dearlove, Christopher (UK) wrote: >>> OK, you know there are some people at NRL. Good. But still quite a way s= hort of what we really need in terms of buy-in. (I=E2=80=99m assuming the pe= ople at NRL are represented by you and/or Brian, as otherwise even they aren= =E2=80=99t showing up.) >>>=20 >>> =20 >>>=20 >>> -- >>>=20 >>> Christopher Dearlove >>> Senior Principal Engineer >>> BAE Systems Applied Intelligence Laboratories >>> ________________________________________________________________________= __ >>>=20 >>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>=20 >>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Badd= ow, Chelmsford, Essex CM2 8HN. >>> www.baesystems.com/ai >>>=20 >>> BAE Systems Applied Intelligence Limited >>> Registered in England & Wales No: 01337451 >>>=20 >>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>=20 >>> =20 >>>=20 >>> From: Justin Dean [mailto:bebemaster@gmail.com]=20 >>> Sent: 27 April 2016 16:45 >>> To: Dearlove, Christopher (UK) >>> Cc: Thomas Heide Clausen; manet@ietf.org >>> Subject: Re: [manet] Recharter Discussion >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> *** WARNING *** >>>=20 >>> This message originates from outside our organisation, either from an ex= ternal partner or the internet. >>> Consider carefully whether you should click on any links, open any attac= hments or reply. >>> For information regarding Red Flags that you can look out for in emails y= ou receive, click here. >>> If you feel the email is suspicious, please follow this process. >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christopher (UK) wrote: >>>=20 >>> The key points as I see it are: >>>=20 >>> - We shouldn=E2=80=99t wait for telecon, and can=E2=80=99t rely on telec= on and cut out list. >>>=20 >>> I agree. We shouldn't wait for the telecon. I'll continue to engage ev= eryone on this list about what people are willing to work on. >>> =20 >>>=20 >>> - We are very short of contributors. Many who have contributed have drop= ped away. And those who have been main creators of WG RFCs (looking at stati= stics, Clausen and Dearlove in particular, but also others - but not a lot o= f others, especially after the first batch of Experimental RFCs) may or may n= ot be contributing. >>>=20 >>> We are short contributors and we may be able to get more by focusing the= group on specific issues and possibly creating new focused groups to invite= a larger/wider IETF involvement. Security being the one coming to mind. Y= our mention on the list about security stuff that you are interested in hasn= 't brought a lot of discussion on this list but it very well may bring a lot= of interest from the larger ietf community.=20 >>>=20 >>> =20 >>>=20 >>> - But even more importantly we need real people (preferably companies wi= th products) using our protocols with real problems. DLEP I think has some r= eal adaptors, though I think most are waiting for an RFC. OLSRv2 is short on= companies advertising they are using it - I wish some would (I=E2=80=99m to= ld they exist, but couldn=E2=80=99t name any). AODVv2 (which may or may not b= e in scope) appears not to have even up to date experimental code (please co= rrect if wrong). >>>=20 >>> - Hence although we may have some great ideas, it=E2=80=99s not yet clea= r people want them and we can deliver - DLEP maintenance being I think close= st to contradicting that, at least publicly. >>>=20 >>> Well I KNOW that here at NRL we have the real people and prototype produ= cts relating to the multicast issue that it can happen. The key issue is mak= ing sure there are enough people willing to contribute and engineer a soluti= on to an issue that needs solving. >>>=20 >>> =20 >>>=20 >>> There is the horrible warning of Autoconf that went wrong in several way= s, but at the end, had no one who would do the work (which is a lot of work,= taking longer than you expect) to create a draft and take it all the way. A= nd that means a small team of actual authors, plus wider input. >>>=20 >>> =20 >>>=20 >>> Incidentally the autoconf problem is still real, but was too narrow. Tha= t was considering address autoconfiguration (though the WG never actually go= t there). As I see it, there=E2=80=99s an inseparable (in terms of thinking a= bout it, drafts may of course separate out details) issue that is of address= assignment, identity assignment/management, cryptographic key management, a= nd other forms of management (network management). And several chicken and e= gg problems that arise in them, especially in ad hoc networks. >>>=20 >>> I think the issue with autoconf is that it was attempting to solve to br= oad a problem. There were demonstratable solutions to very specific problem= s (e.g. multihop DHCP) but then there were more exotic solutions to more com= plex problems like DAD in disconnected partitioning/merging networks. If we c= an focus on a specific well defined problem space I think we'll be fine. =20= >>>=20 >>> =20 >>>=20 >>> -- >>>=20 >>> Christopher Dearlove >>> Senior Principal Engineer >>> BAE Systems Applied Intelligence Laboratories >>> ________________________________________________________________________= __ >>>=20 >>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>=20 >>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Badd= ow, Chelmsford, Essex CM2 8HN. >>> www.baesystems.com/ai >>>=20 >>> BAE Systems Applied Intelligence Limited >>> Registered in England & Wales No: 01337451 >>>=20 >>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>=20 >>> =20 >>>=20 >>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Heide Cl= ausen >>> Sent: 26 April 2016 22:01 >>> To: Justin Dean >>> Cc: manet@ietf.org >>> Subject: Re: [manet] Recharter Discussion >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> *** WARNING *** >>>=20 >>> This message originates from outside our organisation, either from an ex= ternal partner or the internet. >>> Consider carefully whether you should click on any links, open any attac= hments or reply. >>> For information regarding Red Flags that you can look out for in emails y= ou receive, click here. >>> If you feel the email is suspicious, please follow this process. >>>=20 >>> *** WARNING *** >>> EXTERNAL EMAIL -- This message originates from outside our organization.= >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>>=20 >>> On 26 avr. 2016, at 22:21, Justin Dean wrote: >>>=20 >>> Thomas I understand your concerns but we have mostly gone over this befo= re in previous meetings. >>>=20 >>> =20 >>>=20 >>> The IETF conducts is business on mailing lists. >>>=20 >>> =20 >>>=20 >>> My recollection is that the strawman charter was presented once in a WG m= eeting, then the chairs did not animate any charter discussion for several I= ETFs, on the list (nor was the charter discussed in subsequent meetings) - u= ntil this present "urgency" was declared (by the chairs) to the WG. >>>=20 >>> =20 >>>=20 >>> The AD will not allow us to meet at the next IETF meeting if we do not h= ave a new charter and new work items.=20 >>>=20 >>> =20 >>>=20 >>> That does not negate my point, however, which was that: >>>=20 >>> =20 >>>=20 >>> it should be established on the list that there are meaningful things to= do, and there's a meaningful critical mass of people to be doing those thin= gs, before a (virtual) interim is called. Brainstorming on a teleconference i= s rarely a constructive way to spend time >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> Thomas >>>=20 >>> =20 >>>=20 >>> To your point it's imparative that the discussion continues on list abou= t the charter. With that in mind here is a suggested edit of the previously= floated charter, with comments in () with JWD tags. >>>=20 >>>=20 >>> The purpose of the MANET working group is to standardize IP routing prot= ocol functionality suitable for wireless routing application within both sta= tic and dynamic topologies with increased dynamics due to node motion or oth= er factors. =20 >>> =20 >>> Approaches are intended to be relatively lightweight in nature, suitable= for multiple hardware and wireless environments, and address scenarios wher= e MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infr= astructures (e.g., a mixture of fixed and mobile routers) should also be sup= ported by MANET specifications and management features. >>> =20 >>> The MANET WG is responsible for the maintenance of OLSRv2, AODVv2 (JWD T= BD), DLEP and NHPD. Of particular interest: security enhancements, and encry= ption security extensions for RFC5444. (JWD we may want to break this out of= the WG and make a new MANET Sec working group to grab the attention of thos= e interested in security and get their participation.) >>> =20 >>> The MANET WG will standardize a multicast MANET protocol framework based= on previous work and lessons learned for scoped forwarding within MANET net= works. As part of this framework the WG will produce a well defined MANET m= ulticast forwarding information base. >>> =20 >>> The WG will produce an informational draft outlining challenges and best= practices for deploying and managing MANET networks.=20 >>> =20 >>> The MANET WG will interact with the PIM working group on issues relating= to the multicast work. The WG will also pay attention to other IETF and IR= TF work that is addressing topics related to MANET environments. >>> =20 >>> In summary, the WG will develop the following drafts: >>> =20 >>> MANET Management Document (Informational) >>> MANET Maintenance=20 >>> - RFC5444 Security extension (Standards) (JWD possibly move this to new= working group) >>> MANET Multicast >>> - Multicast FIB (Standards) >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen = wrote: >>>=20 >>> Hi, >>>=20 >>> =20 >>>=20 >>> I believe that an virtual interim is premature: a teleconference is, mec= hanically, less inclusive than are mailing list discussions (time-zones, oth= er commitments, requirement of synchronicity of participation, etc.). >>>=20 >>> =20 >>>=20 >>> Furthermore.... >>>=20 >>> =20 >>>=20 >>> Until such time that a strawman charter is proposed, updated to reflect t= he reality of the group as stipulated by the AD and by Mr. Dean, as well as a= dditional charter items emerging on the list, and with relatively broad and= deep support for the included items by the working group, having an interim= - virtual or otherwise - is not constructive. >>>=20 >>> =20 >>>=20 >>> In other words, it should be established on the list that there are mean= ingful things to do, and there's a meaningful critical mass of people to be d= oing those things, before a (virtual) interim is called. Brainstorming on a t= eleconference is rarely a constructive way to spend time. >>>=20 >>> =20 >>>=20 >>> Best, >>>=20 >>> =20 >>>=20 >>> Thomas >>>=20 >>> =20 >>>=20 >>> Sent from my iPad >>>=20 >>> =20 >>>=20 >>> On 22 Apr 2016, at 17:50, Stan Ratliff wrote: >>>=20 >>> Hello WG,=20 >>>=20 >>> =20 >>>=20 >>> Do we need to hold an interim meeting (via WebEX) to discuss? I'd like t= o get opinions on the list about that. We'll need a couple of weeks to sched= ule, but we can do that.=20 >>>=20 >>> =20 >>>=20 >>> One other point inline:=20 >>>=20 >>> =20 >>>=20 >>> On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christopher (UK) wrote: >>>=20 >>> Multicast is the obvious top item. Lots of possible approaches, time to d= iscuss. >>>=20 >>> =20 >>>=20 >>> Gateways for AODVv2 at Standard is obviously not possible since AODVv2 i= s going to be Experimental at most. >>>=20 >>> =20 >>>=20 >>> Management we did of course have an NHDP/OLSRv2 draft killed by AD. Whic= h since NHDP/OLSRv2 us all we have (SMF excepted) that was a bit tricky. >>>=20 >>> =20 >>>=20 >>> I would have to make an IPR declaration to say some of what I might have= to say about encryption. Not today. >>>=20 >>> =20 >>>=20 >>> Understood. But please remember - there's only about a 5-week gap now be= fore the charter needs to be complete in order for the WG to meet in Berlin.= =20 >>>=20 >>> =20 >>>=20 >>> Regards, >>>=20 >>> Stan >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> Missing from the list is any work on OLSRv2 (or NHDP). MT-OLSRv2 is expe= rimental. That would need implementation tests to advance to PS. Anyone inte= rested in that (I=E2=80=99m not saying I can)? >>>=20 >>> =20 >>>=20 >>> More broadly on OLSRv2 there are various things that could be done, but w= hat is really needed is people with a real application. Any that exist were f= rightened away from this group. >>>=20 >>> =20 >>>=20 >>> -- >>>=20 >>> Christopher Dearlove >>> Senior Principal Engineer >>> BAE Systems Applied Intelligence Laboratories >>> ________________________________________________________________________= __ >>>=20 >>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>=20 >>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Badd= ow, Chelmsford, Essex CM2 8HN. >>> www.baesystems.com/ai >>>=20 >>> BAE Systems Applied Intelligence Limited >>> Registered in England & Wales No: 01337451 >>>=20 >>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>=20 >>> =20 >>>=20 >>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean >>> Sent: 22 April 2016 16:07 >>> To: manet@ietf.org >>> Subject: [manet] Recharter Discussion >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> *** WARNING *** >>>=20 >>> This message originates from outside our organisation, either from an ex= ternal partner or the internet. >>> Consider carefully whether you should click on any links, open any attac= hments or reply. >>> For information regarding Red Flags that you can look out for in emails y= ou receive, click here. >>> If you feel the email is suspicious, please follow this process. >>>=20 >>> *** WARNING *** >>> EXTERNAL EMAIL -- This message originates from outside our organization.= >>>=20 >>> =20 >>>=20 >>> I'll start things off by floating the draft re-charter which was present= ed in Prague. =20 >>>=20 >>> The purpose of the MANET working group is to standardize IP routing prot= ocol functionality suitable for wireless routing application within both sta= tic and dynamic topologies with increased dynamics due to node motion or oth= er factors. =20 >>> =20 >>> Approaches are intended to be relatively lightweight in nature, suitable= for multiple hardware and wireless environments, and address scenarios wher= e MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infr= astructures (e.g., a mixture of fixed and mobile routers) should also be sup= ported by MANET specifications and management features. >>> =20 >>> The MANET WG is responsible for the maintenance of OLSRv2, AODVv2, DLEP a= nd NHPD. Of particular interest: border behavior between MANET networks and f= ixed IP network infrastructures, enhance AODVv2 gateway functionality; secur= ity enhancements, encryption security extensions for RFC5444.=20 >>> =20 >>> The MANET WG will standardize a multicast MANET protocol framework based= on previous work and lessons learned for scoped forwarding within MANET net= works. As part of this framework the WG will produce a well defined MANET m= ulticast forwarding information base. >>> =20 >>> The WG will produce an informational draft outlining challenges and best= practices for deploying and managing MANET networks. >>> =20 >>> The MANET WG will interact with the PIM working group on issues relating= to the multicast work. The WG will also pay attention to other IETF and IR= TF work that is addressing topics related to MANET environments. >>> =20 >>> In summary, the WG will develop the following drafts: >>> =20 >>> MANET Management Document (Informational) >>> MANET Maintenance=20 >>> - RFC5444 Security extension (Standards) >>> - Enhanced AODVv2 gateway extension (Standards) >>> MANET Multicast >>> - Multicast FIB (Standards) >>> =20 >>> =20 >>> This will likely be considered too broad to pass. We will likely need t= o cut some and focus the work. For me personally I know I have the time and= backing to work on the Multicast piece. =20 >>> =20 >>> Justin >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> =20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-73ACF7A0-E03D-4C75-A53F-6D7080595BC5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Fish-eye is already supported in OLSRv= 2. We wrote 5497 to add the final needed detail. However we didn't really ca= ll it out (or some other similarly supported features) in 7181. We have vari= ous bits of unpublished material describing this. I might have mentioned it i= n my one published paper on OLSRv2 (it's in a NATO conference). Or might not= , I don't have access this minute.

<= /div>
Hierarchical on the other hand is a diff= erent question. There were some Canadians who looked at this, but it was som= e time ago. I think you'd want to start from a clean sheet to design though.=

-- 
Christopher Dearlove

On 9 May 2016, at 12:26, Jiazi YI <ietf@jiaziyi.com> wrote:

Hi, 

<= div class=3D"gmail_quote">On Wed, May 4, 2016 at 2:30 AM, Stan Ratliff <= ratliffstan@gmail.com> wrote:
Christopher/All,

Ti= me to pick this discussion up again. What type of buy-in do you think is nec= essary? On the one hand, you discuss a "small team of authors"; on the other= , you mention that we're "way short of what we really need in terms of buy-i= n".

There has been interest expressed in addressing the MCAST i= ssue, and volunteers (specifically, Justin, and probably Brian) to submit wo= rk. There is also a small number of potential authors interested in a few (t= hree or so) DLEP extensions. Is there any OLSRv2 work on the horizon?
=

Personally, I have intere= sts in OLSRv2 source-destination routing, and possible extensions to make OL= SRv2 more scalable (fish-eye? or even hierarchical)? 
The mul= tipath extension is for experimental track -- hopefully it can be last calle= d soon. If there are interests on it, we can think about the possibility of p= ushing it towards standard track after the experimental RFC is published.&nb= sp;

I will try to participate the interim meeting, b= ut not sure yet. 

cheers

<= div>Jiazi


 
Is there a definable, manage= able problem space for things like cryptographic key management in ad hoc ne= tworks?

We need to either come to consensus on a 12-18 month c= harter, or be prepared to close the WG. What is the interest level?

=
Regards,
Stan

<= div>


On We= d, Apr 27, 2016 at 12:35 PM, Dearlove, Christopher (UK) &l= t;chris.d= earlove@baesystems.com> wrote:

OK, you know there are some= people at NRL. Good. But still quite a way short of what we really need in t= erms of buy-in. (I=E2=80=99m assuming the people at NRL are represented by you and/or Brian, as otherwise even they aren=E2=80=99t show= ing up.)

 =

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________= ____________________________________

T:  = +44 (0)1245 242194  |  E: chris= .dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 =

From: Justin Dean [mailto:bebemaster@gmail.com]
Sent: 27 April 2016 16:45
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; manet@ietf.org
Subject: Re: [manet] Recharter Discussion

 

 

*** WARNING ***=

This message originates from outside our organisa= tion, either from an external partner or the internet.
Cons= ider carefully whether you should click on any links, open any attachments o= r reply.
For i= nformation regarding Red Flags that you can look out for in emails you receive, click here.
If y= ou feel the email is suspicious, please follow this process.

 

 

On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christophe= r (UK) <chris.dearlove@baesystems.com> wrote:

The key points as I see it a= re:

- We shouldn=E2=80=99t wait= for telecon, and can=E2=80=99t rely on telecon and cut out list.<= /u>

I agree.  We shouldn't wait for the telecon.&nbs= p; I'll continue to engage everyone on this list about what people are willi= ng to work on.
 

- We are very short of cont= ributors. Many who have contributed have dropped away. And those who have been main creators of WG RFCs (looking at statistics, Clausen and Dearlove i= n particular, but also others - but not a lot of others, especially after th= e first batch of Experimental RFCs) may or may not be contributing.

We are short contributors and we may be able to get m= ore by focusing the group on specific issues and possibly creating new focus= ed groups to invite a larger/wider IETF involvement.  Security being th= e one coming to mind.  Your mention on the list about security stuff that you are interested in hasn't brought a= lot of discussion on this list but it very well may bring a lot of interest= from the larger ietf community. 

 

- But even more importantly= we need real people (preferably companies with products) using our protocol= s with real problems. DLEP I think has some real adaptors, though I think mos= t are waiting for an RFC. OLSRv2 is short on companies advertising they are u= sing it - I wish some would (I=E2=80=99m told they exist, but couldn=E2=80=99= t name any). AODVv2 (which may or may not be in scope) appears not to have even up to date experimental code (please cor= rect if wrong).

- Hence although we may hav= e some great ideas, it=E2=80=99s not yet clear people want them and we can d= eliver - DLEP maintenance being I think closest to contradicting that, at least pu= blicly.

Well I KNOW that here at NRL we have the real people a= nd prototype products relating to the multicast issue that it can happen. Th= e key issue is making sure there are enough people willing to contribute and= engineer a solution to an issue that needs solving.

  <= u>

There is the horrible warni= ng of Autoconf that went wrong in several ways, but at the end, had no one who would do the work (which is a lot of work, taking longer than you e= xpect) to create a draft and take it all the way. And that means a small tea= m of actual authors, plus wider input.

 =

Incidentally the autoconf p= roblem is still real, but was too narrow. That was considering address autoconfiguration (though the WG never actually got there). As I see it, th= ere=E2=80=99s an inseparable (in terms of thinking about it, drafts may of c= ourse separate out details) issue that is of address assignment, identity as= signment/management, cryptographic key management, and other forms of management (network management). And several= chicken and egg problems that arise in them, especially in ad hoc networks.=

I think the issue with autoconf is that it was attemp= ting to solve to broad a problem.  There were demonstratable solutions t= o very specific problems (e.g. multihop DHCP) but then there were more exoti= c solutions to more complex problems like DAD in disconnected partitioning/merging networks. If we can focus on a= specific well defined problem space I think we'll be fine.   <= /u>

 =

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________= ____________________________________

T:  = +44 (0)1245 2= 42194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 =

From: manet [mailto:manet-b= ounces@ietf.org] On Behalf Of Thomas Heide Clausen
Sent: 26 April 2016 22:01
To: Justin Dean
Cc: manet@ietf.or= g
Subject: Re: [manet] Recharter Discussion

 

 

*** WARNING ***

This message originates from outside our organisa= tion, either from an external partner or the internet.
Cons= ider carefully whether you should click on any links, open any attachments o= r reply.
For i= nformation regarding Red Flags that you can look out for in emails you receive, click here.
If y= ou feel the email is suspicious, please follow this process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our o= rganization.

 

 


On 26 avr. 2016, at 22:21, Justin Dean <bebemaster@gmail.com> wrote:

Thomas I understand your concerns but we have mostly g= one over this before in previous meetings.

 

The IETF conducts is business on mailing lists.

 

My recollection is that the strawman charter was pres= ented once in a WG meeting, then the chairs did not animate any charter disc= ussion for several IETFs, on the list (nor was the charter discussed in subsequent meetings) - until this present "urgency" wa= s declared (by the chairs) to the WG.

 

The AD will not allow us to meet at the next IETF mee= ting if we do not have a new charter and new work items. =

 

That does not negate my point, however, which was tha= t:

 

it should be established o= n the list that there are meaningful things to do, and th= ere's a meaningful critical mass of people to be doing those things, before a (virtual) interim is called. Brainstor= ming on a teleconference is rarely a constructive way to spend time

 

 

Thomas

 

To your point it's imp= arative that the discussion continues on list about the charter.  With t= hat in mind here is a suggested edit of the previously floated charter, with= comments in () with JWD tags.

The purpose of the MANET working group is t=
o standardize IP routing protocol functionality suitable for wireless routin=
g application within both static and dynamic topologies with increased dynam=
ics due to node motion or other factors.  
 
Approaches are intended to be relatively li=
ghtweight in nature, suitable for multiple hardware and wireless environment=
s, and address scenarios where MANETs are deployed at the edges of an IP inf=
rastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobil=
e routers) should also be supported by MANET specifications and management f=
eatures.
 
The MANET WG is responsible for the mainten=
ance of OLSRv2, AODVv2 (JWD TBD), DLEP and NHPD. Of particular interest: sec=
urity enhancements, and encryption security extensions for RFC5444. (JWD we m=
ay want to break this out of the WG and make a new MANET Sec working group t=
o grab the attention of those interested in security and get their participa=
tion.)
 
The MANET WG will standardize a multicast M=
ANET protocol framework based on previous work and lessons learned for scope=
d forwarding within MANET networks.  As part of this framework the WG w=
ill produce a well defined MANET multicast forwarding information base.
 
The WG will produce an informational draft o=
utlining challenges and best practices for deploying and managing MANET netw=
orks. 
 
The MANET WG will interact with the PIM wor=
king group on issues relating to the multicast work.  The WG will also p=
ay attention to other IETF and IRTF work that is addressing topics related t=
o MANET environments.
 
In summary, the WG will develop the followi=
ng drafts:
 
MANET Management Document (Informational)
MANET Maintenance 

 - RFC5444 Security extension (Standar=
ds) (JWD possibly move this to new working group)
=


MANET Multicast


 - Multicast FIB (Standards)<=
u>




 






 

 

On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen <<= a href=3D"mailto:ietf@thomasclausen.org" target=3D"_blank">ietf@thomasclause= n.org> wrote:

Hi,

 

I believe that an virtual interim is premature: a tel= econference is, mechanically, less inclusive than are mailing list discussio= ns (time-zones, other commitments, requirement of synchronicity of participation, etc.).

 

Furthermore....

 

Until such time that a strawman charter is proposed, updated to reflect the reality of the group as stipulated by t= he AD and by Mr. Dean, as well as additional charter items emerging on the l= ist,  and with relatively broad and deep support for the included items b= y the working group, having an interim - virtual or otherwise - is not const= ructive.

 

In other words, it should be established on the list t= hat there are meaningful things to do, and there's a meaningful critic= al mass of people to be doing those things, before a (virtual) inter= im is called. Brainstorming on a teleconference is rarely a constructive way= to spend time.

 

Best,

 

Thomas

 

Sent from my iPad

 

On 22 Apr 2016, at 17:= 50, Stan Ratliff <ratliffstan@gmail.com> wrote:

Hello WG, 

 

Do we need to hold an interim meeting (via WebEX) to d= iscuss? I'd like to get opinions on the list about that. We'll need a couple= of weeks to schedule, but we can do that. 

 

One other point inline: 

 

On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

Multicast is the obvious to= p item. Lots of possible approaches, time to discuss.

 =

Gateways for AODVv2 at Stan= dard is obviously not possible since AODVv2 is going to be Experimental at most.

 =

Management we did of course= have an NHDP/OLSRv2 draft killed by AD. Which since NHDP/OLSRv2 us all we have (SMF excepted) that was a bit tricky.

 =

I would have to make an IPR= declaration to say some of what I might have to say about encryption. Not today.

 

Understood. But please remember - there's only about a= 5-week gap now before the charter needs to be complete in order for the WG t= o meet in Berlin. 

 

Regards,

Stan

 

 

 

 =

Missing from the list is an= y work on OLSRv2 (or NHDP). MT-OLSRv2 is experimental. That would need implementation tests to advance to PS. Anyone interested in that (I=E2=80=99= m not saying I can)?

 =

More broadly on OLSRv2 ther= e are various things that could be done, but what is really needed is people with a real application. Any that exist were frightened away from th= is group.

 =

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________= ____________________________________

T:  = +44 (0)1245 2= 42194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 =

From: manet [mailto:manet-b= ounces@ietf.org] On Behalf Of Justin Dean
Sent: 22 April 2016 16:07
To: manet@ietf.or= g
Subject: [manet] Recharter Discussion

 

 

*** WARNING ***

This message originates from outside our organisa= tion, either from an external partner or the internet.
Cons= ider carefully whether you should click on any links, open any attachments o= r reply.
For i= nformation regarding Red Flags that you can look out for in emails you receive, click here.
If y= ou feel the email is suspicious, please follow this process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our o= rganization.

 

I'll start things off b= y floating the draft re-charter which was presented in Prague.  = 

The purpose of the MANET working group is t=
o standardize IP routing protocol functionality suitable for wireless routin=
g application within both static and dynamic topologies with increased dynam=
ics due to node motion or other factors.  
 
Approaches are intended to be relatively li=
ghtweight in nature, suitable for multiple hardware and wireless environment=
s, and address scenarios where MANETs are deployed at the edges of an IP inf=
rastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobil=
e routers) should also be supported by MANET specifications and management f=
eatures.
 
The MANET WG is responsible for the mainten=
ance of OLSRv2, AODVv2, DLEP and NHPD. Of particular interest: border behavi=
or between MANET networks and fixed IP network infrastructures, enhance AODV=
v2 gateway functionality; security enhancements, encryption security extensi=
ons for RFC5444. 
 
The MANET WG will standardize a multicast M=
ANET protocol framework based on previous work and lessons learned for scope=
d forwarding within MANET networks.  As part of this framework the WG w=
ill produce a well defined MANET multicast forwarding information base.
 
The WG will produce an informational draft o=
utlining challenges and best practices for deploying and managing MANET netw=
orks.
 
The MANET WG will interact with the PIM wor=
king group on issues relating to the multicast work.  The WG will also p=
ay attention to other IETF and IRTF work that is addressing topics related t=
o MANET environments.
 
In summary, the WG will develop the followi=
ng drafts:
 
MANET Management Document (Informational)
MANET Maintenance 

 - RFC5444 Security extension (Standar=
ds)


 - Enhanced AODVv2 gateway extension (Stand=
ards)


MANET Multicast


 - Multicast FIB (Standards)<=
u>


 


 


This will likely be considered too broad to=
 pass.  We will likely need to cut some and focus the work.  For m=
e personally I know I have the time and backing to work on the Multicast pie=
ce.  


 


Justin

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************<= u>


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

 

_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

 

 


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


<= /div>
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-73ACF7A0-E03D-4C75-A53F-6D7080595BC5-- From nobody Mon May 9 08:52:07 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B491212D0DE for ; Mon, 9 May 2016 08:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RzcNClQagpO for ; Mon, 9 May 2016 08:52:04 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D78412B011 for ; Mon, 9 May 2016 08:52:04 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id f66so71130740vkh.2 for ; Mon, 09 May 2016 08:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=F8ngSdLkhW7v39w866K8jqf3kv0Qu+9qE3Tc8zT5oyQ=; b=kWxIenbpUGJ3b1WY9ix9NLPT5JA6y4WzRaNt5GXB/QtUHmfG3+clFqfCdxA1sy3KYe 5wyLjeUcI3C8j3oBK6wiJiotAGD6HxtxVHgPR0rQZywNQkjP2fA6ad0f+ktu1YnyUGE6 C3vHtO4wl1z/dtDpecCKXvPeXwSasqnYjRsqtirf7B3kzqx24qqbub/FTwipgh0bwtCq 0wJn916VmKLul07fFfiYG58jxB4lWY/TvxUXWkdHhIezeTCz779mbXZQh7QrSGl3Ozvw 5F8ia+a0SV58R3zJaX/DH2tGQtncipi7nEm064vscQjS3HsW4bbMgIbunjpnEN4NH5He q4GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=F8ngSdLkhW7v39w866K8jqf3kv0Qu+9qE3Tc8zT5oyQ=; b=LgDMNjuppXEdqRR5w0iN3Oh919g879D3DBQb2FII68U8EKztqVG7chmH/vlQZzYbrq Fwa7b5ioyrhhl9ehZqEhgr7E5yUOp5XN2OUwexUB7et6dJQWS2D+vvx4GKnLVv246nf1 ys10+LxD9AtiQArN/5zLOYEXD1uSVVjXPnFRSdEwMiaWe0mLJTCR/AKgZnPO+MkAZsNo 8Bl+KciFjchTtFpqFonkXroMaC+OSLKxg6bQj2A8m0peeAFMKkyQBXyvAVlT4/gLHJE5 ClfFCmWIyHJ7m3AK2mqwI6CVs2XgB9vvyM30tLyMLH/PM1K31dgtk2bW1SgTnBMe2+/i mc4Q== X-Gm-Message-State: AOPr4FVv0iIqLesWnkcvMgM+hgtgvleUaLtkgGFtQpaIrfLzWv3HzTPh/fBNNJ877Ed8BCXts4ikcFfszX4yLQ== MIME-Version: 1.0 X-Received: by 10.176.1.103 with SMTP id 94mr20594251uak.41.1462809123205; Mon, 09 May 2016 08:52:03 -0700 (PDT) Received: by 10.176.4.104 with HTTP; Mon, 9 May 2016 08:52:03 -0700 (PDT) Date: Mon, 9 May 2016 11:52:03 -0400 Message-ID: From: Justin Dean To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=001a113e2fd829bb3305326acad6 Archived-At: Subject: [manet] Last Call issued for draft-ietf-manet-olsrv2-multipath X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 15:52:06 -0000 --001a113e2fd829bb3305326acad6 Content-Type: text/plain; charset=UTF-8 The IETF WG state of draft-ietf-manet-olsrv2-multipath has been changed to "In WG Last Call" from "WG Document" https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ This draft has been around for a while. I've previously reviewed the draft and updates have been made. I'll be doing another review and encourage everyone to do the same. This will be a 2 week last call ending on the 23rd. Justin --001a113e2fd829bb3305326acad6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The IETF WG state of draft-ietf-manet-olsrv2-multipath has been changed
to "In WG Last Call" from "WG Document"

https://datatracker.ietf.org/doc/= draft-ietf-manet-olsrv2-multipath/

This draft has been around for a while. I've previously reviewed = the draft and updates have been made.=C2=A0 I'll be doing another revie= w and encourage everyone to do the same.=C2=A0 This will be a 2 week last c= all ending on the 23rd.

Justin
--001a113e2fd829bb3305326acad6-- From nobody Mon May 9 13:35:52 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEEF12D12A for ; Mon, 9 May 2016 13:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlZAw4dPd4tu for ; Mon, 9 May 2016 13:35:48 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B70812D110 for ; Mon, 9 May 2016 13:35:48 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id y84so214249600lfc.0 for ; Mon, 09 May 2016 13:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=37XUlKTLRo142WvWErJm4TBWNC7SFncCWMb7QgLd178=; b=hc9th6FJCVhXm8lyNMFy2vHll4WKee6rptXYnEQI7DYA+QQHj292Tv/iIw+bbJK5J3 LhBUlWq4nAOii9fLGTccKeQZOx+4uDAxKhPh17SJXWfYPcf7Z4NNHoJCIPwTjBPmOAKA tMDbSkfBwD2r90wypsfQe9Gzrk4brZlmnFjbKn19bpcIBzRMLKG/goKcfrYXsj6c9Seb Xqz8bKrYSk0i+vtBbWK3u+552Nn/NAEyZpHh8LjLkAlF6XVOpfBc73aX7chBJ5rAxIOd 87lyKuHpDCzWY3TuEGeeHVfNn3SzN+DQ9YJXCcAPBb2PcFP0L3/XaOMsTbvl6IORfAID 64Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=37XUlKTLRo142WvWErJm4TBWNC7SFncCWMb7QgLd178=; b=cxqYwwOeztbn+qe9qAXqWuvWghY87Ol7FKD+ts8DqS2Oj8rNBUFLtRkSg2/boNE4eW T95ujIMo26GoFHAhWz4AJinj5pAdxjiOa049F8vD8YyL6BSImko6hErecAdH0asAvJPD /Cp04mltFklSCeBBle4HErQpg87BYnwg9LdZFEoahiUcdXWpjutL46077Y0z+B2ikbQ5 d37NkMQtFiOUURFC3MLiIRZ1tr0Exs3pbZnRZHDkKA5RvhBeyuhiTOrAwFud3DZXJA4Z 19PXTBmmFFDs8xTB/Vgt2DUm2i5Jnlhvrl2+/rHlLHQA7ASQ4a3mdIEdwq+XZaupV7Iu 0gDg== X-Gm-Message-State: AOPr4FVgGQazE/R2uLd0VCtu/mzrvsnz4Gfqjxn8LYcxtXsDiZo88Sw95XmSyYFuSLNA0sVjYVS3iifnjo9Owg== MIME-Version: 1.0 X-Received: by 10.25.38.69 with SMTP id m66mr15237332lfm.64.1462826146777; Mon, 09 May 2016 13:35:46 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.114.77.4 with HTTP; Mon, 9 May 2016 13:35:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 May 2016 22:35:46 +0200 X-Google-Sender-Auth: NVMlDL0r-F7QEv8STjEutgr1Z84 Message-ID: From: Jiazi YI To: Justin Dean Content-Type: multipart/alternative; boundary=001a113db104d8d2af05326ec0a7 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Last Call issued for draft-ietf-manet-olsrv2-multipath X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 20:35:51 -0000 --001a113db104d8d2af05326ec0a7 Content-Type: text/plain; charset=UTF-8 Thanks very much Justin. @All the WG participants: The modifications are based on the comments received from the first WGLC of the document. For your convenience, we listed the modifications and considerations in this post: https://www.ietf.org/mail-archive/web/manet/current/msg18394.html regards Jiazi On Mon, May 9, 2016 at 5:52 PM, Justin Dean wrote: > The IETF WG state of draft-ietf-manet-olsrv2-multipath has been changed > to "In WG Last Call" from "WG Document" > > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ > > This draft has been around for a while. I've previously reviewed the draft > and updates have been made. I'll be doing another review and encourage > everyone to do the same. This will be a 2 week last call ending on the > 23rd. > > Justin > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a113db104d8d2af05326ec0a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks very much Justin.=C2=A0

@All the= WG participants:

The modifications are based on t= he comments received from the first WGLC of the document. For your convenie= nce, we listed the modifications and considerations in this post: http= s://www.ietf.org/mail-archive/web/manet/current/msg18394.html

regards

Jiazi

On Mon, May 9, 2016 at 5:5= 2 PM, Justin Dean <bebemaster@gmail.com> wrote:
The IETF WG state of draft-ietf-manet-olsrv2-multipath has been changed
to "In WG Last Call" from "WG Document"

https://datatracker.ietf.org/doc/= draft-ietf-manet-olsrv2-multipath/

This draft has been around for a while. I've previously reviewed = the draft and updates have been made.=C2=A0 I'll be doing another revie= w and encourage everyone to do the same.=C2=A0 This will be a 2 week last c= all ending on the 23rd.
<= br>
Justi= n

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a113db104d8d2af05326ec0a7-- From nobody Mon May 9 16:00:45 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832E612D0CE for ; Mon, 9 May 2016 16:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWDV6YLqVbIt for ; Mon, 9 May 2016 16:00:38 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6651612D0A2 for ; Mon, 9 May 2016 16:00:37 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id j8so216047001lfd.2 for ; Mon, 09 May 2016 16:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=lO02kyEsEdQqn+FrMfs6SOzGTgaM8/h51UIagfNV4+c=; b=VvTnRdgEr1re2KnaiCI0nPsfD557ul8CQcrW7eq/cYRPfP+H/KAH6KwX7KZd/oiCSJ BOWqNYfRzQiJ33rHg0KAYGp8TL04mI1geQj5MSD1HlVpaIc9sNvZOIvzA1hR3WVhsQTO ncLogLu0dnAy2LDLq9Wiq3OpRTUYAqv0ixQHJryNjw5dYmYy/NZUarBFctl1Lb6tIEuK wwuWTiVt3NAtbutYKdo/vp4+XO0ho4XeBTvD/fyhJumlV7mX0qCkgSH+zkldiOM9ELFd 13IyLdjPRF0XGdQMMhtS5UavyltI848cwSI29koxM4eCPzwTMQmbWNzHFdZqecRs3OVa rZaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lO02kyEsEdQqn+FrMfs6SOzGTgaM8/h51UIagfNV4+c=; b=eUKEmiYOyUFEl7zyUT1STwTfXxkFM109jW1+kxXCzMNwqLIm0wKE6KH3E3Pf3aYlPV XZgpa9VtN0at+YEUR9sNcXGQUrCM8o0uOgSjP5qAlkDOXHtGBKjaYklrEzssh1WTpMVS x1aZA33Hexy2k/WwKLpPA5CBbS5ITAHZXPFyEISAVeazHb6PAaXxozQUJx+ZOf/mDWAv daZjdKq6UvWbjFYiYqX5mV58fYUhQpBLUNS683QzqFkc8h3Vr0qnID7j4r+qyipJGk7p wZ1F0hzTfWsnuS2pXSYcWaycOZaI/JjoLZSkoUb8mrHTujdv01Vc9L3JH0rc8rrsWEvT mY1A== X-Gm-Message-State: AOPr4FWiU3UM/VMb45Q4t84c4JSPc7mq0dx3ZU0qKP1rq6HxHhrrEs3gLtZ6UdyxKsV3Dyt/DTe9x8ZLGgdhhQ== MIME-Version: 1.0 X-Received: by 10.25.20.155 with SMTP id 27mr12951398lfu.90.1462834835656; Mon, 09 May 2016 16:00:35 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.114.77.4 with HTTP; Mon, 9 May 2016 16:00:35 -0700 (PDT) In-Reply-To: <33F4027C-8E60-46CD-BBD7-DACD70A54D21@fu-berlin.de> References: <33F4027C-8E60-46CD-BBD7-DACD70A54D21@fu-berlin.de> Date: Tue, 10 May 2016 01:00:35 +0200 X-Google-Sender-Auth: EtO-BOvZ1xdauyOrnocGwMiIJLs Message-ID: From: Jiazi YI To: Lotte Steenbrink Content-Type: multipart/alternative; boundary=001a113f1fe4be995a053270c6be Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] draft-ietf-manet-aodvv2-15 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:00:44 -0000 --001a113f1fe4be995a053270c6be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lotte, all: Although the chairs have made their decision on aodvv2, I'm providing my response to your comments below, in case you want to continue working on the draft. On Fri, Apr 29, 2016 at 12:50 AM, Lotte Steenbrink < lotte.steenbrink@fu-berlin.de> wrote: > Hi Jiazi, > thank you for your detailed review. A few comments and questions inline. > (I wanted to get this reply out the door as soon as I could, so I/we will > follow up regarding the yet unresponded to items later) > > Am 28.04.2016 um 16:53 schrieb Jiazi YI : > > Hi, > > Here is my preliminary review on aodvv2-15. There are still some points > that I'm not sure that I have fully understood -- I will get back to them > if I had time. > > A summary of my review: > > 1. The specification lacks of a "big picture" of the protocol functioning= . > People prefer to have a general idea of the whole protocol at the very > beginning. This is particularly important for readers who are not familia= r > with reactive protocol in general. > Some of the sections can be reorganized a bit to improve the readability. > For example, with the current structure, the readers need to reach sectio= n > 6.6 (Route discovery) before they can really touch the core function of t= he > protocol. > > 2. As an experimental protocol, the part related to experiments needs to > be improved. IMO, at least the following information must be provided: > - The motivation of this experimental document > - The experiments to be conducted > - What kind of feedback is expected to reported. > > 3. There are some redundant processing procedures in the draft. On the > other hand, some connections between the sections seem to be missing. > Sometimes it's hard to build connection between the message processing an= d > related information bases. > I think this is partially due to the lack of implementation, or the > implementation experience is not reported to the author team? > > 4. The specification uses lots of multicast messages. While multicast RRE= Q > is inevitable, the necessity of multicast RREP/RERR is not clear. It brin= g > issues related to control message overhead and security. > > 5. The interaction with RIB: The route state maintenance requires "*Local= Route.State > MUST be checked before IP packet forwarding and before any operation base= d > on LocalRoute.State.*". Having such check for each data packet might be > heavy load for the system if the routing daemon runs in userspace (becaus= e > of context switch). While interaction with RIB is inevitable, we want to > reduce it as much as possible -- per data packet operation is too much. > > > Hmmm. Yeah. To me it would make more sense to say "if you have a RIB, you > MUST update it any time LocalRoute.State changes [so instead of the polli= ng > described above, you=E2=80=99d let the changes =E2=80=9Etrickle up=E2=80= =9C and avid constant > context switches]. > Yes, that's reasonable. For packet forwarding, it's preferred to simply look at the RIB (other than route discovery is required). Checking the LocalRoute.State seems to be unnecessary and too much overhead. > If you don=E2=80=99t have a RIB and LocalRoute is consulted directly when > forwarding a packet [this would=E2=80=99ve been the case in RIOT a few re= leases > ago.. but there=E2=80=99s no kernel vs user space there either, so you wo= uldn=E2=80=99t > have the expensive context switches], you MUST check LocalRoute.State > before you forward to make sure the route is still valid.=E2=80=9C ... > > > 6. There are too many "MAY" and "SHOULD" in the document without > elaboration. Some of which might cause interoperability issues or even > loops. > > 8. security issues. There are discussions going on in different threads, > so I won't repeat them here. I think the current regeneration-based > approach is complex to secure and hard for future extensions. > > > We=E2=80=99ve gotten rid of that approach as of now. :) > > I haven't checked the security considerations section in detail yet. It's > important to get the big direction right first. > > Please check the details inline: > > *section 1, overview* > > The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol >> enables dynamic,* self-starting*, multihop routing > > > The term "self-starting" is very vague. It makes people think of > auto-configuration. And I didn't see such kind of feature is supported. I > would avoid using it. > > > Makes sense. I=E2=80=99ve removed the term. > > > AODVv2 is an Experimental protocol. >> ... > > > I think much more information is required here: > > 1) Because RFC 3561 has already been experimented for 13 years, as its > version 2, AODVv2 should summarize what kind of experiences have been > obtained in the past 13 years, and justify the design choices made in the > current draft (like use of RFC5444, removing some of the features, etc) > > 2) The motivation and experiments to be conducted need to be elaborated. > It's even necessary to have a separate section/subsection for it. Some > experiment points that come to my mind without much thinking: support of > multiple interfaces, support of gateways, use of different metrics, the > security model, etc.. > > > Fair enough. Thank you for the detailed pointers, I=E2=80=99ll write som= ething up > (unless my co-authors beat me to it ;) ) and get back to you, if that=E2= =80=99s > okay? > I think the one in -16 is much improved. thanks. > > > The basic operations of the AODVv2 protocol are route discovery and >> route maintenance... > > > It's necessary to give an overview of the basic functioning of the > protocol, rather than simply saying "use RREQ/RREP to carry information a= nd > build routes". Because after this, the draft jumps directly into the > protocol details. > It's extremely important for the readers who are not familiar with > reactive protocol. > > > Good point. we=E2=80=99ve removed =E2=80=9EThe basic operations of the AO= DVv2 protocol are > route discovery and route maintenance.=E2=80=9C, since that sentence occu= rs in the > first paragraph already, and we=E2=80=99ve substituted the =E2=80=9EAn AO= DVv2 router is > configured to perform route discovery=E2=80=A6=E2=80=9C paragraph with: > > The basic protocol mechanisms are as follows. Since AODVv2 is a > reactive protocol, route discovery is initiated only when a route to > the target is needed (i.e. when a router' client wants to send data). > AODVv2 does this with the help of a Route Request (RREQ) and Route > Reply (RREP) cycle: an RREQ is distributed across the network until > it arrives at the target. When forwarding an RREQ, all routers > across the network store the neighbor they've received the RREQ from, > memorizing a possible route back to the originator of the RREQ. When > the target receives the RREQ, it answers with an RREP, which then > travels back to the originator along the path memorized by the > intermediate routers. A metric value is included within the messages > to record the cost of the route. AODVv2 uses sequence numbers to > identify stale routing information, and compares route metric values > to determine if advertised routes could form loops. > > we=E2=80=99ve also slightly updated the language of the next pararaph: > > Route maintenance includes confirming bidirectionality of links to > next hop AODVv2 routers and issuing Route Error (RERR) messages > informing other routers of broken links. It also includes reacting > to received Route Error messages, and extending and enforcing route > timeouts. > > What do you think? > Yes. I think it gives a big picture of the protocol. > > > > *section 2, Terminology* > > Please pay attention to the style of the terms. Most of the time, style > like AckReq is used, but sometimes RERR_Gen is used. > Good to be consistent. > > > I think I=E2=80=99ve pointed out a similar issue too (in spring 2014, I t= hink?), > but I think I recall the conclusion being that while the draft should sti= ck > to CamelCase wherever it can, renaming RERR_Gen to RERRGen would have a > negative impact on readability, so there are some exceptions to the rule= =E2=80=A6 > Ok, fine. > > > Unreachable Address >> An address reported in a Route Error message, as described in >> Section 7.4.1. > > > need to explain what's the address for exactly, rather than giving a > pointer to a big section. > > > We had a longer explanation there but Justin said we should shorten it, s= o > we did that and added the pointer=E2=80=A6 :D > hmm... for me, when I try to figure out what's a term means exactly when reading through the document, I would jump to the terminology section, and expect a simple and clear definition in one or two sentences. Providing a pointer to a big chunk of text in after 40 pages won't improve the readability of the document. > > > *section 3, applicability statement* > > AODVv2 handles a wide variety of mobility and traffic patterns by >> determining routes on-demand... > > > It necessary to explicitly call out what kind of traffic patterns that > reactive protocols are not suitable for, such as lots of routers send dat= a > packets to instantaneous and multiple destinations. If that happens, what= 's > the consequence (broadcasting storm, etc). > > > Good point. We=E2=80=99ve reworded the paragraph to.. > > AODVv2 handles a wide variety of mobility and traffic patterns by > determining routes on-demand. In networks with a large number of > routers, AODVv2 is best suited for relatively sparse traffic > scenarios where each router forwards IP packets to a small percentage > of other AODVv2 routers in the network. In this case fewer routes > are needed, and therefore less control traffic is produced. In large > networks with very frequent or bursty traffic, AODVv2 control > messages may cause a broadcast storm, overwhelming the network with > control messages and preventing routes from being established. This > especially applies to networks with point-to-point or point-to- > multipoint traffic. In this case, the transmission priorities > described in Section 6.5 prioritize route maintenance traffic over > route discovery traffic. > > Data packets may be buffered until a route to their destination is > available, as described in Section 6.6. > > Does that help? > Yes. But pay attention that, the point is not "frequent" or "bursty" -- if it's between very small number of source/destination pairs, it doesn't matter. > > > >> AODVv2 provides for message integrity and security against replay >> attacks by using integrity check values, timestamps and sequence >> numbers, as described in Section 12. If security associations can be >> established, encryption can be used for AODVv2 messages to ensure >> that only trusted routers participate in routing operations. > > > We need to call out the hop-by-hop security model used, and the network > MUST apply necessary mechanisms to make sure that only trusted routers ca= n > participate in routing operations. > > > We=E2=80=99re currently working on getting rid of the hop by hop trust mo= del in > favor of end to end security. (I believe the thread is "Re: On > Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review -= a > couple of big ticket Items)=E2=80=9C?) > > > >> The routing algorithm in AODVv2 MAY be operated at layers other than >> the network layer, using layer-appropriate addresses. > > > Considering the deep coupling between AODVv2 and IP, I don't see how it > can work. This should be removed. > > *section 4 data structures* > > 4.1 Interface set > >> >> The InterfaceSet is a conceptual data structure which contains >> information about all interfaces available to AODVv2. >> ... >> Otherwise the InterfaceSet MAY be empty. > > > I'm not sure the sec MAY be empty -- a router contains at least one > interface, no? > > > Yes, but if it knows it only has one and it has access to this informatio= n > elsewhere and this won=E2=80=99t change, it might as well save the bytes = of stating > this again=E2=80=A6 Iirc the idea was to give implementations for constra= ined > devices a bit of leeway there. > I don't think it would save much by removing the single entry set -- instead, it might cause confusion. > > > 4.2 router client set > >> RouterClient.Cost >> The cost associated with reaching this address or address range. > > > Both "metric" and "cost" are used in the draft. If they are the same, > please pick a term and use it consistently. > > > Cost refers to the result of the Cost(L) function for the link to the > RouterClient. Would it make more sense it this entry was called LinkCost? > It's still a metric, no? Do we need to have a difference here? > > > >> The AODVv2 router adding the Router Client MUST wait for >> any existing routing information about this Router Client to be >> purged from the network, i.e., at least MAX_SEQNUM_LIFETIME since the >> last SeqNum update on the router which is removing this Router >> Client. > > > I'm not sure that I parsed this sentence correctly, but the > adding/removing of router client seems to be more an external operation a= nd > out of the control of routing protocol itself. > > > =E2=80=A6But even when it has no influence on when/whether a router is > added/removed, shouldn=E2=80=99t it still be able to deal with the conseq= uences? So > if an AODVv2 outer is assigned a client that has previously been attached > to a different router, it should make sure it doesn=E2=80=99t confuse the= network > (which is achieved by waiting >=3D MAX_SEQNUM_LIFETIME before fully treat= ing > it as its own client)? > > > 4.3 neighbor set > >> >> Neighbor.State ... There are three possible states: Confirmed, Unknown, >> and >> Blacklisted. Unknown is the initial state. > > > I think the "Unknown" is a bit confusing here. It's actually something we > already know -- a state that "we heard from that node, but > bi-directionality is not confirmed". > I think "Heard" is a more appropriate term to be used here. > > 4.4 sequence numbers > > I think the comparison in wrap-around cases should be specified here. > > Tod determine staleness, > > > typo > > > Whoopsie, thanks > > > 4.5 Local route set > >> >> Alternatively, implementations >> MAY choose to modify the Routing Information Base directly. > > > This should be either more precise (in which condition, how we can modify > the RIB?), or be removed. > > > Isn=E2=80=99t the how really implementation specific? > My point is that, the sentence is content-free, and we MAY do anything we want to the RIB, which is not good. > > >> Multiple valid routes for the same address and prefix length but for >> different metric types may exist in the Local Route Set, but the >> decision of which of these routes to install in the Routing >> Information Base to use for forwarding is outside the scope of >> AODVv2. > > > It's OK, but maybe some rules must be specified and followed. For example= , > the metric used must be the same: if a packet is forwarded using metric A > at router X, and then metric B at router Y, it's a obvious source of loop= s. > > > Of course, but that=E2=80=99s an issue of properly establishing routes, w= hich > should be specified farther along in the draft, shouldn=E2=80=99t it? The= purpose > of this paragraph is to say =E2=80=9Eyou can have multiple valid routes (= each > following one metric type) to the same destination, but we won=E2=80=99t = specify > how to pick which metric type is most important to you (i.e. which route > you trust the most).=E2=80=9C > > > 4.6. Multicast Route Message Set > > Since this set is mainly for duplicate packet detection, I think some of > the fields are kind of redundant. For example, an RREQ/RREP message can b= e > identified by its originator's address and sequence number, why 6 fields > (OrigAddr, OrigFprefixLen, OrigSeqNum, TargAddr, TargPrefixLen, TargSeqNu= m) > are necessary here. > > *section 5 Metrics* > > In Route Request messages, the metric describes the cost of the route >> from OrigAddr (and any other addresses included in the prefix length >> of RREQ_Gen's Router Client entry for OrigAddr) to the router sending >> the Route Request. > > > So the metric carried in the RREQ is the metric from Router Client to the > RREQ_Gen plus the metric from RREQ_Gen to the intermediate router. > In the Router Client Set, we have only one field for RouterClient.Cost. O= n > the other hand, "AODVv2 supports different metrics". > > routerClient.cost AODVv2 metric > client-----------------------RREQ_gen--------------- > > What if those two metrics are of different types? This is quite possible > because the two links might use different medium. > > > *section 6 AODVv2 protocol Operations* > > *General comments: * > > I think this section is hard to read and needs some reconstruction. > Generally speaking, people prefer begin from the important operations to > have a big picture/general idea of the protocol functioning, and then the > details. > With the current organization, one needs to read till section 6.6 (Route > discovery, retries and buffering) before he/she could reach the core > functioning of the protocol. > > I don't quite get the current organization of sections either. For exampl= e: > > section 6.2 (Next hop monitoring) and section 6.3 (Neighbor set update) > are very related. One is about the function, and one is about the > corresponding operation. The following sections don't follow this pattern > -- why not making them to one? > > section 6.7.1 (Evaluating route information) and section 6.8 (Suppressing > redundant messages using Multicast Route message set) seem to have some > overlapped operations. They all need to check the uniqueness of the > messages, compare the metrics and stop processing when duplication is > detected. Although they are applied to different information bases, they > are doing the same thing. > > section 6.9 (suppressing redundant RERR messages using the Route Error > set) should obviously a part of section 6.10.2 (reporting invalid routes)= , > but it's a separate section with higher hierarchy. > > more details inline: > > If such an entry does not exist, a new entry is created as described >> in Section 6.3. >> >> *While the value of Neighbor.State is Unknown, acknowledgement of RREP >> messages sent to that neighbor MUST be requested*. ... > > > I think we need to precise this is one for the case of RREP transmission. > > section 6.3 > > If an external mechanism reports a link as broken, the Neighbor Set >> entry SHOULD be removed. > > > I don't know why SHOULD, not MUST is used here. In fact, this is the only > place that I found that a Neighbor Set entry to be removed -- considering > the network is with constrained devices in a dynamic environment, isn't a > timer-based removing mechanisms is more adapted? > > >> an RREP which answers a RREQ sent within RREQ_WAIT_TIME over the >> same interface as Neighbor.Interface > > > I'm not a native English speaker, so I'm not sure about it should be "a > RREP" or "an RREP". But I think there is no reason to use them differentl= y > for RREQ/RREP? Need to check the consistency in the whole draft. > > > The =E2=80=9Ea RREQ=E2=80=9C is probably my fault, since I find that nota= tion more > intuitive as well, but we=E2=80=99ve decided that it should be =E2=80=9Ea= n RREQ=E2=80=9C, because > you=E2=80=99d pronounce it =E2=80=9Earr-reck=E2=80=9C, which warrants an = =E2=80=9Ean=E2=80=9C in front of it. > Thanks for the hint, I=E2=80=99ve checked the draft and found more of the= se errors, > all fixed now. > thanks. > > > section 6.4. Interaction with the Forwarding Plane > > o A route has been updated: update the corresponding route in the >> Routing Information Base. > > > Do we need to pay attention to the "multi-metrics" issue here? To support > multi-metrics, do we need special fields in the RIB? If so, we need to ca= ll > it out in the applicability statement. > > > I=E2=80=99d guess it depends where you=E2=80=99re choosing one route over= the other? If > the RIB supports multiple metrics and can sort it out that=E2=80=99s grea= t, if not > you might want to decide which route to propagate on to the RIB based on > its metric, or you might want to =E2=80=9Etranslate=E2=80=9C metrics into= differently > prioritized routes in the RIB? (if that makes sense, it should probably b= e > mentioned in 4.5. Local Route Set though) > I don't have a solution by hand yet. But as mentioned in my previous comments, having multiple entries to the same destination can be dangerous. For example, a packet requires to be routed using metric type A. Router X has a route supporting metric type A, so it forwards the packet. When the packet arrives at Router Y .... woops, the route with metric type A is invalid, but Router Y has a route with metric type B... should it be used? A safer way is, of course, discarding the packet to avoid loops -- but is it acceptable? > > > section 6.5. Message Transmission > >> >> To implement the congestion control, a queue length is set. If the >> queue is full, in order to queue a new message, a message of lower >> priority must be removed from the queue. If this is not possible, >> the new message MUST be discarded. The queue should be sorted in >> order of message priority. > > > I think it's more implementation details rather than specification. > > section 6.6 > >> >> The constants used inSection 6.7.1 this section are >> defined in Section 10. > > > misplaced reference > > > Oh, thanks. Fixed. > > > section 6.7.1 > > 4. Compare route costs >> * If AdvRte is better than all matching LocalRoutes, it SHOULD >> be used to update the Local Route Set because it offers >> improvement. >> >> *If it is not used to update the Local Route Set, the existing >> non-optimal LocalRoute will continue to be used, causing data >> traffic to use a non-optimal route.* > > > If some routers made the update, and some routers choose not updating, I'= m > afraid there will be loops in the network. > > * If AdvRte is worse and LocalRoute is valid, ignore AdvRte for >> further processing. AdvRte MUST NOT be used to update the >> Local Route Set because it does not offer any improvement. >> * If AdvRte is not better (i.e., it is worse or equal) but >> LocalRoute is Invalid, AdvRte SHOULD be used to update the >> Local Route Set because it can safely repair the existing >> Invalid LocalRoute. > > > shouldn=E2=80=99t worse AdvRte is already filtered by the LoopFree functi= on in the > previous step 3? > > section 6.7.2. Applying Route Updates > >> If there is no existing matching route, >> AdvRte allows a corresponding RREP to be sent. > > > I don't quite get why this relevant to RREP sending here. > > > Yeah=E2=80=A6 Honestly I don=E2=80=99t get this one either. I=E2=80=99d j= ust delete it? Anybody > against that? > > > >> 7. If an existing LocalRoute.State changed from Invalid or >> Unconfirmed to become Idle, any matching Unconfirmed LocalRoute >> with worse metric value SHOULD be expunged. >> 8. If an existing LocalRoute was updated with a better metric value, >> any matching Unconfirmed LocalRoute with worse metric value >> SHOULD be expunged. >> 9. If this update results in LocalRoute.State of Active or Idle, >> which matches a route request which is still in progress, the >> associated route request retry timers SHOULD be cancelled. > > > why "SHOULD", not "MUST" here? > > 6.8. Suppressing Redundant Messages Using the Multicast Route Message > Set > > the processes defined in this section overlap with section 6.7.1 (bullet > 1-2-3-4) > > section 6.10 Local route set maintenance > > >> During normal operation, AODVv2 does not require any explicit >> timeouts to manage the lifetime of a route. At any time, any >> LocalRoute MAY be examined and updated according to the rules below. >> If timers are not used to prompt updates of LocalRoute.State >> >> *, the LocalRoute.State MUST be checked before IP packet forwarding >> and before any operation based on LocalRoute.State*. >> > > I don't think this is an efficient approach. If the routing daemon runs i= n > user space (which is true in most cases), this normally means context > switch. This is inevitable for reactive protocols, but doing so per packe= t > seems to be expensive. > > > see above :) > > > > *section 7 AODVv2 Protocol Messages* > > general comments: > - the message regeneration, rather than the message forwarding, plus > different optional fields make the protocol hard to secure > > > fixed now > > - the tradeoff of using multicast RREP and RERR need to be carefully > considered. > - the tradeoff of using ValidityTime needs to be carefully considered > > > We=E2=80=99ve removed ValidityTime just now > > > section 7.1 > > >> PrefixLengthList >> Contains OrigPrefixLen, i.e., the length, in bits, of the prefix >> associated with the Router Client entry which includes OrigAddr. >> If omitted, the prefix length is equal to OrigAddr's address >> length in bits. > > > it seems that only one prefix length is needed, why "list"? > > > ValidityTime >> The length of time that the message sender is willing to offer a >> route toward OrigAddr (and any other addresses included in the >> given prefix length). Omitted if no time limit is imposed. > > > the necessity of using ValidityTime has been raised here > https://www.ietf.org/mail-archive/web/manet/current/msg18852.html > > >> 5. Include MetricType and set the type accordingly >> 6. Set OrigMetric :=3D RouterClient.Cost for the Router Client entry >> which includes OrigAddr > > > What if the metric type of the RouterClient.Cost is different from the > metric type to be used in the route discovery? In fact, this is quite > possible because they probably use different types of medium. > > However, the regenerated RREQ can >> be unicast to the next hop address of the LocalRoute toward TargAddr, >> if known. > > > This can be a problem if the TargAddr is known to the routing set, but th= e > link is actually broken. Because there is no related RERR messages to > notify that, the following route discovery retries might fail also. A mor= e > careful design is required if unicast RREQ is to be used. > > 7.2. Route Reply (RREP) Message > > I don't quite understand the purpose of multicast RREP. There are, > however, lots of disadvantages of using an optional AckReq field. > This has been discussed in another thread > https://www.ietf.org/mail-archive/web/manet/current/msg18864.html > > >> Before creating an RREP, the router SHOULD check if the corresponding >> RREQ is redundant, i.e., a Route Reply has already been generated in >> response to the RREQ, or if the limit for the rate of AODVv2 control >> message generation has been reached. If so, the RREP SHOULD NOT be >> created. > > > What about if the RREQ carries a better route? > > > Then it=E2=80=99s not redundant? Or do you mean the SHOULD NOT be created= part? > The idea of these priorities is that already established routes should be > protected before new routes are created, so even if the new RREQ is bette= r, > updating this route would strain the network even more, preventing routes > from working, which in turn triggers more RREQs.. etc etc. So I=E2=80=99d= say it=E2=80=99s > a pity but we have no other option but to drop the better RREQ? > hmmm... what I understand is that, the intermediate routers will process the RREQ carrying better route, but then the corresponding RREP won't be generated? best Jiazi > (I=E2=80=99ve also substituted =E2=80=9Ethe limit for the rate of AODVv2 = control message > generation=E2=80=9C for =E2=80=9E CONTROL_TRAFFIC_LIMIT=E2=80=9C in the D= raft now since that seemed > more concise ;) ) > > > 7.3.2 RREP_Ack Reception > > it seems that some action is missing after the step 2 Neighbour set > update. At least, we need to update the Local Route Set? > > 7.4.1 RERR generation > > Is it necessary to generate RERR for RREP failure? > > > >> If there is no route to PktSource, the RERR SHOULD be >> multicast to LL-MANET-Routers. If the RERR is sent in response to a >> broken link, i.e., PktSource is not included, the RERR is, by >> default, multicast to LL-MANET-Routers. > > > Although I know the purpose of using RERR message is to inform as many > routers as possible about the route breakage information, it seems to be > huge overhead, and more importantly, an appealing attack vector for > hackers. > > 7.4.3 RERR regeneration > > 2. For each LocalRoute that needs to be reported as identified in >> Section 7.4.1: >> * Insert LocalRoute.Address into the AddressList. > > > The AddressList can changed on every RERR regeneration. On the other hand= , > in section 6.9 (suppressing redundant RERR), the uniqueness of RERR is > determined by AddressList and PktSource (optional). It seems to me that t= he > suppressing won't be able to work correctly? > > One more note: > > Jitter is not mentioned in the draft, which is important because the > multicast messages used. I can see RFC5148 in the reference section, but > didn't find where it is used. > > best > > Jiazi > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > Best regards, > Lotte > > > --001a113f1fe4be995a053270c6be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lotte, all:

Although the chairs have= made their decision on aodvv2, I'm providing my response to your comme= nts below, in case you want to continue working on the draft.=C2=A0

On Fri, Apr 29, 2016 = at 12:50 AM, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
Hi Jiazi,
thank you for your detailed review. A few com= ments and questions inline. (I wanted to get this reply out the door as soo= n as I could, so I/we will follow up regarding the yet unresponded to items= later)


Hi,=C2=A0

Here is my preliminary review = on aodvv2-15. There are still some points that I'm not sure that I have= fully understood -- I will get back to them if I had time.=C2=A0

A summary of my review:

1. The spe= cification lacks of a "big picture" of the protocol functioning. = People prefer to have a general idea of the whole protocol at the very begi= nning. This is particularly important for readers who are not familiar with= reactive protocol in general.=C2=A0
Some of the sections can be = reorganized a bit to improve the readability. For example, with the current= structure, the readers need to reach section 6.6 (Route discovery) before = they can really touch the core function of the protocol.=C2=A0
2. As an experimental protocol, the part related to experiment= s needs to be improved. IMO, at least the following information must be pro= vided:
=C2=A0 =C2=A0 =C2=A0 =C2=A0- The motivation of this experi= mental document=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0- The experiment= s to be conducted=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0- What kind of= feedback is expected to reported. =C2=A0

3. There= are some redundant processing procedures in the draft. On the other hand, = some connections between the sections seem to be missing. Sometimes it'= s hard to build connection between the message processing and related infor= mation bases.=C2=A0
I think this is partially due to the lack of = implementation, or the implementation experience is not reported to the aut= hor team?

4. The specification uses lots of multic= ast messages. While multicast RREQ is inevitable, the necessity of multicas= t RREP/RERR is not clear. It bring issues related to control message overhe= ad and security.=C2=A0

5. The interaction with RIB= : The=C2=A0route state maintenance=C2=A0requires "LocalRoute.State = MUST be checked before IP packet forwarding and before any operation based = on LocalRoute.State.". Having such check for each data packet migh= t be heavy load for the system if the routing daemon runs in userspace (bec= ause of context switch). While interaction with RIB is inevitable, we want = to reduce it as much as possible -- per data packet operation is too much.= =C2=A0

Hmmm. Yeah.= To me it would make more sense to say "if you have a RIB, you MUST up= date it any time LocalRoute.State changes [so instead of the polling descri= bed above, you=E2=80=99d let the changes =E2=80=9Etrickle up=E2=80=9C and a= vid constant context switches].
<= br>
Yes, that's reasonable. For packet forwarding, it's p= referred to simply look at the RIB (other than route discovery is required)= . Checking the LocalRoute.State seems to be unnecessary and too much overhe= ad.=C2=A0
=C2=A0
If you don=E2=80=99t have a RIB an= d LocalRoute is consulted directly when forwarding a packet [this would=E2= =80=99ve been the case in RIOT a few releases ago.. but there=E2=80=99s no = kernel vs user space there either, so you wouldn=E2=80=99t have the expensi= ve context switches], you MUST check LocalRoute.State before you forward to= make sure the route is still valid.=E2=80=9C ...


6. There are too many "MAY" and &quo= t;SHOULD" in the document without elaboration. Some of which might cau= se interoperability issues or even loops.=C2=A0

8.= security issues. There are discussions going on in different threads, so I= won't repeat them here. I think the current regeneration-based approac= h is complex to secure and hard for future extensions.=C2=A0

We=E2=80=99ve gotten rid of tha= t approach as of now. :)

I haven't checked the security considerati= ons section in detail yet. It's important to get the big direction righ= t first.=C2=A0

Please check the details inline= :

section 1, overview

<= div>
=C2=A0 =C2=A0The Ad hoc On-Demand Distance Vector Vers= ion 2 (AODVv2) protocol
=C2=A0 =C2=A0enables dynamic, self-starting, multihop routing

The term "self-st= arting" is very vague. It makes people think of auto-configuration. An= d I didn't see such kind of feature is supported. I would avoid using i= t.=C2=A0

Mak= es sense. I=E2=80=99ve removed the term.


=C2=A0 AODVv2 is an Experimental pr= otocol.
=C2=A0...
=C2=A0
I think= much more information is required here:

1) Becaus= e RFC 3561 has already been experimented for 13 years, as its version 2, AO= DVv2 should summarize what kind of experiences have been obtained in the pa= st 13 years, and justify the design choices made in the current draft (like= use of RFC5444, removing some of the features, etc)

2) The motivation and experiments to be conducted need to be elaborated.= It's even necessary to have a separate section/subsection for it. Some= experiment points that come to my mind without much thinking: support of m= ultiple interfaces, support of gateways, use of different metrics, the secu= rity model, etc..

= Fair enough.=C2=A0 Thank you for the detailed pointers, I=E2=80=99ll write = something up (unless my co-authors beat me to it ;) ) and get back to you, = if that=E2=80=99s okay?

=
I think the one in -16 is much improved. thanks.=C2=A0
=C2= =A0


=C2=A0 =C2=A0The basic operations= of the AODVv2 protocol are route discovery and
=C2=A0 =C2=A0route maint= enance...

It's necessary to give = an overview of the basic functioning of the protocol, rather than simply sa= ying "use RREQ/RREP to carry information and build routes". Becau= se after this, the draft jumps directly into the protocol details.=C2=A0
It's extremely important for the readers who are not familiar w= ith reactive protocol.

=
Good point. we=E2=80=99ve removed =E2=80=9EThe basic operations of the= AODVv2 protocol are route discovery and route maintenance.=E2=80=9C, since= that sentence occurs in the first paragraph already, and we=E2=80=99ve sub= stituted the =E2=80=9EAn AODVv2 router is configured to perform route disco= very=E2=80=A6=E2=80=9C paragraph with:

<= font face=3D"Courier">=C2=A0 =C2=A0The basic protocol mechanisms are as fol= lows.=C2=A0 Since AODVv2 is a
=C2= =A0 =C2=A0reactive protocol, route discovery is initiated only when a route= to
=C2=A0 =C2=A0the target is need= ed (i.e. when a router' client wants to send data).
=C2=A0 =C2=A0AODVv2 does this with the help of a Route= Request (RREQ) and Route
=C2=A0 = =C2=A0Reply (RREP) cycle: an RREQ is distributed across the network until
=C2=A0 =C2=A0it arrives at the targe= t.=C2=A0 When forwarding an RREQ, all routers
=C2=A0 =C2=A0across the network store the neighbor they've= received the RREQ from,
=C2=A0 =C2= =A0memorizing a possible route back to the originator of the RREQ.=C2=A0 Wh= en
=C2=A0 =C2=A0the target receives= the RREQ, it answers with an RREP, which then
=C2=A0 =C2=A0travels back to the originator along the path mem= orized by the
=C2=A0 =C2=A0intermed= iate routers.=C2=A0 A metric value is included within the messages
=C2=A0 =C2=A0to record the cost of the rout= e.=C2=A0 AODVv2 uses sequence numbers to
=C2=A0 =C2=A0identify stale routing information, and compares route m= etric values
=C2=A0 =C2=A0to determ= ine if advertised routes could form loops.

we=E2=80=99ve also slightly updated the language of the next pararaph= :

=C2=A0 =C2=A0Route m= aintenance includes confirming bidirectionality of links to
=C2=A0 =C2=A0next hop AODVv2 routers and issuing R= oute Error (RERR) messages
=C2=A0 = =C2=A0informing other routers of broken links.=C2=A0 It also includes react= ing
=C2=A0 =C2=A0to received Route = Error messages, and extending and enforcing route
=C2=A0 =C2=A0timeouts.

What do you think?

Yes. I think it gives a big picture of the protocol.=C2=A0
=C2=A0

=C2=A0

section 2, Terminology=

Please pay attention to the style of the terms. M= ost of the time, style like AckReq is used, but sometimes RERR_Gen is used.= =C2=A0
Good to be consistent.=C2=A0

I think I=E2=80=99ve pointed out a similar issu= e too (in spring 2014, I think?), but I think I recall the conclusion being= that while the draft should stick to CamelCase wherever it can, renaming R= ERR_Gen to RERRGen would have a negative impact on readability, so there ar= e some exceptions to the rule=E2=80=A6
=

Ok, fine.=C2=A0
=C2=A0


=C2=A0 =C2=A0Unreachable Address
=C2=A0 =C2=A0 =C2= =A0 An address reported in a Route Error message, as described in
=C2=A0= =C2=A0 =C2=A0 Section 7.4.1.

need to= explain what's the address for exactly, rather than giving a pointer t= o a big section.=C2=A0

=
We had a longer explanation there but Justin said we should shorten it= , so we did that and added the pointer=E2=80=A6 :D
<= /blockquote>

hmm... for me, when I try to figure out wha= t's a term means exactly when reading through the document, I would jum= p to the terminology section, and expect a simple and clear definition in o= ne or two sentences. Providing a pointer to a big chunk of text in after 40= pages won't improve the readability of the document.=C2=A0
= =C2=A0


section 3, applicability statement

=C2=A0 =C2=A0AODVv2 handles a = wide variety of mobility and traffic patterns by
=C2=A0 =C2=A0determinin= g routes on-demand...

It necessary to expli= citly call out what kind of traffic patterns that reactive protocols are no= t suitable for, such as lots of routers send data packets to instantaneous = and multiple destinations. If that happens, what's the consequence (bro= adcasting storm, etc).=C2=A0

<= /div>
Good point. We=E2=80=99ve reworded the paragraph to..

=C2=A0 = =C2=A0AODVv2 handles a wide variety of mobility and traffic patterns by
=C2=A0 =C2=A0determining routes= on-demand.=C2=A0 In networks with a large number of
=C2=A0 =C2=A0routers, AODVv2 is best suited for relativel= y sparse traffic
=C2=A0 =C2=A0scena= rios where each router forwards IP packets to a small percentage
=C2=A0 =C2=A0of other AODVv2 routers in the n= etwork.=C2=A0 In this case fewer routes
=C2=A0 =C2=A0are needed, and therefore less control traffic is produce= d.=C2=A0 In large
=C2=A0 =C2=A0netw= orks with very frequent or bursty traffic, AODVv2 control
= =C2=A0 =C2=A0messages may cause a broadcast storm, o= verwhelming the network with
=C2=A0= =C2=A0control messages and preventing routes from being established.=C2=A0= This
=C2=A0 =C2=A0especially appli= es to networks with point-to-point or point-to-
=C2=A0 =C2=A0multipoint traffic.=C2=A0 In this case, the trans= mission priorities
=C2=A0 =C2=A0des= cribed in Section 6.5 prioritize route maintenance traffic over
=C2=A0 =C2=A0route discovery traffic.

=C2=A0 =C2=A0Data packets may be buffered until a route to their destinat= ion is
=C2=A0 =C2=A0available, as d= escribed in Section 6.6.

Does that help?

Yes. But pay at= tention that, the point is not "frequent" or "bursty" -= - if it's between very small number of source/destination pairs, it doe= sn't matter.
=C2=A0

=C2=A0
= =C2=A0 =C2=A0AODVv2 provides for message integrity and security against rep= lay
=C2=A0 =C2=A0attacks by using integrity check values, timestamps and= sequence
=C2=A0 =C2=A0numbers, as described in Section 12.=C2=A0 If sec= urity associations can be
=C2=A0 =C2=A0established, encryption can be us= ed for AODVv2 messages to ensure
=C2=A0 =C2=A0that only trusted routers = participate in routing operations.=C2=A0

<= div>We need to call out the hop-by-hop security model used, and the network= MUST apply necessary mechanisms to make sure that only trusted routers can= participate in routing operations.=C2=A0

We=E2=80=99re currently working on getting rid of t= he hop by hop trust model in favor of end to end security. (I believe the t= hread is "Re: On Forwarding-and-regeneration (was: Re: draft-ietf-mane= t-aodvv2-13 review - a couple of big ticket Items)=E2=80=9C?)

=C2=A0
=C2=A0 =C2=A0The routing algorithm in AODVv2 MAY be ope= rated at layers other than
=C2=A0 =C2=A0the network layer, using layer-a= ppropriate addresses.

Considering the deep = coupling between AODVv2 and IP, I don't see how it can work. This shoul= d be removed.=C2=A0

section 4 data structures

4.1 Interface set
=
The InterfaceSet is a conceptual data structure which contains
=C2= =A0 =C2=A0information about all interfaces available to AODVv2.
...
O= therwise the InterfaceSet MAY be empty.

I&#= 39;m not sure the sec MAY be empty -- a router contains at least one interf= ace, no?=C2=A0

Yes= , but if it knows it only has one and it has access to this information els= ewhere and this won=E2=80=99t change, it might as well save the bytes of st= ating this again=E2=80=A6 Iirc the idea was to give implementations for con= strained devices a bit of leeway there.

I don't think it would save much by removing the s= ingle entry set -- instead, it might cause confusion.=C2=A0
=C2= =A0


4.2 router client set
=C2=A0= =C2=A0RouterClient.Cost
=C2=A0 =C2=A0 =C2=A0 The cost associated with r= eaching this address or address range.

Both= "metric" and "cost" are used in the draft. If they are= the same, please pick a term and use it consistently.=C2=A0

Cost refers to the result of the= Cost(L) function for the link to the RouterClient. Would it make more sens= e it this entry was called LinkCost?

It's still a metric, no? Do we need to have a differe= nce here?=C2=A0
=C2=A0

=C2=A0
The= AODVv2 router adding the Router Client MUST wait for
=C2=A0 =C2=A0any e= xisting routing information about this Router Client to be
=C2=A0 =C2=A0= purged from the network, i.e., at least MAX_SEQNUM_LIFETIME since the
= =C2=A0 =C2=A0last SeqNum update on the router which is removing this Router=
=C2=A0 =C2=A0Client.=C2=A0

I'm not = sure that I parsed this sentence correctly, but the adding/removing of rout= er client seems to be more an external operation and out of the control of = routing protocol itself.=C2=A0

=E2=80=A6But even when it has no influence on when/whether a r= outer is added/removed, shouldn=E2=80=99t it still be able to deal with the= consequences? So if an AODVv2 outer is assigned a client that has previous= ly been attached to a different router, it should make sure it doesn=E2=80= =99t confuse the network (which is achieved by waiting >=3D MAX_SEQNUM_L= IFETIME before fully treating it as its own client)?=C2=A0

<= div dir=3D"ltr">

4.3 neighbor set
=
=C2=A0Neighbor.State ... There are three possible states: Confirmed, Un= known, and
=C2=A0 =C2=A0 =C2=A0 Blacklisted.=C2=A0 Unknown is the initia= l state.

I think the "Unknown" is= a bit confusing here. It's actually something we already know -- a sta= te that "we heard from that node, but bi-directionality is not confirm= ed".=C2=A0
I think "Heard" is a more appropriate t= erm to be used here.=C2=A0

4.4 sequence numbers

I think the comparison in wrap-around cases should b= e specified here.=C2=A0

Tod determine = staleness,

typo

Whoopsie, thanks


4.5 Local= route set

Alternatively, implementations
=C2= =A0 =C2=A0MAY choose to modify the Routing Information Base directly.

This should be either more precise (in which con= dition, how we can modify the RIB?), or be removed. =C2=A0

Isn=E2=80=99t the how really imple= mentation specific?

My point is that, the sentence is content-free, and we MAY do anything we = want to the RIB, which is not good.=C2=A0
=C2=A0
= =C2=A0 =C2=A0Multiple valid routes for the same address and prefix length b= ut for
=C2=A0 =C2=A0different metric types may exist in the Local Route = Set, but the
=C2=A0 =C2=A0decision of which of these routes to install i= n the Routing
=C2=A0 =C2=A0Information Base to use for forwarding is out= side the scope of
=C2=A0 =C2=A0AODVv2.

I= t's OK, but maybe some rules must be specified and followed. For exampl= e, the metric used must be the same: if a packet is forwarded using metric = A at router X, and then metric B at router Y, it's a obvious source of = loops.=C2=A0

Of co= urse, but that=E2=80=99s an issue of properly establishing routes, which sh= ould be specified farther along in the draft, shouldn=E2=80=99t it? The pur= pose of this paragraph is to say =E2=80=9Eyou can have multiple valid route= s (each following one metric type) to the same destination, but we won=E2= =80=99t specify how to pick which metric type is most important to you (i.e= . which route you trust the most).=E2=80=9C=C2=A0


4.6.=C2=A0 Multicast Route Message Set
=

Since this set is mainly for duplicate packet det= ection, I think some of the fields are kind of redundant. For example, an R= REQ/RREP message can be identified by its originator's address and sequ= ence number, why 6 fields (OrigAddr, OrigFprefixLen, OrigSeqNum, TargAddr, = TargPrefixLen, TargSeqNum) are necessary here.=C2=A0

section 5 Metrics

=C2=A0 =C2=A0In Route Request messages, the metric describes the cost of = the route
=C2=A0 =C2=A0from OrigAddr (and any other addresses included i= n the prefix length
=C2=A0 =C2=A0of RREQ_Gen's Router Client entry f= or OrigAddr) to the router sending
=C2=A0 =C2=A0the Route Request.=C2=A0=

So the metric carried in the RREQ is= the metric from Router Client to the RREQ_Gen plus the metric from RREQ_Ge= n to the intermediate router.=C2=A0
In the Router Client Set, we = have only one field for RouterClient.Cost. On the other hand, "AODVv2 = supports different metrics".=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 routerClient.c= ost =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AODVv2 metric=C2=A0
client-----------------------RR= EQ_gen---------------

What if those two met= rics are of different types? This is quite possible because the two links m= ight use different medium.=C2=A0


section 6 AODVv2 protocol Operations

<= i>General comments:=C2=A0

I think this section= is hard to read and needs some reconstruction. Generally speaking, people = prefer begin from the important operations to have a big picture/general id= ea of the protocol functioning, and then the details.=C2=A0
With = the current organization, one needs to read till section 6.6 (Route discove= ry, retries and buffering) before he/she could reach the core functioning o= f the protocol.=C2=A0

I don't quite get the cu= rrent organization of sections either. For example:

section 6.2 (Next hop monitoring) and section 6.3 (Neighbor set update) a= re very related. One is about the function, and one is about the correspond= ing operation. The following sections don't follow this pattern -- why = not making them to one?

section 6.7.1 (Evaluating = route information) and section 6.8 (Suppressing redundant messages using Mu= lticast Route message set) seem to have some overlapped operations. They al= l need to check the uniqueness of the messages, compare the metrics and sto= p processing when duplication is detected. Although they are applied to dif= ferent information bases, they are doing the same thing.=C2=A0
section 6.9 (suppressing redundant RERR messages using the Rou= te Error set) should obviously a part of section 6.10.2 (reporting invalid = routes), but it's a separate section with higher hierarchy.=C2=A0
=

more details inline:

=C2=A0 =C2=A0If such an entry does not exist, a new entry is create= d as described
=C2=A0 =C2=A0in Section 6.3. =C2=A0While the value of = Neighbor.State is Unknown,
=C2=A0 =C2=A0acknowledgement of RREP messages= sent to that neighbor MUST be
=C2=A0 =C2=A0requested. ...

I think we need to precise this is one for the case = of RREP transmission.=C2=A0

section 6.3
=
=C2=A0 =C2=A0If an external mechanism repor= ts a link as broken, the Neighbor Set
=C2=A0 =C2=A0entry SHOULD be remov= ed.

I don't know why SHOULD, not = MUST is used here. In fact, this is the only place that I found that a Neig= hbor Set entry to be removed -- considering the network is with constrained= devices in a dynamic environment, isn't a timer-based removing mechani= sms is more adapted?
=C2=A0
=C2=A0 an RREP = which answers a RREQ sent within RREQ_WAIT_TIME over the
=C2=A0 =C2=A0 = =C2=A0 same interface as Neighbor.Interface

I'm not a native English speaker, so I'm not sure about it should = be "a RREP" or "an RREP". But I think there is no reaso= n to use them differently for RREQ/RREP? Need to check the consistency in t= he whole draft.=C2=A0

The =E2=80=9Ea RREQ=E2=80=9C is probably my fault, since I f= ind that notation more intuitive as well, but we=E2=80=99ve decided that it= should be =E2=80=9Ean RREQ=E2=80=9C, because you=E2=80=99d pronounce it = =E2=80=9Earr-reck=E2=80=9C, which warrants an =E2=80=9Ean=E2=80=9C in front= of it. Thanks for the hint, I=E2=80=99ve checked the draft and found more = of these=C2=A0errors, all fixed now.

thanks.
=C2=A0


s= ection 6.4.=C2=A0 Interaction with the Forwarding Plane
=C2=A0 =C2=A0o =C2=A0A route has been updated: upda= te the corresponding route in the
=C2=A0 =C2=A0 =C2=A0 Routing Informati= on Base.

Do we need to pay attention = to the "multi-metrics" issue here? To support multi-metrics, do w= e need special fields in the RIB? If so, we need to call it out in the appl= icability statement.=C2=A0

I=E2=80=99d guess it depends where you=E2=80=99re choosing one rou= te over the other? If the RIB supports multiple metrics and can sort it out= that=E2=80=99s great, if not you might want to decide which route to propa= gate on to the RIB based on its metric, or you might want to =E2=80=9Etrans= late=E2=80=9C metrics into differently prioritized routes in the RIB? (if t= hat makes sense, it should probably be mentioned in=C2=A04.5.=C2=A0 Local R= oute Set though)

I = don't have a solution by hand yet. But as mentioned in my previous comm= ents, having multiple entries to the same destination can be dangerous. For= example, a packet requires to be routed using metric type A. Router X has = a route supporting metric type A, so it forwards the packet. When the packe= t arrives at Router Y .... woops, the route with metric type A is invalid, = but Router Y has a route with metric type B... should it be used? A safer w= ay is, of course, discarding the packet to avoid loops -- but is it accepta= ble?=C2=A0
=C2=A0


section 6.5.=C2=A0 Mess= age Transmission

=C2=A0 =C2=A0To implement th= e congestion control, a queue length is set.=C2=A0 If the
=C2=A0 =C2=A0q= ueue is full, in order to queue a new message, a message of lower
=C2=A0= =C2=A0priority must be removed from the queue.=C2=A0 If this is not possib= le,
=C2=A0 =C2=A0the new message MUST be discarded.=C2=A0 The queue shou= ld be sorted in
=C2=A0 =C2=A0order of message priority.=C2=A0

I think it's more implementation details rather t= han specification. =C2=A0

section 6.6=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
The constants used inSection 6.7.1 this section are
= =C2=A0 =C2=A0defined in Section 10.

misplac= ed reference

Oh, t= hanks. Fixed.


section 6.7.1

=C2=A0 =C2=A04.=C2=A0 Compare route costs
=C2=A0 =C2=A0 = =C2=A0 =C2=A0* =C2=A0If AdvRte is better than all matching LocalRoutes, it = SHOULD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be used to update the Local Ro= ute Set because it offers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 improvement= . =C2=A0If it is not used to update the Local Route Set,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 the existing non-optimal LocalRoute will continue = to be used,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 causing data traffic to u= se a non-optimal route.

If some r= outers made the update, and some routers choose not updating, I'm afrai= d there will be loops in the network.=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0If AdvRte is worse and LocalR= oute is valid, ignore AdvRte for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 furt= her processing.=C2=A0 AdvRte MUST NOT be used to update the
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Local Route Set because it does not offer any impr= ovement.
=C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0If AdvRte is not better (i.e= ., it is worse or equal) but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LocalRou= te is Invalid, AdvRte SHOULD be used to update the
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Local Route Set because it can safely repair the existing
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Invalid LocalRoute.

shouldn=E2=80=99t worse AdvRte is already filtered by the= LoopFree function in the previous step 3?

sec= tion 6.7.2.=C2=A0 Applying Route Updates
If = there is no existing matching route,
=C2=A0 =C2=A0AdvRte allows a corres= ponding RREP to be sent.=C2=A0

I don&= #39;t quite get why this relevant to RREP sending here.=C2=A0

Yeah=E2=80=A6 Honestly I don=E2= =80=99t get this one either. I=E2=80=99d just delete it? Anybody against th= at?

=C2=A0
=C2=A0 =C2=A07.=C2=A0 If an existing L= ocalRoute.State changed from Invalid or
=C2=A0 =C2=A0 =C2=A0 =C2=A0Uncon= firmed to become Idle, any matching Unconfirmed LocalRoute
=C2=A0 =C2=A0= =C2=A0 =C2=A0with worse metric value SHOULD be expunged.
=C2=A0 =C2=A08= .=C2=A0 If an existing LocalRoute was updated with a better metric value,=C2=A0 =C2=A0 =C2=A0 =C2=A0any matching Unconfirmed LocalRoute with worse= metric value
=C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD be expunged.
=C2=A0 = =C2=A09.=C2=A0 If this update results in LocalRoute.State of Active or Idle= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0which matches a route request which is stil= l in progress, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0associated route request r= etry timers SHOULD be cancelled.

why "= SHOULD", not "MUST" here?=C2=A0

6.8.=C2=A0 Suppressing Redundant Messages Using the Multicast Route Messa= ge
=C2=A0 =C2=A0 =C2=A0 Set

the pr= ocesses defined in this section overlap with section 6.7.1 (bullet 1-2-3-4)=

section 6.10 Local route set maintenance
=C2=A0
=C2=A0 =C2=A0During normal operation, AODVv2= does not require any explicit
=C2=A0 =C2=A0timeouts to manage the lifet= ime of a route.=C2=A0 At any time, any
=C2=A0 =C2=A0LocalRoute MAY be ex= amined and updated according to the rules below.
=C2=A0 =C2=A0If timers = are not used to prompt updates of LocalRoute.State, the
=C2=A0 =C2=A0= LocalRoute.State MUST be checked before IP packet forwarding and
=C2=A0 = =C2=A0before any operation based on LocalRoute.State.
<= div>
I don't think this is an efficient approach. If the = routing daemon runs in user space (which is true in most cases), this norma= lly means context switch. This is inevitable for reactive protocols, but do= ing so per packet seems to be expensive.=C2=A0

see above :)



section 7 AODVv2 Protocol Messages

general= comments:
=C2=A0 - the message regeneration, rather than the mes= sage forwarding, plus different optional fields make the protocol hard to s= ecure=C2=A0

fixed = now

=C2=A0 - the tradeoff of using multicast RREP and RERR need to be c= arefully considered.=C2=A0
=C2=A0 - the tradeoff of using Validit= yTime needs to be carefully considered
<= br>
We=E2=80=99ve removed ValidityTime just now
=

=
section 7.1
=C2=A0
=C2=A0 = =C2=A0PrefixLengthList
=C2=A0 =C2=A0 =C2=A0 Contains OrigPrefixLen, i.e.= , the length, in bits, of the prefix
=C2=A0 =C2=A0 =C2=A0 associated wit= h the Router Client entry which includes OrigAddr.
=C2=A0 =C2=A0 =C2=A0 = If omitted, the prefix length is equal to OrigAddr's address
=C2=A0 = =C2=A0 =C2=A0 length in bits.

it seems that= only one prefix length is needed, why "list"?


=C2=A0 =C2=A0ValidityTime
=C2=A0 =C2= =A0 =C2=A0 The length of time that the message sender is willing to offer a=
=C2=A0 =C2=A0 =C2=A0 route toward OrigAddr (and any other addresses inc= luded in the
=C2=A0 =C2=A0 =C2=A0 given prefix length).=C2=A0 Omitted if= no time limit is imposed.

the necessity of= using ValidityTime has been raised here=C2=A0https://= www.ietf.org/mail-archive/web/manet/current/msg18852.html
=C2= =A0
=C2=A0 =C2=A05.=C2=A0 Include MetricType and= set the type accordingly
=C2=A0 =C2=A06.=C2=A0 Set OrigMetric :=3D Rout= erClient.Cost for the Router Client entry
=C2=A0 =C2=A0 =C2=A0 =C2=A0whi= ch includes OrigAddr
=C2=A0
What if the me= tric type of the RouterClient.Cost is different from the metric type to be = used in the route discovery? In fact, this is quite possible because they p= robably use different types of medium.=C2=A0

=C2=A0However, the regenerated RREQ can
=C2=A0 =C2=A0be unic= ast to the next hop address of the LocalRoute toward TargAddr,
=C2=A0 = =C2=A0if known.

This can be a problem= if the TargAddr is known to the routing set, but the link is actually brok= en. Because there is no related RERR messages to notify that, the following= route discovery retries might fail also. A more careful design is required= if unicast RREQ is to be used.=C2=A0

7.2.=C2= =A0 Route Reply (RREP) Message

I don't q= uite understand the purpose of multicast RREP. There are, however, lots of = disadvantages of using an optional AckReq field.=C2=A0
This has b= een discussed in another thread=C2=A0https://www.ietf.= org/mail-archive/web/manet/current/msg18864.html
=C2=A0
=
=C2=A0 =C2=A0Before creating an RREP, the router SHOULD ch= eck if the corresponding
=C2=A0 =C2=A0RREQ is redundant, i.e., a Route R= eply has already been generated in
=C2=A0 =C2=A0response to the RREQ, or= if the limit for the rate of AODVv2 control
=C2=A0 =C2=A0message genera= tion has been reached.=C2=A0 If so, the RREP SHOULD NOT be
=C2=A0 =C2=A0= created.

What about if the RREQ carries a b= etter route?

= Then it=E2=80=99s not redundant? Or do you mean the SHOULD NOT be created p= art? The idea of=C2=A0these priorities is that already established routes s= hould be protected before new routes are created, so even if the new RREQ i= s better, updating this route would strain the network even more, preventin= g routes from working, which in turn triggers more RREQs.. etc etc. So I=E2= =80=99d say it=E2=80=99s a pity but we have no other option but to drop the= better RREQ?=C2=A0

hmmm... what I understand is that, the intermediate routers will process t= he RREQ carrying better route, but then the corresponding RREP won't be= generated?=C2=A0
=C2=A0

best
=
Jiazi


(I=E2=80=99ve als= o substituted =E2=80=9Ethe limit for the rate of AODVv2 control message gen= eration=E2=80=9C for =E2=80=9E CONTROL_TRAFFIC_LIMIT=E2=80=9C in the Draft = now since that seemed more concise ;) )


= 7.3.2=C2=A0RREP_Ack Reception

it seems that some a= ction is missing after the step 2 Neighbour set update. At least, we need t= o update the Local Route Set?

7.4.1 RERR gener= ation

Is it necessary to generate RERR for RREP fa= ilure?

=C2=A0
If there i= s no route to PktSource, the RERR SHOULD be
=C2=A0 =C2=A0multicast to LL= -MANET-Routers.=C2=A0 If the RERR is sent in response to a
=C2=A0 =C2=A0= broken link, i.e., PktSource is not included, the RERR is, by
=C2=A0 =C2= =A0default, multicast to LL-MANET-Routers.

= Although I know the purpose of using RERR message is to inform as many rout= ers as possible about the route breakage information, it seems to be huge o= verhead, and more importantly, an appealing attack vector for hackers.=C2= =A0

7.4.3 RERR regeneration

=C2=A0 =C2=A02.=C2=A0 For each LocalRoute that needs to= be reported as identified in
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 7.4.1:<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0Insert LocalRoute.Address into the Ad= dressList.

The AddressList can change= d on every RERR regeneration. On the other hand, in section 6.9 (suppressin= g redundant RERR), the uniqueness of RERR is determined by AddressList and = PktSource (optional). It seems to me that the suppressing won't be able= to work correctly?

One more note:

<= /div>
Jitter is not mentioned in the draft, which is important because = the multicast messages used.=C2=A0 I can see RFC5148 in the reference secti= on, but didn't find where it is used.=C2=A0

be= st

Jiazi

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

Best regards,
Lotte



--001a113f1fe4be995a053270c6be-- From nobody Mon May 9 16:24:25 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF6412D536 for ; Mon, 9 May 2016 16:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxdISLub4L0k for ; Mon, 9 May 2016 16:24:12 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8665F12D510 for ; Mon, 9 May 2016 16:24:10 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id y84so217782223lfc.0 for ; Mon, 09 May 2016 16:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=X5I5cwHhXo0RPifsVyzbYgB9uxTjLkC0fExcgKFJ9MM=; b=oUVpYCtSNZcy0Ogg7gV+unEblnt3j/U5I9j7ph4vwHPaRjh3s4fHdmhOabTuk+vulE eZWYeTtBCsyD3YhxIIFNyYprw9NrB7TasERFhmVgXCCzEOPYQQKelYElHrll7ER5qP2W EfgLnFdky4/fX26MyKI2u8IvLR3w5r9O6E4OPGsW2wfXDs0FV80UBLbvENUFpLU8qkIK iCM5P4rtPyZGpRlg6QnKk0El3GrynzyS+nn5ZAqXYz2MyF9GWCx5lFnZKGDfWHS/TiPC /ZC6EA28xB3lYYXpat9Dph36LJ0cYftqlA8YgBwEVHDfzt5SKVd1e0AAeDWPmF8sBO5u vGBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=X5I5cwHhXo0RPifsVyzbYgB9uxTjLkC0fExcgKFJ9MM=; b=nBwKbsMFe+4P67N4pBJrskfunb6wJT/pjL5x5y9aNROqNPvvD1VqSR+Q+002czCHO+ JBTMH9vaQjglQ/mKKafyxh7Up2cNsXFMaOoI889jIIJciFGWeEfVsVXtDIpGntciR21D 6Z9/BDoJTAVPm65zG2KBr0/CbPZcnHokjaJMlrOnLPDQXkCagcn/Fu6bFUMLOcA4POkT s4nnS+dzEu7zfk1peKz8/oeSHDa7zSTF/YehBQS7U8xnbSR8nlGyUdJUFvFBMn5gvirF mPIP6N4wGrBnVBZj7oUHcOyt+LxeXDYUErCZc1VHHPLP1HQ8ob6V/nyVCn9itBqfzZ5I 2TGQ== X-Gm-Message-State: AOPr4FXb8tArHbeb8IcklBDbXKfKnpVc2kRhjaCr1VtTZVBKVW436UAH244PpCK1RWm4lGftSlKO9a+FfH+hWw== MIME-Version: 1.0 X-Received: by 10.25.161.193 with SMTP id k184mr3298705lfe.136.1462836248627; Mon, 09 May 2016 16:24:08 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.114.77.4 with HTTP; Mon, 9 May 2016 16:24:08 -0700 (PDT) In-Reply-To: <0e7fb67e-2711-9912-7e97-e2a54d0bf8ed@earthlink.net> References: <0e7fb67e-2711-9912-7e97-e2a54d0bf8ed@earthlink.net> Date: Tue, 10 May 2016 01:24:08 +0200 X-Google-Sender-Auth: hKHB2QzvtSObtj_KQ1gzWZf5Vtw Message-ID: From: Jiazi YI To: Charlie Perkins Content-Type: multipart/alternative; boundary=001a11411564f6d6130532711a84 Archived-At: Cc: manet Subject: Re: [manet] draft-ietf-manet-aodvv2-15 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:24:23 -0000 --001a11411564f6d6130532711a84 Content-Type: text/plain; charset=UTF-8 Hi Charlie: On Tue, May 3, 2016 at 7:16 AM, Charlie Perkins < charles.perkins@earthlink.net> wrote: > Hello Jiazi, > > A bit of follow-up below... > > On 4/28/2016 7:53 AM, Jiazi YI wrote: > > Hi, > > Here is my preliminary review on aodvv2-15. There are still some points > that I'm not sure that I have fully understood -- I will get back to them > if I had time. > > A summary of my review: > > 1. The specification lacks of a "big picture" of the protocol functioning. > People prefer to have a general idea of the whole protocol at the very > beginning. This is particularly important for readers who are not familiar > with reactive protocol in general. > Some of the sections can be reorganized a bit to improve the readability. > For example, with the current structure, the readers need to reach section > 6.6 (Route discovery) before they can really touch the core function of the > protocol. > > > As with many documents, there is a need to establish definitions and data > structures before specifying the details of the control protocol > interactions. > I see in -16 we have already two paragraphs doing the work, which seem to be fine for me. > > > > 2. As an experimental protocol, the part related to experiments needs to > be improved. IMO, at least the following information must be provided: > - The motivation of this experimental document > - The experiments to be conducted > - What kind of feedback is expected to reported. > > > We will provide some indication for useful experiments. > thx. > > > > > 3. There are some redundant processing procedures in the draft. On the > other hand, some connections between the sections seem to be missing. > Sometimes it's hard to build connection between the message processing and > related information bases. > > > If you could be more specific, that would help. I know that there has > been a lot of effort to provide exactly this kind of continuity, so I don't > know what is missing. > They are elaborated in the detailed inline comments . > > > > 4. The specification uses lots of multicast messages. While multicast RREQ > is inevitable, the necessity of multicast RREP/RERR is not clear. It bring > issues related to control message overhead and security. > > > Multicast RERR is useful when many precursors need to receive the message > ASAP. The justification for multicast RREP is more detailed, but I think > on this point there is definitely room for discussion. Even for multicast > RERR, serial unicast is preferable whenever the number of precursors is > small. > > > > 5. The interaction with RIB: The route state maintenance requires "*LocalRoute.State > MUST be checked before IP packet forwarding and before any operation based > on LocalRoute.State.*". Having such check for each data packet might be > heavy load for the system if the routing daemon runs in userspace (because > of context switch). While interaction with RIB is inevitable, we want to > reduce it as much as possible -- per data packet operation is too much. > > > This is an implementation detail. Systems can be built with RIB and FIB > co-located, which would be my preference. > > > 6. There are too many "MAY" and "SHOULD" in the document without > elaboration. Some of which might cause interoperability issues or even > loops. > > > Do you suggest an elaboration after every single RFC 2119 term? > No. But I called some of them out in the detailed comments below for those need to be clarified, > > > > Please check the details inline: > > *section 1, overview* > > The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol >> enables dynamic,* self-starting*, multihop routing > > > The term "self-starting" is very vague. It makes people think of > auto-configuration. And I didn't see such kind of feature is supported. I > would avoid using it. > > > The protocol is indeed self-starting, and previous commenters never > suggested confusion with auto-configuration. I can't think of another term > that denotes that the routing table is built dynamically without > necessarily requiring any preconfigured route table entries. Can you > suggest a better term? > I couldn't come up with a better term, because I don't get what do you mean exactly here. For me, "self-starting" is that if I throw a non-configured routers in the network, it should be able to run properly (getting addresses, setting up router parameters, etc.). Apparently, this is not a part of AODVv2. > > > AODVv2 is an Experimental protocol. >> ... > > > I think much more information is required here: > > 1) Because RFC 3561 has already been experimented for 13 years, as its > version 2, AODVv2 should summarize what kind of experiences have been > obtained in the past 13 years, and justify the design choices made in the > current draft (like use of RFC5444, removing some of the features, etc) > > > I never heard of a rule like this - that if a protocol is going to > Experimental, we need to describe the experiments that have already been > done. > It's not a "rule", but very useful information for the readers who are interested in the protocol. If I have been running RFC3561 for years, and now am thinking about moving the new version, I would like to know why it's necessary. > > However, the use of RFC 5444 was not justified by any experiment, but > instead mandated by RFC 5498. I am surprised that you request justification > for removing the features, since you were among the people who requested > removing them. This was done to satisfy that request. > Yes, I suggested removing the features and I know the reasons -- but not all the readers know that :) > > 2) The motivation and experiments to be conducted need to be elaborated. > It's even necessary to have a separate section/subsection for it. Some > experiment points that come to my mind without much thinking: support of > multiple interfaces, support of gateways, use of different metrics, the > security model, etc.. > > > These are reasonable experiments and should be mentioned in a section for > that purpose. > > thx > > The basic operations of the AODVv2 protocol are route discovery and >> route maintenance... > > > It's necessary to give an overview of the basic functioning of the > protocol, rather than simply saying "use RREQ/RREP to carry information and > build routes". Because after this, the draft jumps directly into the > protocol details. > It's extremely important for the readers who are not familiar with > reactive protocol. > > > Which aspects of reactive protocol operation do you think should be > mentioned? Perhaps the longer the description gets, the less likely it is > that people will read and digest it. > > > *section 2, Terminology* > > Please pay attention to the style of the terms. Most of the time, style > like AckReq is used, but sometimes RERR_Gen is used. > Good to be consistent. > > Unreachable Address >> An address reported in a Route Error message, as described in >> Section 7.4.1. > > > need to explain what's the address for exactly, rather than giving a > pointer to a big section. > > > It seems difficult to imagine that someone would see the term "Unreachable > Address" and be unable to determine that the address would be used in the > Route Error message to notify other AODVv2 nodes that the address is > unreachable. That is exactly what the address is used for, and seems > intuitive to me. Do you have any suggestion about how to remedy the lack? > > > > *section 3, applicability statement* > > AODVv2 handles a wide variety of mobility and traffic patterns by >> determining routes on-demand... > > > It necessary to explicitly call out what kind of traffic patterns that > reactive protocols are not suitable for, such as lots of routers send data > packets to instantaneous and multiple destinations. If that happens, what's > the consequence (broadcasting storm, etc). > > > We can mention that AODVv2 supports traffic patterns for there are a lot > of source/destination pairs that do not need routes to each other. Sending > data to multiple destinations at the same time sounds like multicast, which > is out of scope. I don't know about instantaneous destinations...? > > An obvious case that reactive protocols won't work well is that we have large among and instantaneous source/destination pairs. > The routing algorithm in AODVv2 MAY be operated at layers other than >> the network layer, using layer-appropriate addresses. > > > Considering the deep coupling between AODVv2 and IP, I don't see how it > can work. This should be removed. > > > Well, it's been done at layer 2. It was used for 802.11s. It's been done > for Bluetooth. Of course in those situations you wouldn't use the IP > address, but that's a pretty simple translation to make. > Yes, but it's more the "idea of AODV" used in those L2 technologies. For this AODVv2 specification (message formats, information bases, message processing etc.), it can only be used with IP. > > > > > 4.2 router client set > >> RouterClient.Cost >> The cost associated with reaching this address or address range. > > > Both "metric" and "cost" are used in the draft. If they are the same, > please pick a term and use it consistently. > > > They are not the same. Some people have been using metrics that measure > benefit, not cost. I don't like those metrics, myself. Both terms are > needed. > OK. When I'm reading the document, I couldn't really tell the difference. For example: A metric value is included within the messages to record the cost of the route. If they are different, it could be helpful to explain clearly in the terminology section. > > > >> The AODVv2 router adding the Router Client MUST wait for >> any existing routing information about this Router Client to be >> purged from the network, i.e., at least MAX_SEQNUM_LIFETIME since the >> last SeqNum update on the router which is removing this Router >> Client. > > > I'm not sure that I parsed this sentence correctly, but the > adding/removing of router client seems to be more an external operation and > out of the control of routing protocol itself. > > > It's just the routing information about the client in other places of the > network, not anything related to an external operation. Is there something > specific that is confusing here? > > > 4.3 neighbor set > >> >> Neighbor.State ... There are three possible states: Confirmed, Unknown, >> and >> Blacklisted. Unknown is the initial state. > > > I think the "Unknown" is a bit confusing here. It's actually something we > already know -- a state that "we heard from that node, but > bi-directionality is not confirmed". > I think "Heard" is a more appropriate term to be used here. > > > That's O.K. with me - perhaps other people have some feedback here...? > > > > 4.4 sequence numbers > > I think the comparison in wrap-around cases should be specified here. > > > Doesn't it work just to describe how subtraction works? If the > wrap-around cases are not exceptions, do they really need to be specified? > To me that sounds like a long and uninformative rathole. > I think it's necessary, and not that complicated. For example, RFC7181 simply says: The sequence number S1 is said to be "greater than" the sequence number S2 if: o S1 > S2 AND S1 - S2 < MAXVALUE/2, OR o S2 > S1 AND S2 - S1 > MAXVALUE/2 When sequence numbers S1 and S2 differ by MAXVALUE/2, their ordering cannot be determined. In this case, which should not occur, either ordering may be assumed. > > > > > 4.5 Local route set > >> >> Alternatively, implementations >> MAY choose to modify the Routing Information Base directly. > > > This should be either more precise (in which condition, how we can modify > the RIB?), or be removed. > > > I think this is an attempt to point out that there are a lot of > implementation strategies. > > > > > >> Multiple valid routes for the same address and prefix length but for >> different metric types may exist in the Local Route Set, but the >> decision of which of these routes to install in the Routing >> Information Base to use for forwarding is outside the scope of >> AODVv2. > > > It's OK, but maybe some rules must be specified and followed. For example, > the metric used must be the same: if a packet is forwarded using metric A > at router X, and then metric B at router Y, it's a obvious source of loops. > > > I don't think this is possible for monotonically increasing metrics. > sorry, I meant metric type here. best Jiazi --001a11411564f6d6130532711a84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Charlie:


On Tue, May 3, 2016 at 7:16 AM, Charlie Perkins <charles.perkins@earthlink.net> wrote:
=20 =20 =20

Hello Jiazi,

A bit of follow-up below...


On 4/28/2016 7:53 AM, Jiazi YI wrote:
=20
Hi,=C2=A0

Here is my preliminary review on aodvv2-15. There are still some points that I'm not sure that I have fully understood -- I will get back to them if I had time.=C2=A0

A summary of my review:

1. The specification lacks of a "big picture" of the protocol functioning. People prefer to have a general idea of the whole protocol at the very beginning. This is particularly important for readers who are not familiar with reactive protocol in general.=C2=A0
Some of the sections can be reorganized a bit to improve the readability. For example, with the current structure, the readers need to reach section 6.6 (Route discovery) before they can really touch the core function of the protocol.

 As with many documents, there is a need to establish definitions and data structures before specifying the details of the control protocol interactions.

I see in -= 16 we have already two paragraphs doing the work, which seem to be fine for= me.=C2=A0
=C2=A0



2. As an experimental protocol, the part related to experiments needs to be improved. IMO, at least the following information must be provided:
=C2=A0 =C2=A0 =C2=A0 =C2=A0- The motivation of this experiment= al document=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0- The experiments to be conducted= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0- What kind of feedback is expected= to reported.

 We will provide some indication for useful experiments.

thx.=C2=A0
=C2=A0
=




3. There are some redundant processing procedures in the draft. On the other hand, some connections between the sections seem to be missing. Sometimes it's hard to build connection between the message processing and related information bases.=C2=A0

 If you could be more specific, that would help.=C2=A0 I know that there has been a lot of effort to provide exactly this kind of continuity, so I don't know what is missing.

<= div>They are elaborated in the detailed inline comments .=C2=A0
= =C2=A0



4. The specification uses lots of multicast messages. While multicast RREQ is inevitable, the necessity of multicast RREP/RERR is not clear. It bring issues related to control message overhead and security.

Multicast RERR is useful when many precursors need to receive the message ASAP.=C2=A0 The justification for multicast RREP is more detailed, but I think on this point there is definitely room for discussion.=C2=A0 Even for multicast RERR, serial unicast is preferable whenever the number of precursors is small.

=C2=A0

5. The interaction with RIB: The=C2=A0route state maintenance=C2=A0requires "LocalRoute.State MUST be check= ed before IP packet forwarding and before any operation based on LocalRoute.State.". Having such check for each data packet might be heavy load for the system if the routing daemon runs in userspace (because of context switch). While interaction with RIB is inevitable, we want to reduce it as much as possible -- per data packet operation is too much.

 This is an implementation detail.=C2=A0 Systems can be built with RIB a= nd FIB co-located, which would be my preference.


6. There are too many "MAY" and "SHOULD" i= n the document without elaboration. Some of which might cause interoperability issues or even loops.

 Do you suggest an elaboration after every single RFC 2119 term?

No. But I called some of them out in the det= ailed comments below for those need to be clarified,=C2=A0
=C2=A0=


=C2=A0
Please check the details inline:

section 1, overview

=C2=A0 =C2=A0The Ad hoc On-Dema= nd Distance Vector Version 2 (AODVv2) protocol
=C2=A0 =C2=A0enables dynamic, self-starting, multihop ro= uting

The term "self-starting" is very vague. It makes p= eople think of auto-configuration. And I didn't see such kind of feature is supported. I would avoid using it.

 The protocol is indeed self-starting, and previous commenters never suggested confusion with auto-configuration.=C2=A0 I can't think of another term that denotes that the routing table is built dynamically without necessarily requiring any preconfigured route table entries.=C2=A0 Can you suggest a better term?
<= div>
I couldn't come up with a better term, because I don= 't get what do you mean exactly here. For me, "self-starting"= is that if I throw a non-configured routers in the network, it should be a= ble to run properly (getting addresses, setting up router parameters, etc.)= . Apparently, this is not a part of AODVv2.=C2=A0
=C2=A0

=C2=A0 AODVv2 is an Experimental protocol.
=C2=A0...
=C2=A0
I think much more information is required here:

1) Because RFC 3561 has already been experimented for 13 years, as its version 2, AODVv2 should summarize what kind of experiences have been obtained in the past 13 years, and justify the design choices made in the current draft (like use of RFC5444, removing some of the features, etc)

 I never heard of a rule like this - that if a protocol is going to Experimental, we need to describe the experiments that have already been done.

It's not a &qu= ot;rule", but very useful information for the readers who are interest= ed in the protocol. If I have been running RFC3561 for years, and now am th= inking about moving the new version, I would like to know why it's nece= ssary.=C2=A0
=C2=A0

However, the use of RFC 5444 was not justified by any experiment, but instead mandated by RFC 5498. I am surprised that you request justification for removing the features, since you were among the people who requested removing them.=C2=A0 This was done to satisfy that request.

Yes, I suggested removin= g the features and I know the reasons -- but not all the readers know that = :)
=C2=A0

2) The motivation and experiments to be conducted need to be elaborated. It's even necessary to have a separate section/subsection for it. Some experiment points that come to my mind without much thinking: support of multiple interfaces, support of gateways, use of different metrics, the security model, etc..

 These are reasonable experiments and should be mentioned in a section for that purpose.


thx=C2=A0

=C2=A0 =C2=A0The basic operatio= ns of the AODVv2 protocol are route discovery and
=C2=A0 =C2=A0route maintenance...

It's necessary to give an overview of the basic functionin= g of the protocol, rather than simply saying "use RREQ/RREP to carry information and build routes". Because after this, the draft jumps directly into the protocol details.=C2=A0
It's extremely important for the readers who are not familiar with reactive protocol.

 Which aspects of reactive protocol operation do you think should be mentioned?=C2=A0 Perhaps the longer the description gets, the less like= ly it is that people will read and digest it.


section 2, Terminology

Please pay attention to the style of the terms. Most of the time, style like AckReq is used, but sometimes RERR_Gen is used.=C2=A0
Good to be consistent.=C2=A0

=C2=A0 =C2=A0Unreachable Addres= s
=C2=A0 =C2=A0 =C2=A0 An address reported in a Route Error messa= ge, as described in
=C2=A0 =C2=A0 =C2=A0 Section 7.4.1.

need to explain what's the address for exactly, rather tha= n giving a pointer to a big section.

 It seems difficult to imagine that someone would see the term "Unreachable Address" and be unable to determine that the add= ress would be used in the Route Error message to notify other AODVv2 nodes that the address is unreachable.=C2=A0 That is exactly what the address is used for, and seems intuitive to me.=C2=A0 Do you have any suggestion about how to remedy the lack?

=C2=A0

section 3, applicability statement

=C2=A0 =C2=A0AODVv2 handles a w= ide variety of mobility and traffic patterns by
=C2=A0 =C2=A0determining routes on-demand...

It necessary to explicitly call out what kind of traffic patterns that reactive protocols are not suitable for, such as lots of routers send data packets to instantaneous and multiple destinations. If that happens, what's the consequence (broadcasting storm, etc).

 We can mention that AODVv2 supports traffic patterns for there are a lot of source/destination pairs that do not need routes to each other.=C2=A0 Sending data to multiple destinations at the same time sounds like multicast, which is out of scope.=C2=A0 I don't know ab= out instantaneous destinations...?

=
An obvious case that reactive p= rotocols won't work well is that we have large among and instantaneous = source/destination pairs. =C2=A0
=C2=A0 =C2=A0The routing algorith= m in AODVv2 MAY be operated at layers other than
=C2=A0 =C2=A0the network layer, using layer-appropriate addresses= .

Considering the deep coupling between AODVv2 and IP, I don't see how it can work. This should be removed.

 Well, it's been done at layer 2.=C2=A0 It was used for 802.11s.=C2= =A0 It's been done for Bluetooth.=C2=A0 Of course in those situations you wouldn= 't use the IP address, but that's a pretty simple translation to make.=

Yes, but it's more the "ide= a of AODV" used in those L2 technologies. For this AODVv2 specificatio= n (message formats, information bases, message processing etc.), it can onl= y be used with IP.
=C2=A0




4.2 router client set
=C2=A0 =C2=A0RouterClient.Cost =C2=A0 =C2=A0 =C2=A0 The cost associated with reaching this addre= ss or address range.

Both "metric" and "cost" are used in the d= raft. If they are the same, please pick a term and use it consistently.

 They are not the same.=C2=A0 Some people have been using metrics that measure benefit, not cost.=C2=A0 I don't like those metrics, myself= .=C2=A0 Both terms are needed.

OK. When I= 'm reading the document, I couldn't really tell the difference. For= example:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A metric valu= e is included within the messages =C2=A0to record the cost of the route.

If they are different, it could be helpful to = explain clearly in the terminology section.=C2=A0

= =C2=A0

=C2=A0
The AODVv2 router adding the Router Client MUST wait for
=C2=A0 =C2=A0any existing routing information about this Router C= lient to be
=C2=A0 =C2=A0purged from the network, i.e., at least MAX_SEQNUM_L= IFETIME since the
=C2=A0 =C2=A0last SeqNum update on the router which is removing t= his Router
=C2=A0 =C2=A0Client.=C2=A0

I'm not sure that I parsed this sentence correctly, but th= e adding/removing of router client seems to be more an external operation and out of the control of routing protocol itself.

It's just the routing information about the client in other places of the network, not anything related to an external operation.=C2=A0 Is there something specific that is confusing here?


4.3 neighbor set

=C2=A0Neighbor.State ... There are three possible states: Confirmed, Unknown, and
=C2=A0 =C2=A0 =C2=A0 Blacklisted.=C2=A0 Unknown is the initial st= ate.

I think the "Unknown" is a bit confusing here. It= 9;s actually something we already know -- a state that "we heard from that node, but bi-directionality is not confirmed".=C2= =A0
I think "Heard" is a more appropriate term to be use= d here.

 That's O.K. with me - perhaps other people have some feedback here...?

=C2=A0

4.4 sequence numbers

I think the comparison in wrap-around cases should be specified here.

 Doesn't it work just to describe how subtraction works?=C2=A0 If th= e wrap-around cases are not exceptions, do they really need to be specified?=C2=A0 To me that sounds like a long and uninformative rathol= e.

I think it's necessary, and no= t that complicated. For example, RFC7181 simply says:

<= div>
=C2=A0 =C2=A0The sequence number S1 is said to be "greater th= an" the sequence
=C2=A0 =C2=A0number S2 if:

=C2=A0 =C2=A0o =C2=A0S1 > S2 AND S1 - S2 < MAXVALUE/2, OR

=C2=A0 =C2=A0o =C2=A0S2 > S1 AND S2 - S1 > MAX= VALUE/2

=C2=A0 =C2=A0When sequence numbers S1 and = S2 differ by MAXVALUE/2, their ordering
=C2=A0 =C2=A0cannot be de= termined.=C2=A0 In this case, which should not occur, either
=C2= =A0 =C2=A0ordering may be assumed.
=C2=A0


=C2=A0

4.5 Local route set

Alternatively, implementations
=C2=A0 =C2=A0MAY choose to modify the Routing Information Base di= rectly.

This should be either more precise (in which condition, how we can modify the RIB?), or be removed.

 I think this is an attempt to point out that there are a lot of implementation strategies.

=C2=A0

=C2=A0
=C2=A0 =C2=A0Multiple valid route= s for the same address and prefix length but for
=C2=A0 =C2=A0different metric types may exist in the Local Route = Set, but the
=C2=A0 =C2=A0decision of which of these routes to install in the = Routing
=C2=A0 =C2=A0Information Base to use for forwarding is outside th= e scope of
=C2=A0 =C2=A0AODVv2.

It's OK, but maybe some rules must be specified and followed. For example, the metric used must be the same: if a packet is forwarded using metric A at router X, and then metric B at router Y, it's a obvious source of loops.

 I don't think this is possible for monotonically increasing metrics= .

sorry, I meant metric type here.=C2= =A0


=C2=A0<snip>

best

Jiazi
<= /div> --001a11411564f6d6130532711a84-- From nobody Mon May 9 16:34:49 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAD912B05D for ; Mon, 9 May 2016 16:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPjph-u5m7EW for ; Mon, 9 May 2016 16:34:46 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F052112D17F for ; Mon, 9 May 2016 16:28:34 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id u64so217754816lff.3 for ; Mon, 09 May 2016 16:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=mTKtkja5RI0HfVmRAxJX4fxKtNpV3FFJsDqScDmk71s=; b=c57aClnE4nVPjRtaAoe9Ct5o/uBK+txMRapNRdQ+61HStqXbzocdrT+Dx5GWDxZEp9 7G8Zv+mG3oQNMrXi4gsgJv5a96u8mA3oYr7cM/EcKQPb0/OJ7PAGySUUSaqTEtEqIvqz 7Rh781ATJIj7zv/HWra+POwCT9+f7gNdmQLCT/GnwjW70U26YDvQVe8ADkyaWOV5iQYi eXusfLwEFp93d9ZsOoyYaDv7NRVkCizfIMrtOMHjAylb6mQkMLhDg87Kc1wtcN0B5OWJ s9PKvbSl3QDUnN2VUkCTZ1sntq0RWeHoGpeUySFXztmJ5ztgToyJxFcDOEMzSAQ1eJKy Phmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mTKtkja5RI0HfVmRAxJX4fxKtNpV3FFJsDqScDmk71s=; b=lstZLlHIRTZOPDDOIdAx9U9+Lz/CE5DkTL7OA8Sfyjk5fv64N9N0LVvLJrDBcl4I1Y H832AotNLVLN9xCrsXZKX+0ivU3sooSTzutcCeFrJdOATNru92tu4b6BJrPRx8qLnEDu OwaCeWPpDqSjH3kVLNKXzhT4wek0ajWslOA5M8DtpifKEJvXMIOn2m/8AsaCCL84NnFZ jmDwwj47DCKf/rAdQ5+fpnq/amCVSGiizuJHoiosUVXSm59E0ekUa/vKggN0uXKv8+W/ 4UQor6RswVEKB/kfFf+23IRpPgR+W+deyuWQ4cmxkKDbqGHRX9cpXMFnry3AMmyRmiYM xHWA== X-Gm-Message-State: AOPr4FWmYcVpY9RwS0Fbmf3CFrekvVZaagzkQmS7d6CWm2mPlp3k7NtuI8zNQs/hbYVUKeBIucN+blEey8yRNg== MIME-Version: 1.0 X-Received: by 10.25.161.193 with SMTP id k184mr3303551lfe.136.1462836513222; Mon, 09 May 2016 16:28:33 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.114.77.4 with HTTP; Mon, 9 May 2016 16:28:33 -0700 (PDT) In-Reply-To: References: <33F4027C-8E60-46CD-BBD7-DACD70A54D21@fu-berlin.de> Date: Tue, 10 May 2016 01:28:33 +0200 X-Google-Sender-Auth: j_IRBPfWZoBOJ78Y5L5xZvuNpjk Message-ID: From: Jiazi YI To: Victoria Mercieca Content-Type: multipart/alternative; boundary=001a11411564bc3c150532712aec Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] draft-ietf-manet-aodvv2-15 review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:34:47 -0000 --001a11411564bc3c150532712aec Content-Type: text/plain; charset=UTF-8 > > > >> One more note: >> >> Jitter is not mentioned in the draft, which is important because the >> multicast messages used. I can see RFC5148 in the reference section, but >> didn't find where it is used. >> >> VM> We could say "The use of jitter in an implementation is RECOMMENDED > by RFC5148" in the Message Transmission section? > We need more details than that, such as in which message jitter is required, and when it should be applied. Preferably with some suggested default values. In fact, the jitter in reactive protocol should be considered even further -- we discussed the issue in the draft https://tools.ietf.org/html/draft-yi-manet-reactive-jitter-04 best Jiazi > > > Kind regards, and thanks once again for your review, > Victoria. > >> --001a11411564bc3c150532712aec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=

=C2=A0
One more note:

Jitter = is not mentioned in the draft, which is important because the multicast mes= sages used.=C2=A0 I can see RFC5148 in the reference section, but didn'= t find where it is used.=C2=A0

VM> We could say "The use of jitter in an implementation is RECOM= MENDED by RFC5148" in the Message Transmission section?

We need more details than = that, such as in which message jitter is required, and when it should be ap= plied. Preferably with some suggested default values. In fact, the jitter i= n reactive protocol should be considered even further -- we discussed the i= ssue in the draft=C2=A0https://tools.ietf.org/html/draft-yi-manet-reactive-j= itter-04

best

Jiazi
=C2=A0


Kind r= egards, and thanks once again for your review,
Victoria.

--001a11411564bc3c150532712aec-- From nobody Thu May 12 07:27:41 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7773812B060 for ; Thu, 12 May 2016 07:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlnzpaj6j0BU for ; Thu, 12 May 2016 07:27:36 -0700 (PDT) Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEA912D0BA for ; Thu, 12 May 2016 07:27:36 -0700 (PDT) Received: from turig.iit.cnr.it (turig.iit.cnr.it [146.48.98.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxbk.iit.cnr.it (Postfix) with ESMTPSA id 07AF9C02A7 for ; Thu, 12 May 2016 16:27:33 +0200 (CEST) Date: Thu, 12 May 2016 16:32:01 +0200 From: Mattia Campana To: manet@ietf.org Message-ID: <573493e1.0wkrG7U5XNPQcODR%mattia.campana@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [manet] [IFIP IoP-W 2016]: call for participation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: iopw2016-publicity@iit.cnr.it List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 14:27:39 -0000 [Apologies for possible duplicates] ****************************** FINAL PROGRAM DEFINED ****************************** - 1 Keynote talk "Power to the (local) People", Prof. Jorg Ott (TUM, Germany) - 7 full papers - final plenary open discussion on IoP topics and perspective ************************************************************************************* The Organising Committee of the First IFIP Internet of People Workshop (IFIP IoP-W 2016) is happy to announce the workshop program below, which will be held in Vienna, on May 20, co-located with IFIP Networking 2016. Full details about registration and logistics can be found on the workshop website http://cnd.iit.cnr.it/iopw2016/ as well as on the IFIP Networking 2016 website https://networking2016.univie.ac.at/ Hope to see you in Vienna! Best regards, Isabelle Chrisment Andrea Passarella Ana Pont Sanjuan IFIP IoP-W 2016 Co-Chairs -------------------------------------------------------------------------------- IFIP IoP-W 2016 - First IFIP Internet of People Workshop co-located with IFIP Networking 2016 20 May 2016, Vienna, Austria http://cnd.iit.cnr.it/iopw2016/ ********* WORKSHOP PROGRAM ********* -------------------------------------------------------------------------------- 9:00 - 9:15 Welcome Address 9:15 - 10:15 Keynote Talk ------------------------------------------------------------------------ Title: Power to the (local) People Speaker: Prof. Jorg Ott, Technische Universitat Munchen, Germany ------------------------------------------------------------------------ 10:15 - 10:45 Coffee Break 10:45 - 12:30 Session 1: Social Aspects of IoP ------------------------------------------------------------------------ Christian Quadri, Matteo Zignani, Sabrina Gaito and Gian Paolo Rossi Clique-Aware Mobile Social Clouds Leonardo Maccari On the technical and Social Structure of Community Networks Pablo Nicolas Terevinto Charquero, Ana Pont Sanjuan, Jose Antonio Gil Salinas and Josep Domenech I de Soria A flexible workload model based on roles of interactive users in social networks Narges Yousefnezhad, Marcin Nagy and N. Asokan On Improving Tie Strength Estimates by Aggregating Multiple Communication Channels ------------------------------------------------------------------------ 12:30 - 14:00 Lunch Break 14:00 - 15:15 Session 2: Analysis towards supporting IoP system design ------------------------------------------------------------------------ Michael Seufert, Tobias Hossfeld, Anika Schwind, Valentin Burger and Phuoc Tran-Gia Group-based Communication in WhatsApp Margeret Hall and Simon Caton Online Social Engagement at Higher Education Institutes: A German Case Study Quang Vinh Dang and Claudia-Lavinia Ignat Performance of real-time collaborative editors at large scale: user perspective ------------------------------------------------------------------------ 15:15 - 16:00 Open discussion and closing From nobody Thu May 12 07:57:07 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00C412B060 for ; Thu, 12 May 2016 07:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4FNeZWzcwOe for ; Thu, 12 May 2016 07:57:03 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A7D12B022 for ; Thu, 12 May 2016 07:57:03 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id s184so100591262vkb.3 for ; Thu, 12 May 2016 07:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=iltjRgGjU3ut/nDPsKbS+jqR65OZo4ZWJXjVgB9wLdY=; b=tiyKPf5t0z0z66alGLbF1tlHT4UHWtUMLsk3ub5fB4MBRVO/uSX11bteOS7tcCl4MD ulOl8E8An4DzdytnhnNMNMxpNLAeAh6eKsxepyMWZnOBPJLBZ+Uw6Rxn+5S74TspriAf pUwICZu3pKfIaPWbC6kMtust0KkUBMHAad6mNVwxh85EnSzZ220R2ZRAsxyZ+7ux033a G/6pbi1VL05aWS39Vlub31P18B0O/KUgfef1N7Zpg9ewJ73PypSkC/Oicsdo5hLDg2/c K99vCl0RRqmn62vBxq+3afRhOIs20hPYHj8DjjxIwta5eAaSnVrOU1FY2IZZYlbcnOAA j2Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=iltjRgGjU3ut/nDPsKbS+jqR65OZo4ZWJXjVgB9wLdY=; b=hmtYGAhzHxvCtx1GS/wMRKsOSJ+ln+BJ8/p5V197lMM2wSWcVjQiseyYKGo+UCARYD Z9yX/z5OJkRN4unL55evLqWX6ZvR+QPqN0dh6fqlRnoe56t/JLxUSIW5BwEHPvxCfRbo ax+b/2Z21fgNtkhxp00P9rgXEu8dZDpiBM9mAbtgaIbB3M39mrggNK0yKgIAIOV7lEag ka0LoqjkUb9Ar9nXFmq3nc0HQ+HVJsQIs8+nO4GfjDU9Q5t/qYbEcn8Abbp7iksJcaDA UHhJNhgbxFEGoQcEkC0UMxrVtW42XArPG/fEAjAp5W0Fxqz90pccZ509OxVriUm9KocX 7prg== X-Gm-Message-State: AOPr4FWHHZWsbodN/JnkUgcboACezz87vr1JgbRhztEJxzCIQpZoKfm7CKc3fygsYxrSXdCvXPcqtLTUZLQtiw== MIME-Version: 1.0 X-Received: by 10.31.12.74 with SMTP id 71mr5127233vkm.56.1463065022637; Thu, 12 May 2016 07:57:02 -0700 (PDT) Received: by 10.176.4.104 with HTTP; Thu, 12 May 2016 07:57:02 -0700 (PDT) Date: Thu, 12 May 2016 10:57:02 -0400 Message-ID: From: Justin Dean To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=001a1145228cf532480532a65e99 Archived-At: Subject: [manet] Updated after meeting Draft Recharter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 14:57:06 -0000 --001a1145228cf532480532a65e99 Content-Type: text/plain; charset=UTF-8 Thanks to everyone who was able to participate in the voice chat today regarding the recharter. Below is an updated draft charter based upon discussions had in the chat. I've also included inline comments with (JWD ...) which of course will be removed when officially adopting the draft. If something is missing or misrepresented please provide feedback on the list so we may adjust it and update it accordingly. The plan is to present the charter to Alvaro for adoption to be completed before the next IETF meeting so get your comments in ASAP. DRAFT CHARTER The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors. Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features. The MANET WG is responsible for the maintenance of RFC5444, NHDP, OLSRv2, and DLEP. Of possible particular interest: type extensions for DLEP, security enhancements for RFC5444/NHDP/OLSRv2, best practices for MANET deployment/management, source specific extensions for OLSRv2, and import/export of routing state for NHDP/OLSRv2. (JWD these are not promised deliverable items and we may want to remove them and just go with maintenance without listing them, also please correct me if I misrepresented the work talked about in the webex meeting head on May 12th) The MANET WG will standardize a multicast MANET protocol framework based on previous work and lessons learned for scoped forwarding within MANET networks. As part of this framework the WG will produce a well defined MANET multicast forwarding information base. The WG will produce an informational draft outlining challenges and best practices for deploying and managing MANET networks. The MANET WG will interact with the PIM working group on issues relating to the multicast work. The WG will also pay attention to other IETF and IRTF work that is addressing topics related to MANET environments. In summary, the WG will develop the following drafts: (JWD MANET Management Document is removed as the requirement for producing the document is no longer valid but the working group may work on this if there is interest) MANET Maintenance - DLEP multiple flow extensions (JWD updated item) (JWD RFC5444 Security Extensions document has been removed as a deliverable but may still be worked upon under the auspices of MANET maintenance.) MANET Multicast - Multicast FIB (Standards) --001a1145228cf532480532a65e99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Thanks to everyone who was able to participate in the voice=
 chat today regarding the recharter.  Below is an updated draft charter bas=
ed upon discussions had in the chat.  I've also included inline comment=
s with (JWD ...) which of course will be removed when officially adopting t=
he draft.  If something is missing or misrepresented please provide feedbac=
k on the list so we may adjust it and update it accordingly.  The plan is t=
o present the charter to Alvaro for adoption to be completed before the nex=
t IETF meeting so get your comments in ASAP.


DRAFT CHARTER

The purpose of the MANET working group is to standardize IP routing protoco=
l functionality suitable for wireless routing application within both stati=
c and dynamic topologies with increased dynamics due to node motion or othe=
r factors. =20

Approaches are intended to be relatively lightweight in nature, suitable fo=
r multiple hardware and wireless environments, and address scenarios where =
MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infra=
structures (e.g., a mixture of fixed and mobile routers) should also be sup=
ported by MANET specifications and management features.

The MANET WG is responsible for the maintenance of RFC5444, NHDP, OLSRv2, a=
nd DLEP. Of possible particular interest:=C2=A0type extensions for DLEP, security enhancements for RFC5444/NHDP/OLSRv2, <=
span style=3D"font-family:arial,sans-serif">best practices for MANET deploy=
ment/management,=C2=A0source specific extensions for OLSRv2, and import/exp=
ort of routing state for NHDP/OLSRv2.  
(JWD these are not promi=
sed deliverable items and we may want to remove them and just go with maint=
enance without listing them, also please correct me if I misrepresented the=
 work talked about in the webex meeting head on May 12th)
The MANET W=
G will standardize a multicast MANET protocol framework based on previous w=
ork and lessons learned for scoped forwarding within MANET networks.  As pa=
rt of this framework the WG will produce a well defined MANET multicast for=
warding information base.

The WG will produce an informational draft outlining challenges and best pr=
actices for deploying and managing MANET networks.=20

The MANET WG will interact with the PIM working group on issues relating to=
 the multicast work.  The WG will also pay attention to other IETF and IRTF=
 work that is addressing topics related to MANET environments.

In summary, the WG will develop the following drafts:

(JWD MANET Management Document is removed as the requirement for producing =
the document is no longer valid but the working group may work on this if t=
here is interest)

MANET Maintenance=C2=A0
 - DLEP multiple flow extensions (JWD updated item)
 (JWD RFC=
5444 Security Extensions document has been removed as a deliverable but may=
 still be worked upon under the auspices of MANET maintenance.)
MANET Multicast
  - Multic=
ast FIB (Standards)
--001a1145228cf532480532a65e99-- From nobody Thu May 12 08:20:13 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DC012D6A3 for ; Thu, 12 May 2016 08:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPVzl3i0eIRs for ; Thu, 12 May 2016 08:20:07 -0700 (PDT) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D8412D133 for ; Thu, 12 May 2016 08:20:06 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,610,1454976000"; d="scan'208,217"; a="35212934" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 12 May 2016 16:20:02 +0100 X-IronPort-AV: E=Sophos;i="5.24,610,1454976000"; d="scan'208,217";a="117889559" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 12 May 2016 16:20:02 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.168]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Thu, 12 May 2016 16:20:02 +0100 From: "Dearlove, Christopher (UK)" To: Justin Dean , "manet@ietf.org" Thread-Topic: [manet] Updated after meeting Draft Recharter Thread-Index: AQHRrF6St9vONTaTXU2u4zgtGGdx1Z+1af3Q Date: Thu, 12 May 2016 15:20:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B57E4GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Updated after meeting Draft Recharter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:20:11 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B57E4GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 QXMgeW91IGtub3cgSSBoYWQgdG8gZHVjayBvdXQgZWFybHksIGFuZCB5b3Ugd2VyZSBnb25lIHdo ZW4gSSBjYW1lIGJhY2suDQoNCkFsc28gbm90IGZvciBhIHNwZWNpZmljIGl0ZW0sIGJ1dCBJIHBy ZXN1bWUgd291bGQgYmUgcGVybWl0dGVkLCBpcyBpZiBhbnlvbmUgZGVjaWRlZCB0byB3b3JrIG9u IGNvbmNlcHRzIHN1Y2ggYXMgaGllcmFyY2hpY2FsIG9yIGh5YnJpZCBkZXZlbG9wbWVudHMgb2Yg T0xTUnYyLiBTb21lb25lIGFjdHVhbGx5IG1lbnRpb25lZCBvbmUgb2YgdGhvc2UgcmVjZW50bHks IGJ1dCBJ4oCZbSBub3QgYXdhcmUgb2YgYW55b25lIGFjdGl2ZWx5IHB1c2hpbmcgb25lLiBCdXQg aW4gY2FzZSB0aGV5IGRpZCwgSSBwcmVzdW1lIHdvdWxkIGJlIGFsbG93ZWQuDQoNCi0tDQpDaHJp c3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpU OiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv bTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFk ZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0 dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTEN ClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJy ZXksIEdVMiA3WVANCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSnVzdGluIERlYW4NClNlbnQ6IDEyIE1heSAyMDE2IDE1OjU3DQpUbzog bWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFttYW5ldF0gVXBkYXRlZCBhZnRlciBtZWV0aW5nIERy YWZ0IFJlY2hhcnRlcg0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0 ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFs IHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91 IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5 Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sg b3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0 LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVu dHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3Vz LCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3Rl bXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIw V2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCioqKiBXQVJOSU5HICoqKg0KRVhURVJO QUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdh bml6YXRpb24uDQoNCg0KVGhhbmtzIHRvIGV2ZXJ5b25lIHdobyB3YXMgYWJsZSB0byBwYXJ0aWNp cGF0ZSBpbiB0aGUgdm9pY2UgY2hhdCB0b2RheSByZWdhcmRpbmcgdGhlIHJlY2hhcnRlci4gIEJl bG93IGlzIGFuIHVwZGF0ZWQgZHJhZnQgY2hhcnRlciBiYXNlZCB1cG9uIGRpc2N1c3Npb25zIGhh ZCBpbiB0aGUgY2hhdC4gIEkndmUgYWxzbyBpbmNsdWRlZCBpbmxpbmUgY29tbWVudHMgd2l0aCAo SldEIC4uLikgd2hpY2ggb2YgY291cnNlIHdpbGwgYmUgcmVtb3ZlZCB3aGVuIG9mZmljaWFsbHkg YWRvcHRpbmcgdGhlIGRyYWZ0LiAgSWYgc29tZXRoaW5nIGlzIG1pc3Npbmcgb3IgbWlzcmVwcmVz ZW50ZWQgcGxlYXNlIHByb3ZpZGUgZmVlZGJhY2sgb24gdGhlIGxpc3Qgc28gd2UgbWF5IGFkanVz dCBpdCBhbmQgdXBkYXRlIGl0IGFjY29yZGluZ2x5LiAgVGhlIHBsYW4gaXMgdG8gcHJlc2VudCB0 aGUgY2hhcnRlciB0byBBbHZhcm8gZm9yIGFkb3B0aW9uIHRvIGJlIGNvbXBsZXRlZCBiZWZvcmUg dGhlIG5leHQgSUVURiBtZWV0aW5nIHNvIGdldCB5b3VyIGNvbW1lbnRzIGluIEFTQVAuDQoNCg0K DQoNCg0KRFJBRlQgQ0hBUlRFUg0KDQoNCg0KVGhlIHB1cnBvc2Ugb2YgdGhlIE1BTkVUIHdvcmtp bmcgZ3JvdXAgaXMgdG8gc3RhbmRhcmRpemUgSVAgcm91dGluZyBwcm90b2NvbCBmdW5jdGlvbmFs aXR5IHN1aXRhYmxlIGZvciB3aXJlbGVzcyByb3V0aW5nIGFwcGxpY2F0aW9uIHdpdGhpbiBib3Ro IHN0YXRpYyBhbmQgZHluYW1pYyB0b3BvbG9naWVzIHdpdGggaW5jcmVhc2VkIGR5bmFtaWNzIGR1 ZSB0byBub2RlIG1vdGlvbiBvciBvdGhlciBmYWN0b3JzLg0KDQoNCg0KQXBwcm9hY2hlcyBhcmUg aW50ZW5kZWQgdG8gYmUgcmVsYXRpdmVseSBsaWdodHdlaWdodCBpbiBuYXR1cmUsIHN1aXRhYmxl IGZvciBtdWx0aXBsZSBoYXJkd2FyZSBhbmQgd2lyZWxlc3MgZW52aXJvbm1lbnRzLCBhbmQgYWRk cmVzcyBzY2VuYXJpb3Mgd2hlcmUgTUFORVRzIGFyZSBkZXBsb3llZCBhdCB0aGUgZWRnZXMgb2Yg YW4gSVAgaW5mcmFzdHJ1Y3R1cmUuIEh5YnJpZCBtZXNoIGluZnJhc3RydWN0dXJlcyAoZS5nLiwg YSBtaXh0dXJlIG9mIGZpeGVkIGFuZCBtb2JpbGUgcm91dGVycykgc2hvdWxkIGFsc28gYmUgc3Vw cG9ydGVkIGJ5IE1BTkVUIHNwZWNpZmljYXRpb25zIGFuZCBtYW5hZ2VtZW50IGZlYXR1cmVzLg0K DQoNCg0KVGhlIE1BTkVUIFdHIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgbWFpbnRlbmFuY2Ugb2Yg UkZDNTQ0NCwgTkhEUCwgT0xTUnYyLCBhbmQgRExFUC4gT2YgcG9zc2libGUgcGFydGljdWxhciBp bnRlcmVzdDogdHlwZSBleHRlbnNpb25zIGZvciBETEVQLCBzZWN1cml0eSBlbmhhbmNlbWVudHMg Zm9yIFJGQzU0NDQvTkhEUC9PTFNSdjIsIGJlc3QgcHJhY3RpY2VzIGZvciBNQU5FVCBkZXBsb3lt ZW50L21hbmFnZW1lbnQsIHNvdXJjZSBzcGVjaWZpYyBleHRlbnNpb25zIGZvciBPTFNSdjIsIGFu ZCBpbXBvcnQvZXhwb3J0IG9mIHJvdXRpbmcgc3RhdGUgZm9yIE5IRFAvT0xTUnYyLg0KDQooSldE IHRoZXNlIGFyZSBub3QgcHJvbWlzZWQgZGVsaXZlcmFibGUgaXRlbXMgYW5kIHdlIG1heSB3YW50 IHRvIHJlbW92ZSB0aGVtIGFuZCBqdXN0IGdvIHdpdGggbWFpbnRlbmFuY2Ugd2l0aG91dCBsaXN0 aW5nIHRoZW0sIGFsc28gcGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBtaXNyZXByZXNlbnRlZCB0aGUg d29yayB0YWxrZWQgYWJvdXQgaW4gdGhlIHdlYmV4IG1lZXRpbmcgaGVhZCBvbiBNYXkgMTJ0aCkN Cg0KVGhlIE1BTkVUIFdHIHdpbGwgc3RhbmRhcmRpemUgYSBtdWx0aWNhc3QgTUFORVQgcHJvdG9j b2wgZnJhbWV3b3JrIGJhc2VkIG9uIHByZXZpb3VzIHdvcmsgYW5kIGxlc3NvbnMgbGVhcm5lZCBm b3Igc2NvcGVkIGZvcndhcmRpbmcgd2l0aGluIE1BTkVUIG5ldHdvcmtzLiAgQXMgcGFydCBvZiB0 aGlzIGZyYW1ld29yayB0aGUgV0cgd2lsbCBwcm9kdWNlIGEgd2VsbCBkZWZpbmVkIE1BTkVUIG11 bHRpY2FzdCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGJhc2UuDQoNCg0KDQpUaGUgV0cgd2lsbCBw cm9kdWNlIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgb3V0bGluaW5nIGNoYWxsZW5nZXMgYW5kIGJl c3QgcHJhY3RpY2VzIGZvciBkZXBsb3lpbmcgYW5kIG1hbmFnaW5nIE1BTkVUIG5ldHdvcmtzLg0K DQoNCg0KVGhlIE1BTkVUIFdHIHdpbGwgaW50ZXJhY3Qgd2l0aCB0aGUgUElNIHdvcmtpbmcgZ3Jv dXAgb24gaXNzdWVzIHJlbGF0aW5nIHRvIHRoZSBtdWx0aWNhc3Qgd29yay4gIFRoZSBXRyB3aWxs IGFsc28gcGF5IGF0dGVudGlvbiB0byBvdGhlciBJRVRGIGFuZCBJUlRGIHdvcmsgdGhhdCBpcyBh ZGRyZXNzaW5nIHRvcGljcyByZWxhdGVkIHRvIE1BTkVUIGVudmlyb25tZW50cy4NCg0KDQoNCklu IHN1bW1hcnksIHRoZSBXRyB3aWxsIGRldmVsb3AgdGhlIGZvbGxvd2luZyBkcmFmdHM6DQoNCg0K DQooSldEIE1BTkVUIE1hbmFnZW1lbnQgRG9jdW1lbnQgaXMgcmVtb3ZlZCBhcyB0aGUgcmVxdWly ZW1lbnQgZm9yIHByb2R1Y2luZyB0aGUgZG9jdW1lbnQgaXMgbm8gbG9uZ2VyIHZhbGlkIGJ1dCB0 aGUgd29ya2luZyBncm91cCBtYXkgd29yayBvbiB0aGlzIGlmIHRoZXJlIGlzIGludGVyZXN0KQ0K DQpNQU5FVCBNYWludGVuYW5jZQ0KDQogLSBETEVQIG11bHRpcGxlIGZsb3cgZXh0ZW5zaW9ucyAo SldEIHVwZGF0ZWQgaXRlbSkNCg0KIChKV0QgUkZDNTQ0NCBTZWN1cml0eSBFeHRlbnNpb25zIGRv Y3VtZW50IGhhcyBiZWVuIHJlbW92ZWQgYXMgYSBkZWxpdmVyYWJsZSBidXQgbWF5IHN0aWxsIGJl IHdvcmtlZCB1cG9uIHVuZGVyIHRoZSBhdXNwaWNlcyBvZiBNQU5FVCBtYWludGVuYW5jZS4pDQoN Ck1BTkVUIE11bHRpY2FzdA0KDQogIC0gTXVsdGljYXN0IEZJQiAoU3RhbmRhcmRzKQ0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8g dGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91 ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9y IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B57E4GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0K c3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIHlvdSBrbm93 IEkgaGFkIHRvIGR1Y2sgb3V0IGVhcmx5LCBhbmQgeW91IHdlcmUgZ29uZSB3aGVuIEkgY2FtZSBi YWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QWxzbyBub3QgZm9yIGEgc3BlY2lmaWMgaXRlbSwgYnV0IEkgcHJlc3Vt ZSB3b3VsZCBiZSBwZXJtaXR0ZWQsIGlzIGlmIGFueW9uZSBkZWNpZGVkIHRvIHdvcmsgb24gY29u Y2VwdHMgc3VjaCBhcyBoaWVyYXJjaGljYWwgb3IgaHlicmlkIGRldmVsb3BtZW50cyBvZiBPTFNS djIuDQogU29tZW9uZSBhY3R1YWxseSBtZW50aW9uZWQgb25lIG9mIHRob3NlIHJlY2VudGx5LCBi dXQgSeKAmW0gbm90IGF3YXJlIG9mIGFueW9uZSBhY3RpdmVseSBwdXNoaW5nIG9uZS4gQnV0IGlu IGNhc2UgdGhleSBkaWQsIEkgcHJlc3VtZSB3b3VsZCBiZSBhbGxvd2VkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxv dmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGll ZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9z cGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0 ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJtYWlsdG86 Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu Y29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3 RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5C QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBh cmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVm PSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5 MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNB OEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lz dGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmlj ZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+SnVzdGluIERlYW48YnI+DQo8Yj5TZW50OjwvYj4gMTIgTWF5IDIwMTYgMTU6NTc8 YnI+DQo8Yj5Ubzo8L2I+IG1hbmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFttYW5l dF0gVXBkYXRlZCBhZnRlciBtZWV0aW5nIERyYWZ0IFJlY2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQg Mi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioq PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFs aWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBv dXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBp bnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz MzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91 IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5 Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGlu ZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0 IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJh bmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1 bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5 b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0i aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3Bv dGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBk ZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6MS4wcHQgNC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qPHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+KioNCjwvc3Bhbj48L3N0cm9uZz48L3NwYW4+PHN0cm9uZz48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5XQVJOSU5HDQo8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+KioqPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVz c2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcDt3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFua3MgdG8gZXZlcnlvbmUgd2hvIHdhcyBhYmxlIHRv IHBhcnRpY2lwYXRlIGluIHRoZSB2b2ljZSBjaGF0IHRvZGF5IHJlZ2FyZGluZyB0aGUgcmVjaGFy dGVyLiZuYnNwOyBCZWxvdyBpcyBhbiB1cGRhdGVkIGRyYWZ0IGNoYXJ0ZXIgYmFzZWQgdXBvbiBk aXNjdXNzaW9ucyBoYWQgaW4gdGhlIGNoYXQuJm5ic3A7IEkndmUgYWxzbyBpbmNsdWRlZCBpbmxp bmUgY29tbWVudHMgd2l0aCAoSldEIC4uLikgd2hpY2ggb2YgY291cnNlIHdpbGwgYmUgcmVtb3Zl ZCB3aGVuIG9mZmljaWFsbHkgYWRvcHRpbmcgdGhlIGRyYWZ0LiZuYnNwOyBJZiBzb21ldGhpbmcg aXMgbWlzc2luZyBvciBtaXNyZXByZXNlbnRlZCBwbGVhc2UgcHJvdmlkZSBmZWVkYmFjayBvbiB0 aGUgbGlzdCBzbyB3ZSBtYXkgYWRqdXN0IGl0IGFuZCB1cGRhdGUgaXQgYWNjb3JkaW5nbHkuJm5i c3A7IFRoZSBwbGFuIGlzIHRvIHByZXNlbnQgdGhlIGNoYXJ0ZXIgdG8gQWx2YXJvIGZvciBhZG9w dGlvbiB0byBiZSBjb21wbGV0ZWQgYmVmb3JlIHRoZSBuZXh0IElFVEYgbWVldGluZyBzbyBnZXQg eW91ciBjb21tZW50cyBpbiBBU0FQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRSQUZUIENIQVJURVI8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUg cHVycG9zZSBvZiB0aGUgTUFORVQgd29ya2luZyBncm91cCBpcyB0byBzdGFuZGFyZGl6ZSBJUCBy b3V0aW5nIHByb3RvY29sIGZ1bmN0aW9uYWxpdHkgc3VpdGFibGUgZm9yIHdpcmVsZXNzIHJvdXRp bmcgYXBwbGljYXRpb24gd2l0aGluIGJvdGggc3RhdGljIGFuZCBkeW5hbWljIHRvcG9sb2dpZXMg d2l0aCBpbmNyZWFzZWQgZHluYW1pY3MgZHVlIHRvIG5vZGUgbW90aW9uIG9yIG90aGVyIGZhY3Rv cnMuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkFwcHJvYWNoZXMgYXJlIGludGVuZGVkIHRvIGJlIHJlbGF0aXZlbHkg bGlnaHR3ZWlnaHQgaW4gbmF0dXJlLCBzdWl0YWJsZSBmb3IgbXVsdGlwbGUgaGFyZHdhcmUgYW5k IHdpcmVsZXNzIGVudmlyb25tZW50cywgYW5kIGFkZHJlc3Mgc2NlbmFyaW9zIHdoZXJlIE1BTkVU cyBhcmUgZGVwbG95ZWQgYXQgdGhlIGVkZ2VzIG9mIGFuIElQIGluZnJhc3RydWN0dXJlLiBIeWJy aWQgbWVzaCBpbmZyYXN0cnVjdHVyZXMgKGUuZy4sIGEgbWl4dHVyZSBvZiBmaXhlZCBhbmQgbW9i aWxlIHJvdXRlcnMpIHNob3VsZCBhbHNvIGJlIHN1cHBvcnRlZCBieSBNQU5FVCBzcGVjaWZpY2F0 aW9ucyBhbmQgbWFuYWdlbWVudCBmZWF0dXJlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgTUFORVQgV0cgaXMgcmVzcG9u c2libGUgZm9yIHRoZSBtYWludGVuYW5jZSBvZiBSRkM1NDQ0LCBOSERQLCBPTFNSdjIsIGFuZCBE TEVQLiBPZiBwb3NzaWJsZSBwYXJ0aWN1bGFyIGludGVyZXN0OiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+dHlwZSBleHRlbnNpb25zIGZvciBETEVQLCBzZWN1cml0eSBlbmhhbmNl bWVudHMgZm9yIFJGQzU0NDQvTkhEUC9PTFNSdjIsIGJlc3QgcHJhY3RpY2VzIGZvciBNQU5FVCBk ZXBsb3ltZW50L21hbmFnZW1lbnQsJm5ic3A7c291cmNlIHNwZWNpZmljIGV4dGVuc2lvbnMgZm9y IE9MU1J2MiwgYW5kIGltcG9ydC9leHBvcnQgb2Ygcm91dGluZyBzdGF0ZSBmb3IgTkhEUC9PTFNS djIuJm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXA7d29yZC13cmFwOmJy ZWFrLXdvcmQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+KEpXRCB0aGVzZSBhcmUgbm90IHBy b21pc2VkIGRlbGl2ZXJhYmxlIGl0ZW1zIGFuZCB3ZSBtYXkgd2FudCB0byByZW1vdmUgdGhlbSBh bmQganVzdCBnbyB3aXRoIG1haW50ZW5hbmNlIHdpdGhvdXQgbGlzdGluZyB0aGVtLCBhbHNvIHBs ZWFzZSBjb3JyZWN0IG1lIGlmIEkgbWlzcmVwcmVzZW50ZWQgdGhlIHdvcmsgdGFsa2VkIGFib3V0 IGluIHRoZSB3ZWJleCBtZWV0aW5nIGhlYWQgb24gTWF5IDEydGgpPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcDt3b3JkLXdyYXA6YnJlYWst d29yZCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgTUFORVQgV0cgd2lsbCBzdGFuZGFy ZGl6ZSBhIG11bHRpY2FzdCBNQU5FVCBwcm90b2NvbCBmcmFtZXdvcmsgYmFzZWQgb24gcHJldmlv dXMgd29yayBhbmQgbGVzc29ucyBsZWFybmVkIGZvciBzY29wZWQgZm9yd2FyZGluZyB3aXRoaW4g TUFORVQgbmV0d29ya3MuJm5ic3A7IEFzIHBhcnQgb2YgdGhpcyBmcmFtZXdvcmsgdGhlIFdHIHdp bGwgcHJvZHVjZSBhIHdlbGwgZGVmaW5lZCBNQU5FVCBtdWx0aWNhc3QgZm9yd2FyZGluZyBpbmZv cm1hdGlvbiBiYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoZSBXRyB3aWxsIHByb2R1Y2UgYW4gaW5mb3JtYXRpb25hbCBk cmFmdCBvdXRsaW5pbmcgY2hhbGxlbmdlcyBhbmQgYmVzdCBwcmFjdGljZXMgZm9yIGRlcGxveWlu ZyBhbmQgbWFuYWdpbmcgTUFORVQgbmV0d29ya3MuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBNQU5FVCBXRyB3aWxsIGlu dGVyYWN0IHdpdGggdGhlIFBJTSB3b3JraW5nIGdyb3VwIG9uIGlzc3VlcyByZWxhdGluZyB0byB0 aGUgbXVsdGljYXN0IHdvcmsuJm5ic3A7IFRoZSBXRyB3aWxsIGFsc28gcGF5IGF0dGVudGlvbiB0 byBvdGhlciBJRVRGIGFuZCBJUlRGIHdvcmsgdGhhdCBpcyBhZGRyZXNzaW5nIHRvcGljcyByZWxh dGVkIHRvIE1BTkVUIGVudmlyb25tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JbiBzdW1tYXJ5LCB0aGUgV0cgd2lsbCBk ZXZlbG9wIHRoZSBmb2xsb3dpbmcgZHJhZnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4oSldEIE1BTkVUIE1hbmFnZW1lbnQgRG9jdW1lbnQg aXMgcmVtb3ZlZCBhcyB0aGUgcmVxdWlyZW1lbnQgZm9yIHByb2R1Y2luZyB0aGUgZG9jdW1lbnQg aXMgbm8gbG9uZ2VyIHZhbGlkIGJ1dCB0aGUgd29ya2luZyBncm91cCBtYXkgd29yayBvbiB0aGlz IGlmIHRoZXJlIGlzIGludGVyZXN0KTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXA7 d29yZC13cmFwOmJyZWFrLXdvcmQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TUFORVQgTWFp bnRlbmFuY2UmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRl LXNwYWNlOnByZS13cmFwO3dvcmQtd3JhcDpicmVhay13b3JkIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+IC0gRExFUCBtdWx0aXBsZSBmbG93IGV4dGVuc2lvbnMgKEpXRCB1cGRhdGVkIGl0ZW0pPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcDt3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gKEpXRCBSRkM1NDQ0IFNlY3VyaXR5IEV4dGVuc2lvbnMg ZG9jdW1lbnQgaGFzIGJlZW4gcmVtb3ZlZCBhcyBhIGRlbGl2ZXJhYmxlIGJ1dCBtYXkgc3RpbGwg YmUgd29ya2VkIHVwb24gdW5kZXIgdGhlIGF1c3BpY2VzIG9mIE1BTkVUIG1haW50ZW5hbmNlLik8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5N QU5FVCBNdWx0aWNhc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRl LXNwYWNlOnByZS13cmFwO3dvcmQtd3JhcDpicmVhay13b3JkIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7IC0gTXVsdGljYXN0IEZJQiAoU3RhbmRhcmRzKTwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxw PioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPGJyPgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgcGxlYXNl IGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+Cllv dSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xv c2Ugb3I8YnI+CmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJy PgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKjwvcD48L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B57E4GLKXM0002VGREEN_-- From nobody Thu May 12 08:43:28 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAFA12D68C for ; Thu, 12 May 2016 08:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IukKLnReesP for ; Thu, 12 May 2016 08:43:23 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8466812D1B2 for ; Thu, 12 May 2016 08:43:23 -0700 (PDT) Received: by mail-ig0-x230.google.com with SMTP id m9so54934589ige.1 for ; Thu, 12 May 2016 08:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sCA5zOOWFN4m6LL661qUimBNe5orALpWGkYGdLL/XxM=; b=nmYoIySlT/6FQB74cFSQE4kanJPmjN2t7CaeknuFF+/SoM/2b0fr5ny6kgRsupYCCV SVts4omzMkOcCGFBqermBEB+lXeYEu8LUdmDEa5qzV4Q9YC9hj0+VYbqcjYRO/FIIl+K TvxgIa2t4cbCzM+tocWeNjK8R3IN3dHGrG+da0opKtzIeySuhTsiHZHxGq6X39qTKKtj JOey0IAprtFmcLFrsHBljNO/E0aHZ5HBW4BfbqwB4AitAMrP+OMoFIiTg7/rfYFo7iOJ US0SixxQql0d9YZ1/UMprn+WVcKjikJKNO3uoLiJ1UtRDhCHv14UAJFyK8GK+hSc6xsc 4WGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sCA5zOOWFN4m6LL661qUimBNe5orALpWGkYGdLL/XxM=; b=EpPukRS5ajh6BLPg4L+/hdkEXyMKQ/0K6eTUIS513j5FFnSRZdJJSOnLxggC9c5clF gUKMh6JuR7xzePoQedYbiTwr2bGxCiVhk8bQTTbV9jSUfJf/xVqD8d5o05S4JaPS3s2m +SqPC2VVyPxEGfocN16B8xf9aK21Kzeh7i42WN1UHmRJ40vTVVlg4CEpKwIcEOj6Fan5 hPdA08zKlTTrYSIJ5A3qAIiKFZGZgavHzDNQddFZ4yzncMpPT8pO+Avpe73n8PqtiWBx tmvrO31kS+o+veeqMXV7wk8AgezHsRA64p5wFRw8tLcUAC7FW0YJNSsvP2nPTn8NCbyb 1s0Q== X-Gm-Message-State: AOPr4FWFbLTSSq6+VDeNsx6FrxtiJdWB1TSMzcE3+8IP/YA6vLLKwFVKYs/qIBdw5RYOUv0E3FZdhg72FUHOKw== MIME-Version: 1.0 X-Received: by 10.50.124.39 with SMTP id mf7mr6763209igb.95.1463067802758; Thu, 12 May 2016 08:43:22 -0700 (PDT) Received: by 10.79.30.196 with HTTP; Thu, 12 May 2016 08:43:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 11:43:22 -0400 Message-ID: From: James Nguyen To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=089e0111bc56aa7a300532a704d6 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Updated after meeting Draft Recharter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:43:26 -0000 --089e0111bc56aa7a300532a704d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > As you know I had to duck out early, and you were gone when I came back. > > > > Also not for a specific item, but I presume would be permitted, is if > anyone decided to work on concepts such as hierarchical or hybrid > developments of OLSRv2. Someone actually mentioned one of those recently, > but I=E2=80=99m not aware of anyone actively pushing one. But in case the= y did, I > presume would be allowed. > > > +1 I'm interested in hierarchical OLSRv2 deployment. In addition, I'm also interested how to make OLSRv2 networks interoperable with other non-OLSRv2 networks. James > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean > *Sent:* 12 May 2016 15:57 > *To:* manet@ietf.org > *Subject:* [manet] Updated after meeting Draft Recharter > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > **** **WARNING ****** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > Thanks to everyone who was able to participate in the voice chat today re= garding the recharter. Below is an updated draft charter based upon discus= sions had in the chat. I've also included inline comments with (JWD ...) w= hich of course will be removed when officially adopting the draft. If some= thing is missing or misrepresented please provide feedback on the list so w= e may adjust it and update it accordingly. The plan is to present the char= ter to Alvaro for adoption to be completed before the next IETF meeting so = get your comments in ASAP. > > > > > > DRAFT CHARTER > > > > The purpose of the MANET working group is to standardize IP routing proto= col functionality suitable for wireless routing application within both sta= tic and dynamic topologies with increased dynamics due to node motion or ot= her factors. > > > > Approaches are intended to be relatively lightweight in nature, suitable = for multiple hardware and wireless environments, and address scenarios wher= e MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh inf= rastructures (e.g., a mixture of fixed and mobile routers) should also be s= upported by MANET specifications and management features. > > > > The MANET WG is responsible for the maintenance of RFC5444, NHDP, OLSRv2,= and DLEP. Of possible particular interest: type extensions for DLEP, secur= ity enhancements for RFC5444/NHDP/OLSRv2, best practices for MANET deployme= nt/management, source specific extensions for OLSRv2, and import/export of = routing state for NHDP/OLSRv2. > > (JWD these are not promised deliverable items and we may want to remove t= hem and just go with maintenance without listing them, also please correct = me if I misrepresented the work talked about in the webex meeting head on M= ay 12th) > > The MANET WG will standardize a multicast MANET protocol framework based = on previous work and lessons learned for scoped forwarding within MANET net= works. As part of this framework the WG will produce a well defined MANET = multicast forwarding information base. > > > > The WG will produce an informational draft outlining challenges and best = practices for deploying and managing MANET networks. > > > > The MANET WG will interact with the PIM working group on issues relating = to the multicast work. The WG will also pay attention to other IETF and IR= TF work that is addressing topics related to MANET environments. > > > > In summary, the WG will develop the following drafts: > > > > (JWD MANET Management Document is removed as the requirement for producin= g the document is no longer valid but the working group may work on this if= there is interest) > > MANET Maintenance > > - DLEP multiple flow extensions (JWD updated item) > > (JWD RFC5444 Security Extensions document has been removed as a delivera= ble but may still be worked upon under the auspices of MANET maintenance.) > > MANET Multicast > > - Multicast FIB (Standards) > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --=20 James Nguyen Email: james.huy.nguyen@gmail.com --089e0111bc56aa7a300532a704d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

As you know I had to= duck out early, and you were gone when I came back.

=C2=A0=

Also not for a speci= fic item, but I presume would be permitted, is if anyone decided to work on= concepts such as hierarchical or hybrid developments of OLSRv2. Someone actually mentioned one of those recently, but I=E2=80=99m not awar= e of anyone actively pushing one. But in case they did, I presume would be = allowed.

=C2=A0=

+1

I'm interes= ted in hierarchical OLSRv2 deployment.=C2=A0=20 In addition, I'm also interested how to make OLSRv2 networks=20 interoperable with other non-OLSRv2 networks.=C2=A0

James
= =C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
_____________________________= _____________________________________________

T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chel= msford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai=

BAE Systems Applied In= telligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

=C2=A0=

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean
Sent: 12 May 2016 15:57
To: manet@ietf.o= rg
Subject: [manet] Updated after meeting Draft Recharter=

=C2=A0

=C2=A0

*** WAR= NING ***

This message originates from outside our= organisation, either from an external partner or the internet.<= i>
Con= sider carefully whether you should click on any links, open any attachments= or reply.
For= information regarding Red Flags that you can look out for in emails you receive, click here.
If = you feel the email is suspicious, please follow this process.<= /u>

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our = organization.

=C2=A0

Thanks to everyone who was able to participate in the voice chat =
today regarding the recharter.=C2=A0 Below is an updated draft charter base=
d upon discussions had in the chat.=C2=A0 I've also included inline com=
ments with (JWD ...) which of course will be removed when officially adopti=
ng the draft.=C2=A0 If something is missing or misrepresented please provid=
e feedback on the list so we may adjust it and update it accordingly.=C2=A0=
 The plan is to present the charter to Alvaro for adoption to be completed =
before the next IETF meeting so get your comments in ASAP.
=C2=A0
=C2=A0
DRAFT CHARTER
=C2=A0
The purpose of the MANET working group is =
to standardize IP routing protocol functionality suitable for wireless rout=
ing application within both static and dynamic topologies with increased dy=
namics due to node motion or other factors.=C2=A0 

=C2=A0


Approaches are intended to be relatively l=
ightweight in nature, suitable for multiple hardware and wireless environme=
nts, and address scenarios where MANETs are deployed at the edges of an IP =
infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and m=
obile routers) should also be supported by MANET specifications and managem=
ent features.


=C2=A0


The MANET WG is responsible for the mainte=
nance of RFC5444, NHDP, OLSRv2, and DLEP. Of possible particular interest:=
=C2=A0type extensions for DLEP, security enhancements for RFC5=
444/NHDP/OLSRv2, best practices for MANET deployment/management,=C2=A0sourc=
e specific extensions for OLSRv2, and import/export of routing state for NH=
DP/OLSRv2.=C2=A0 

(JWD these are not promised deliverable items and we may want to =
remove them and just go with maintenance without listing them, also please =
correct me if I misrepresented the work talked about in the webex meeting h=
ead on May 12th)


The MANET WG will standardize a multicast MANET protocol framewor=
k based on previous work and lessons learned for scoped forwarding within M=
ANET networks.=C2=A0 As part of this framework the WG will produce a well d=
efined MANET multicast forwarding information base.

=C2=A0


The WG will produce an informational draft=
 outlining challenges and best practices for deploying and managing MANET n=
etworks. 


=C2=A0


The MANET WG will interact with the PIM wo=
rking group on issues relating to the multicast work.=C2=A0 The WG will als=
o pay attention to other IETF and IRTF work that is addressing topics relat=
ed to MANET environments.


=C2=A0


In summary, the WG will develop the follow=
ing drafts:


=C2=A0


(JWD MANET Management Document is removed as the requirement for=
 producing the document is no longer valid but the working group may work o=
n this if there is interest)


MANET Maintenance=C2=A0


 - DLEP mult=
iple flow extensions (JWD updated item)<=
u>


 (JWD RFC5444 Security Extensions document has been removed as a =
deliverable but may still be worked upon under the auspices of MANET mainte=
nance.)


MANET Multicast


=C2=A0 - Mul=
ticast FIB (Standards)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




--
James Nguyen
Email: james.huy.nguyen@gmail.com
--089e0111bc56aa7a300532a704d6-- From nobody Thu May 12 08:50:44 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7DF12D1B5 for ; Thu, 12 May 2016 08:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enrGTK5Ewnwq for ; Thu, 12 May 2016 08:50:39 -0700 (PDT) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E1812D1A9 for ; Thu, 12 May 2016 08:50:38 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,610,1454976000"; d="scan'208,217"; a="35214981" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 12 May 2016 16:50:35 +0100 X-IronPort-AV: E=Sophos;i="5.24,610,1454976000"; d="scan'208,217";a="117894303" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 12 May 2016 16:50:34 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.168]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Thu, 12 May 2016 16:50:34 +0100 From: "Dearlove, Christopher (UK)" To: James Nguyen Thread-Topic: [manet] Updated after meeting Draft Recharter Thread-Index: AQHRrF6St9vONTaTXU2u4zgtGGdx1Z+1af3Q///2iQCAABD9QA== Date: Thu, 12 May 2016 15:50:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B583DGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Updated after meeting Draft Recharter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:50:42 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B583DGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIHlvdSBleHBhbmQgb24gdGhlIGxhdHRlcj8NCg0KKEkgc3RhcnRlZCB3cml0aW5nIG15IHRo b3VnaHRzLCBidXQgZGVjaWRlZCBqdXN0IHRvIGFzay4gRXhjZXB0IG15IHRob3VnaHRzIHJ1biB0 byBzY2VuYXJpb3MsIHdoaWNoIGFscmVhZHkgd29yaywgd2hpY2ggbmVlZCBuZXcgd29yaz8pDQoN Ci0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFF IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBT eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywg R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMu Y29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzog MDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRm b3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogSmFtZXMgTmd1eWVuIFttYWlsdG86amFtZXMu aHV5Lm5ndXllbkBnbWFpbC5jb21dDQpTZW50OiAxMiBNYXkgMjAxNiAxNjo0Mw0KVG86IERlYXJs b3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzogSnVzdGluIERlYW47IG1hbmV0QGlldGYub3JnDQpT dWJqZWN0OiBSZTogW21hbmV0XSBVcGRhdGVkIGFmdGVyIG1lZXRpbmcgRHJhZnQgUmVjaGFydGVy DQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp ZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0 aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNr IG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3Jt YXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVt YWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3Rl bXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFn cy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xs b3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3 b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGlj aW91cyUyMEVtYWlscy5wZGY+Lg0KDQoNCk9uIFRodSwgTWF5IDEyLCAyMDE2IGF0IDExOjIwIEFN LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpBcyB5b3Ug a25vdyBJIGhhZCB0byBkdWNrIG91dCBlYXJseSwgYW5kIHlvdSB3ZXJlIGdvbmUgd2hlbiBJIGNh bWUgYmFjay4NCg0KQWxzbyBub3QgZm9yIGEgc3BlY2lmaWMgaXRlbSwgYnV0IEkgcHJlc3VtZSB3 b3VsZCBiZSBwZXJtaXR0ZWQsIGlzIGlmIGFueW9uZSBkZWNpZGVkIHRvIHdvcmsgb24gY29uY2Vw dHMgc3VjaCBhcyBoaWVyYXJjaGljYWwgb3IgaHlicmlkIGRldmVsb3BtZW50cyBvZiBPTFNSdjIu IFNvbWVvbmUgYWN0dWFsbHkgbWVudGlvbmVkIG9uZSBvZiB0aG9zZSByZWNlbnRseSwgYnV0IEni gJltIG5vdCBhd2FyZSBvZiBhbnlvbmUgYWN0aXZlbHkgcHVzaGluZyBvbmUuIEJ1dCBpbiBjYXNl IHRoZXkgZGlkLCBJIHByZXN1bWUgd291bGQgYmUgYWxsb3dlZC4NCg0KKzENCkknbSBpbnRlcmVz dGVkIGluIGhpZXJhcmNoaWNhbCBPTFNSdjIgZGVwbG95bWVudC4gIEluIGFkZGl0aW9uLCBJJ20g YWxzbyBpbnRlcmVzdGVkIGhvdyB0byBtYWtlIE9MU1J2MiBuZXR3b3JrcyBpbnRlcm9wZXJhYmxl IHdpdGggb3RoZXIgbm9uLU9MU1J2MiBuZXR3b3Jrcy4NCkphbWVzDQoNCi0tDQpDaHJpc3RvcGhl ciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGll ZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0 ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0PiAgfCAgRTog Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9y ZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhI Ti4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0K QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBF bmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJl c2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IG1hbmV0IFtt YWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9y Zz5dIE9uIEJlaGFsZiBPZiBKdXN0aW4gRGVhbg0KU2VudDogMTIgTWF5IDIwMTYgMTU6NTcNClRv OiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbWFuZXRd IFVwZGF0ZWQgYWZ0ZXIgbWVldGluZyBEcmFmdCBSZWNoYXJ0ZXINCg0KDQoqKiogV0FSTklORyAq KioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9u LCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNp ZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVu IGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVk IEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBj bGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3Nl Y3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVl bCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0 cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp Z2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4u DQoqKiogV0FSTklORyAqKioNCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5h dGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLg0KDQoNClRoYW5rcyB0byBldmVyeW9u ZSB3aG8gd2FzIGFibGUgdG8gcGFydGljaXBhdGUgaW4gdGhlIHZvaWNlIGNoYXQgdG9kYXkgcmVn YXJkaW5nIHRoZSByZWNoYXJ0ZXIuICBCZWxvdyBpcyBhbiB1cGRhdGVkIGRyYWZ0IGNoYXJ0ZXIg YmFzZWQgdXBvbiBkaXNjdXNzaW9ucyBoYWQgaW4gdGhlIGNoYXQuICBJJ3ZlIGFsc28gaW5jbHVk ZWQgaW5saW5lIGNvbW1lbnRzIHdpdGggKEpXRCAuLi4pIHdoaWNoIG9mIGNvdXJzZSB3aWxsIGJl IHJlbW92ZWQgd2hlbiBvZmZpY2lhbGx5IGFkb3B0aW5nIHRoZSBkcmFmdC4gIElmIHNvbWV0aGlu ZyBpcyBtaXNzaW5nIG9yIG1pc3JlcHJlc2VudGVkIHBsZWFzZSBwcm92aWRlIGZlZWRiYWNrIG9u IHRoZSBsaXN0IHNvIHdlIG1heSBhZGp1c3QgaXQgYW5kIHVwZGF0ZSBpdCBhY2NvcmRpbmdseS4g IFRoZSBwbGFuIGlzIHRvIHByZXNlbnQgdGhlIGNoYXJ0ZXIgdG8gQWx2YXJvIGZvciBhZG9wdGlv biB0byBiZSBjb21wbGV0ZWQgYmVmb3JlIHRoZSBuZXh0IElFVEYgbWVldGluZyBzbyBnZXQgeW91 ciBjb21tZW50cyBpbiBBU0FQLg0KDQoNCg0KDQoNCkRSQUZUIENIQVJURVINCg0KDQoNClRoZSBw dXJwb3NlIG9mIHRoZSBNQU5FVCB3b3JraW5nIGdyb3VwIGlzIHRvIHN0YW5kYXJkaXplIElQIHJv dXRpbmcgcHJvdG9jb2wgZnVuY3Rpb25hbGl0eSBzdWl0YWJsZSBmb3Igd2lyZWxlc3Mgcm91dGlu ZyBhcHBsaWNhdGlvbiB3aXRoaW4gYm90aCBzdGF0aWMgYW5kIGR5bmFtaWMgdG9wb2xvZ2llcyB3 aXRoIGluY3JlYXNlZCBkeW5hbWljcyBkdWUgdG8gbm9kZSBtb3Rpb24gb3Igb3RoZXIgZmFjdG9y cy4NCg0KDQoNCkFwcHJvYWNoZXMgYXJlIGludGVuZGVkIHRvIGJlIHJlbGF0aXZlbHkgbGlnaHR3 ZWlnaHQgaW4gbmF0dXJlLCBzdWl0YWJsZSBmb3IgbXVsdGlwbGUgaGFyZHdhcmUgYW5kIHdpcmVs ZXNzIGVudmlyb25tZW50cywgYW5kIGFkZHJlc3Mgc2NlbmFyaW9zIHdoZXJlIE1BTkVUcyBhcmUg ZGVwbG95ZWQgYXQgdGhlIGVkZ2VzIG9mIGFuIElQIGluZnJhc3RydWN0dXJlLiBIeWJyaWQgbWVz aCBpbmZyYXN0cnVjdHVyZXMgKGUuZy4sIGEgbWl4dHVyZSBvZiBmaXhlZCBhbmQgbW9iaWxlIHJv dXRlcnMpIHNob3VsZCBhbHNvIGJlIHN1cHBvcnRlZCBieSBNQU5FVCBzcGVjaWZpY2F0aW9ucyBh bmQgbWFuYWdlbWVudCBmZWF0dXJlcy4NCg0KDQoNClRoZSBNQU5FVCBXRyBpcyByZXNwb25zaWJs ZSBmb3IgdGhlIG1haW50ZW5hbmNlIG9mIFJGQzU0NDQsIE5IRFAsIE9MU1J2MiwgYW5kIERMRVAu IE9mIHBvc3NpYmxlIHBhcnRpY3VsYXIgaW50ZXJlc3Q6IHR5cGUgZXh0ZW5zaW9ucyBmb3IgRExF UCwgc2VjdXJpdHkgZW5oYW5jZW1lbnRzIGZvciBSRkM1NDQ0L05IRFAvT0xTUnYyLCBiZXN0IHBy YWN0aWNlcyBmb3IgTUFORVQgZGVwbG95bWVudC9tYW5hZ2VtZW50LCBzb3VyY2Ugc3BlY2lmaWMg ZXh0ZW5zaW9ucyBmb3IgT0xTUnYyLCBhbmQgaW1wb3J0L2V4cG9ydCBvZiByb3V0aW5nIHN0YXRl IGZvciBOSERQL09MU1J2Mi4NCg0KKEpXRCB0aGVzZSBhcmUgbm90IHByb21pc2VkIGRlbGl2ZXJh YmxlIGl0ZW1zIGFuZCB3ZSBtYXkgd2FudCB0byByZW1vdmUgdGhlbSBhbmQganVzdCBnbyB3aXRo IG1haW50ZW5hbmNlIHdpdGhvdXQgbGlzdGluZyB0aGVtLCBhbHNvIHBsZWFzZSBjb3JyZWN0IG1l IGlmIEkgbWlzcmVwcmVzZW50ZWQgdGhlIHdvcmsgdGFsa2VkIGFib3V0IGluIHRoZSB3ZWJleCBt ZWV0aW5nIGhlYWQgb24gTWF5IDEydGgpDQoNClRoZSBNQU5FVCBXRyB3aWxsIHN0YW5kYXJkaXpl IGEgbXVsdGljYXN0IE1BTkVUIHByb3RvY29sIGZyYW1ld29yayBiYXNlZCBvbiBwcmV2aW91cyB3 b3JrIGFuZCBsZXNzb25zIGxlYXJuZWQgZm9yIHNjb3BlZCBmb3J3YXJkaW5nIHdpdGhpbiBNQU5F VCBuZXR3b3Jrcy4gIEFzIHBhcnQgb2YgdGhpcyBmcmFtZXdvcmsgdGhlIFdHIHdpbGwgcHJvZHVj ZSBhIHdlbGwgZGVmaW5lZCBNQU5FVCBtdWx0aWNhc3QgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBi YXNlLg0KDQoNCg0KVGhlIFdHIHdpbGwgcHJvZHVjZSBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0IG91 dGxpbmluZyBjaGFsbGVuZ2VzIGFuZCBiZXN0IHByYWN0aWNlcyBmb3IgZGVwbG95aW5nIGFuZCBt YW5hZ2luZyBNQU5FVCBuZXR3b3Jrcy4NCg0KDQoNClRoZSBNQU5FVCBXRyB3aWxsIGludGVyYWN0 IHdpdGggdGhlIFBJTSB3b3JraW5nIGdyb3VwIG9uIGlzc3VlcyByZWxhdGluZyB0byB0aGUgbXVs dGljYXN0IHdvcmsuICBUaGUgV0cgd2lsbCBhbHNvIHBheSBhdHRlbnRpb24gdG8gb3RoZXIgSUVU RiBhbmQgSVJURiB3b3JrIHRoYXQgaXMgYWRkcmVzc2luZyB0b3BpY3MgcmVsYXRlZCB0byBNQU5F VCBlbnZpcm9ubWVudHMuDQoNCg0KDQpJbiBzdW1tYXJ5LCB0aGUgV0cgd2lsbCBkZXZlbG9wIHRo ZSBmb2xsb3dpbmcgZHJhZnRzOg0KDQoNCg0KKEpXRCBNQU5FVCBNYW5hZ2VtZW50IERvY3VtZW50 IGlzIHJlbW92ZWQgYXMgdGhlIHJlcXVpcmVtZW50IGZvciBwcm9kdWNpbmcgdGhlIGRvY3VtZW50 IGlzIG5vIGxvbmdlciB2YWxpZCBidXQgdGhlIHdvcmtpbmcgZ3JvdXAgbWF5IHdvcmsgb24gdGhp cyBpZiB0aGVyZSBpcyBpbnRlcmVzdCkNCg0KTUFORVQgTWFpbnRlbmFuY2UNCg0KIC0gRExFUCBt dWx0aXBsZSBmbG93IGV4dGVuc2lvbnMgKEpXRCB1cGRhdGVkIGl0ZW0pDQoNCiAoSldEIFJGQzU0 NDQgU2VjdXJpdHkgRXh0ZW5zaW9ucyBkb2N1bWVudCBoYXMgYmVlbiByZW1vdmVkIGFzIGEgZGVs aXZlcmFibGUgYnV0IG1heSBzdGlsbCBiZSB3b3JrZWQgdXBvbiB1bmRlciB0aGUgYXVzcGljZXMg b2YgTUFORVQgbWFpbnRlbmFuY2UuKQ0KDQpNQU5FVCBNdWx0aWNhc3QNCg0KICAtIE11bHRpY2Fz dCBGSUIgKFN0YW5kYXJkcykNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lw aWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2Vu ZGVyLg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5v ciBkaXNjbG9zZSBvcg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv bi4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5l dEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQN Cg0KDQoNCi0tDQpKYW1lcyBOZ3V5ZW4NCkVtYWlsOiBqYW1lcy5odXkubmd1eWVuQGdtYWlsLmNv bTxtYWlsdG86amFtZXMuaHV5Lm5ndXllbkBnbWFpbC5jb20+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B583DGLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNh biB5b3UgZXhwYW5kIG9uIHRoZSBsYXR0ZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oSSBzdGFydGVkIHdyaXRpbmcg bXkgdGhvdWdodHMsIGJ1dCBkZWNpZGVkIGp1c3QgdG8gYXNrLiBFeGNlcHQgbXkgdGhvdWdodHMg cnVuIHRvIHNjZW5hcmlvcywgd2hpY2ggYWxyZWFkeSB3b3JrLCB3aGljaCBuZWVkIG5ldyB3b3Jr Pyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNo cmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48 L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdE N0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0Qi PjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8L2I+ PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2Zv cmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4 SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExp bWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUx PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+ UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJl eSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKYW1lcyBOZ3V5ZW4gW21haWx0bzpqYW1lcy5odXkubmd1 eWVuQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMiBNYXkgMjAxNiAxNjo0Mzxicj4N CjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+IEp1 c3RpbiBEZWFuOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0 XSBVcGRhdGVkIGFmdGVyIG1lZXRpbmcgRHJhZnQgUmVjaGFydGVyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAy LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1h bGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8 bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxp Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91 ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGlu dGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz Mzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ug c2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHku PC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5n IDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQg Zm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFu ZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3Vt ZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlv dSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJo dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90 bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRm Ij4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXkgMTIsIDIwMTYgYXQgMTE6MjAg QU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5BcyB5b3Uga25vdyBJIGhhZCB0byBkdWNrIG91dCBlYXJseSwgYW5kIHlvdSB3 ZXJlIGdvbmUgd2hlbiBJIGNhbWUgYmFjay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbHNvIG5vdCBmb3IgYSBz cGVjaWZpYyBpdGVtLCBidXQgSSBwcmVzdW1lIHdvdWxkIGJlIHBlcm1pdHRlZCwgaXMgaWYgYW55 b25lIGRlY2lkZWQgdG8gd29yayBvbiBjb25jZXB0cw0KIHN1Y2ggYXMgaGllcmFyY2hpY2FsIG9y IGh5YnJpZCBkZXZlbG9wbWVudHMgb2YgT0xTUnYyLiBTb21lb25lIGFjdHVhbGx5IG1lbnRpb25l ZCBvbmUgb2YgdGhvc2UgcmVjZW50bHksIGJ1dCBJ4oCZbSBub3QgYXdhcmUgb2YgYW55b25lIGFj dGl2ZWx5IHB1c2hpbmcgb25lLiBCdXQgaW4gY2FzZSB0aGV5IGRpZCwgSSBwcmVzdW1lIHdvdWxk IGJlIGFsbG93ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+JiM0MzsxPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+SSdtIGludGVyZXN0ZWQgaW4gaGllcmFyY2hpY2FsIE9MU1J2MiBkZXBs b3ltZW50LiZuYnNwOyBJbiBhZGRpdGlvbiwgSSdtIGFsc28gaW50ZXJlc3RlZCBob3cgdG8gbWFr ZSBPTFNSdjIgbmV0d29ya3MgaW50ZXJvcGVyYWJsZSB3aXRoIG90aGVyIG5vbi1PTFNSdjIgbmV0 d29ya3MuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SmFtZXM8YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNo cmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48 L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdE N0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0Qi PjogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdl dD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPg0KICZuYnNwO3wgJm5ic3A7PGI+ RTogPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywg Q2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5 c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIi Pnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNB OEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lz dGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj M0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9y ZCwgU3VycmV5LCBHVTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtYW5ldA0KIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldC1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIERlYW48YnI+ DQo8Yj5TZW50OjwvYj4gMTIgTWF5IDIwMTYgMTU6NTc8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9 Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbWFuZXRdIFVwZGF0ZWQgYWZ0ZXIgbWVldGluZyBEcmFm dCBSZWNoYXJ0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEu MHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGU7YmFj a2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dy b3VuZC1wb3NpdGlvbi15OjAlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1hdHRhY2ht ZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15 OjAlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdB Uk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndo aXRlO2JhY2tncm91bmQtYXR0YWNobWVudDpzY3JvbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAl O2JhY2tncm91bmQtcG9zaXRpb24teTowJSI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIg b3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRl cm5ldC48YnI+DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9u IGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9yIGluZm9y bWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+PC9pPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVt YWlscw0KIHlvdSByZWNlaXZlLCBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJh ZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQl MjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCmhlcmU8L2E+Ljxicj4NCklmIHlvdSBmZWVs IHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IDxhIGhyZWY9Imh0dHA6Ly9p bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv RG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdl dD0iX2JsYW5rIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPio8 Yj4qKiA8L2I+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldBUk5JTkcNCjwv c3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPioqKjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RVhURVJOQUwgRU1B SUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRp b248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUt d3JhcDt3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFu a3MgdG8gZXZlcnlvbmUgd2hvIHdhcyBhYmxlIHRvIHBhcnRpY2lwYXRlIGluIHRoZSB2b2ljZSBj aGF0IHRvZGF5IHJlZ2FyZGluZyB0aGUgcmVjaGFydGVyLiZuYnNwOyBCZWxvdyBpcyBhbiB1cGRh dGVkIGRyYWZ0IGNoYXJ0ZXIgYmFzZWQgdXBvbiBkaXNjdXNzaW9ucyBoYWQgaW4gdGhlIGNoYXQu Jm5ic3A7IEkndmUgYWxzbyBpbmNsdWRlZCBpbmxpbmUgY29tbWVudHMgd2l0aCAoSldEIC4uLikg d2hpY2ggb2YgY291cnNlIHdpbGwgYmUgcmVtb3ZlZCB3aGVuIG9mZmljaWFsbHkgYWRvcHRpbmcg dGhlIGRyYWZ0LiZuYnNwOyBJZiBzb21ldGhpbmcgaXMgbWlzc2luZyBvciBtaXNyZXByZXNlbnRl ZCBwbGVhc2UgcHJvdmlkZSBmZWVkYmFjayBvbiB0aGUgbGlzdCBzbyB3ZSBtYXkgYWRqdXN0IGl0 IGFuZCB1cGRhdGUgaXQgYWNjb3JkaW5nbHkuJm5ic3A7IFRoZSBwbGFuIGlzIHRvIHByZXNlbnQg dGhlIGNoYXJ0ZXIgdG8gQWx2YXJvIGZvciBhZG9wdGlvbiB0byBiZSBjb21wbGV0ZWQgYmVmb3Jl IHRoZSBuZXh0IElFVEYgbWVldGluZyBzbyBnZXQgeW91ciBjb21tZW50cyBpbiBBU0FQLjwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkRSQUZUIENIQVJURVI8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgcHVycG9zZSBvZiB0aGUgTUFORVQgd29ya2lu ZyBncm91cCBpcyB0byBzdGFuZGFyZGl6ZSBJUCByb3V0aW5nIHByb3RvY29sIGZ1bmN0aW9uYWxp dHkgc3VpdGFibGUgZm9yIHdpcmVsZXNzIHJvdXRpbmcgYXBwbGljYXRpb24gd2l0aGluIGJvdGgg c3RhdGljIGFuZCBkeW5hbWljIHRvcG9sb2dpZXMgd2l0aCBpbmNyZWFzZWQgZHluYW1pY3MgZHVl IHRvIG5vZGUgbW90aW9uIG9yIG90aGVyIGZhY3RvcnMuJm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFwcHJvYWNoZXMg YXJlIGludGVuZGVkIHRvIGJlIHJlbGF0aXZlbHkgbGlnaHR3ZWlnaHQgaW4gbmF0dXJlLCBzdWl0 YWJsZSBmb3IgbXVsdGlwbGUgaGFyZHdhcmUgYW5kIHdpcmVsZXNzIGVudmlyb25tZW50cywgYW5k IGFkZHJlc3Mgc2NlbmFyaW9zIHdoZXJlIE1BTkVUcyBhcmUgZGVwbG95ZWQgYXQgdGhlIGVkZ2Vz IG9mIGFuIElQIGluZnJhc3RydWN0dXJlLiBIeWJyaWQgbWVzaCBpbmZyYXN0cnVjdHVyZXMgKGUu Zy4sIGEgbWl4dHVyZSBvZiBmaXhlZCBhbmQgbW9iaWxlIHJvdXRlcnMpIHNob3VsZCBhbHNvIGJl IHN1cHBvcnRlZCBieSBNQU5FVCBzcGVjaWZpY2F0aW9ucyBhbmQgbWFuYWdlbWVudCBmZWF0dXJl cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5UaGUgTUFORVQgV0cgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBtYWludGVuYW5jZSBv ZiBSRkM1NDQ0LCBOSERQLCBPTFNSdjIsIGFuZCBETEVQLiBPZiBwb3NzaWJsZSBwYXJ0aWN1bGFy IGludGVyZXN0OiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+dHlwZSBleHRlbnNp b25zIGZvciBETEVQLCBzZWN1cml0eSBlbmhhbmNlbWVudHMgZm9yIFJGQzU0NDQvTkhEUC9PTFNS djIsIGJlc3QgcHJhY3RpY2VzIGZvciBNQU5FVCBkZXBsb3ltZW50L21hbmFnZW1lbnQsJm5ic3A7 c291cmNlIHNwZWNpZmljIGV4dGVuc2lvbnMgZm9yIE9MU1J2MiwgYW5kIGltcG9ydC9leHBvcnQg b2Ygcm91dGluZyBzdGF0ZSBmb3IgTkhEUC9PTFNSdjIuJm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXA7d29yZC13cmFwOmJyZWFr LXdvcmQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+KEpXRCB0aGVzZSBhcmUgbm90IHByb21p c2VkIGRlbGl2ZXJhYmxlIGl0ZW1zIGFuZCB3ZSBtYXkgd2FudCB0byByZW1vdmUgdGhlbSBhbmQg anVzdCBnbyB3aXRoIG1haW50ZW5hbmNlIHdpdGhvdXQgbGlzdGluZyB0aGVtLCBhbHNvIHBsZWFz ZSBjb3JyZWN0IG1lIGlmIEkgbWlzcmVwcmVzZW50ZWQgdGhlIHdvcmsgdGFsa2VkIGFib3V0IGlu IHRoZSB3ZWJleCBtZWV0aW5nIGhlYWQgb24gTWF5IDEydGgpPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcDt3b3JkLXdyYXA6YnJlYWstd29y ZCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgTUFORVQgV0cgd2lsbCBzdGFuZGFyZGl6 ZSBhIG11bHRpY2FzdCBNQU5FVCBwcm90b2NvbCBmcmFtZXdvcmsgYmFzZWQgb24gcHJldmlvdXMg d29yayBhbmQgbGVzc29ucyBsZWFybmVkIGZvciBzY29wZWQgZm9yd2FyZGluZyB3aXRoaW4gTUFO RVQgbmV0d29ya3MuJm5ic3A7IEFzIHBhcnQgb2YgdGhpcyBmcmFtZXdvcmsgdGhlIFdHIHdpbGwg cHJvZHVjZSBhIHdlbGwgZGVmaW5lZCBNQU5FVCBtdWx0aWNhc3QgZm9yd2FyZGluZyBpbmZvcm1h dGlvbiBiYXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlRoZSBXRyB3aWxsIHByb2R1Y2UgYW4gaW5mb3JtYXRpb25hbCBkcmFm dCBvdXRsaW5pbmcgY2hhbGxlbmdlcyBhbmQgYmVzdCBwcmFjdGljZXMgZm9yIGRlcGxveWluZyBh bmQgbWFuYWdpbmcgTUFORVQgbmV0d29ya3MuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBNQU5FVCBXRyB3aWxsIGludGVy YWN0IHdpdGggdGhlIFBJTSB3b3JraW5nIGdyb3VwIG9uIGlzc3VlcyByZWxhdGluZyB0byB0aGUg bXVsdGljYXN0IHdvcmsuJm5ic3A7IFRoZSBXRyB3aWxsIGFsc28gcGF5IGF0dGVudGlvbiB0byBv dGhlciBJRVRGIGFuZCBJUlRGIHdvcmsgdGhhdCBpcyBhZGRyZXNzaW5nIHRvcGljcyByZWxhdGVk IHRvIE1BTkVUIGVudmlyb25tZW50cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JbiBzdW1tYXJ5LCB0aGUgV0cgd2lsbCBkZXZl bG9wIHRoZSBmb2xsb3dpbmcgZHJhZnRzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4oSldEIE1BTkVUIE1hbmFnZW1lbnQgRG9jdW1lbnQgaXMg cmVtb3ZlZCBhcyB0aGUgcmVxdWlyZW1lbnQgZm9yIHByb2R1Y2luZyB0aGUgZG9jdW1lbnQgaXMg bm8gbG9uZ2VyIHZhbGlkIGJ1dCB0aGUgd29ya2luZyBncm91cCBtYXkgd29yayBvbiB0aGlzIGlm IHRoZXJlIGlzIGludGVyZXN0KTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i d2hpdGUtc3BhY2U6cHJlLXdyYXA7d29yZC13cmFwOmJyZWFrLXdvcmQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+TUFORVQgTWFpbnRlbmFuY2UmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwO3dvcmQtd3JhcDpicmVhay13b3Jk Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IC0gRExFUCBtdWx0aXBsZSBmbG93IGV4dGVuc2lvbnMg KEpXRCB1cGRhdGVkIGl0ZW0pPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUtd3JhcDt3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4gKEpXRCBSRkM1NDQ0IFNlY3VyaXR5IEV4dGVuc2lvbnMgZG9jdW1lbnQgaGFz IGJlZW4gcmVtb3ZlZCBhcyBhIGRlbGl2ZXJhYmxlIGJ1dCBtYXkgc3RpbGwgYmUgd29ya2VkIHVw b24gdW5kZXIgdGhlIGF1c3BpY2VzIG9mIE1BTkVUIG1haW50ZW5hbmNlLik8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NQU5FVCBNdWx0aWNh c3Q8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13 cmFwO3dvcmQtd3JhcDpicmVhay13b3JkIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7IC0g TXVsdGljYXN0IEZJQiAoU3RhbmRhcmRzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4N CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkPGJyPg0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3Rl bSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4NCmRpc3RyaWJ1dGUgaXRz IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBp ZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0i YWxsIj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkphbWVzIE5ndXllbjxicj4NCkVtYWlsOiA8YSBocmVmPSJtYWlsdG86amFtZXMuaHV5Lm5n dXllbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qYW1lcy5odXkubmd1eWVuQGdtYWlsLmNv bTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B583DGLKXM0002VGREEN_-- From nobody Thu May 12 08:57:04 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1ED12D1B5 for ; Thu, 12 May 2016 08:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xLkbFjltFSj for ; Thu, 12 May 2016 08:56:59 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAA112D0E3 for ; Thu, 12 May 2016 08:56:59 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id lr7so57637208igb.1 for ; Thu, 12 May 2016 08:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fxWcyeXAydWaY5vmGeMmaZQc/qYVW/Tw497Xi/3tR5w=; b=BLNJQDedHqs0KNlsQFH0q6B8FC1lO1oPwLohob+97k586waBa4uIveeZGSXTiZddPC 0G/nevzx3DC959oJHZBkT8KxhS6XrT4lExSFNQKD7++HBqJwkl+VWBve52eDTKdbjqzk xi3HYBkTv0oiME6sRYPMdSW72hg8sZVo/qtQQ1aCTdlkz2kRcpnos/V9rIK5EiiMJYu7 bMUtcuiPaH3/Qe7q1KFB490m4VPvRMej58spTi21TEHCSc8Mx2T3Ra3xlKQq3KrUgZDU WaaNntGNbDAMZ50VWasek7QfJssjU6vw1Lj96vkLNtskY/095WFKj6F9P8V5xkwuhJKF S7nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fxWcyeXAydWaY5vmGeMmaZQc/qYVW/Tw497Xi/3tR5w=; b=iu1gbSxoFNFSQR2ql9iBk1JDhv8eO4oAoTEDKgS2Ih/E5N5m194InRL+bOAFCkdECY qOgSW0S0cCYYPX54PWObcYFgTRKooM0VA3RLHF69yUxFFE1+hbYDySULnI7Wwp/EFJdv y5krn+xabYBIOXnovug0rJ0GGZUAegwX2+zhr3IhjTWE07XZPMHnYagTaqYeLBiHmp6T mpxYBYGZ4zPv3x7vaHjTSwq6C2WlTMLT8pgbC6sLUCVmEZj46hB/Qbelwu7wIzuvmdTw vBJUVIZZBIu4FSLcL4r3uAHhNTV525lloe2tsSepcNOlqawV0PMNlGWXYH5d3mSd+ZNG phbg== X-Gm-Message-State: AOPr4FUh7gQA3AXjkdulTH/vtZArfgizZqm4VvvA5iygcmLu07S8akIV+0Q6Jq1+iCiO0QsN5ezQatLW7s/O7A== MIME-Version: 1.0 X-Received: by 10.50.221.67 with SMTP id qc3mr26203456igc.36.1463068618583; Thu, 12 May 2016 08:56:58 -0700 (PDT) Received: by 10.79.72.134 with HTTP; Thu, 12 May 2016 08:56:58 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 11:56:58 -0400 Message-ID: From: Stan Ratliff To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a11343b784af9250532a7358c Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Updated after meeting Draft Recharter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:57:02 -0000 --001a11343b784af9250532a7358c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 12, 2016 at 11:50 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Can you expand on the latter? > Ditto. I'm interested in this as well, depending on the scenario. Regards, Stan > > > (I started writing my thoughts, but decided just to ask. Except my > thoughts run to scenarios, which already work, which need new work?) > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > *From:* James Nguyen [mailto:james.huy.nguyen@gmail.com] > *Sent:* 12 May 2016 16:43 > *To:* Dearlove, Christopher (UK) > *Cc:* Justin Dean; manet@ietf.org > *Subject:* Re: [manet] Updated after meeting Draft Recharter > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > > > > > On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > As you know I had to duck out early, and you were gone when I came back. > > > > Also not for a specific item, but I presume would be permitted, is if > anyone decided to work on concepts such as hierarchical or hybrid > developments of OLSRv2. Someone actually mentioned one of those recently, > but I=E2=80=99m not aware of anyone actively pushing one. But in case the= y did, I > presume would be allowed. > > > > +1 > > I'm interested in hierarchical OLSRv2 deployment. In addition, I'm also > interested how to make OLSRv2 networks interoperable with other non-OLSRv= 2 > networks. > > James > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean > *Sent:* 12 May 2016 15:57 > *To:* manet@ietf.org > *Subject:* [manet] Updated after meeting Draft Recharter > > > > > > **** WARNING **** > > > > *This message originates from outside our organisation, either from an > external partner or the internet. Consider carefully whether you should > click on any links, open any attachments or reply. For information > regarding **Red Flags* > * that you can look out for in emails you receive, click here > . > If you feel the email is suspicious, please follow this process > .* > > **** **WARNING ****** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > Thanks to everyone who was able to participate in the voice chat today re= garding the recharter. Below is an updated draft charter based upon discus= sions had in the chat. I've also included inline comments with (JWD ...) w= hich of course will be removed when officially adopting the draft. If some= thing is missing or misrepresented please provide feedback on the list so w= e may adjust it and update it accordingly. The plan is to present the char= ter to Alvaro for adoption to be completed before the next IETF meeting so = get your comments in ASAP. > > > > > > DRAFT CHARTER > > > > The purpose of the MANET working group is to standardize IP routing proto= col functionality suitable for wireless routing application within both sta= tic and dynamic topologies with increased dynamics due to node motion or ot= her factors. > > > > Approaches are intended to be relatively lightweight in nature, suitable = for multiple hardware and wireless environments, and address scenarios wher= e MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh inf= rastructures (e.g., a mixture of fixed and mobile routers) should also be s= upported by MANET specifications and management features. > > > > The MANET WG is responsible for the maintenance of RFC5444, NHDP, OLSRv2,= and DLEP. Of possible particular interest: type extensions for DLEP, secur= ity enhancements for RFC5444/NHDP/OLSRv2, best practices for MANET deployme= nt/management, source specific extensions for OLSRv2, and import/export of = routing state for NHDP/OLSRv2. > > (JWD these are not promised deliverable items and we may want to remove t= hem and just go with maintenance without listing them, also please correct = me if I misrepresented the work talked about in the webex meeting head on M= ay 12th) > > The MANET WG will standardize a multicast MANET protocol framework based = on previous work and lessons learned for scoped forwarding within MANET net= works. As part of this framework the WG will produce a well defined MANET = multicast forwarding information base. > > > > The WG will produce an informational draft outlining challenges and best = practices for deploying and managing MANET networks. > > > > The MANET WG will interact with the PIM working group on issues relating = to the multicast work. The WG will also pay attention to other IETF and IR= TF work that is addressing topics related to MANET environments. > > > > In summary, the WG will develop the following drafts: > > > > (JWD MANET Management Document is removed as the requirement for producin= g the document is no longer valid but the working group may work on this if= there is interest) > > MANET Maintenance > > - DLEP multiple flow extensions (JWD updated item) > > (JWD RFC5444 Security Extensions document has been removed as a delivera= ble but may still be worked upon under the auspices of MANET maintenance.) > > MANET Multicast > > - Multicast FIB (Standards) > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > -- > > James Nguyen > Email: james.huy.nguyen@gmail.com > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11343b784af9250532a7358c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 12, 2016 at 11:50 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Can you expand on the lat= ter?


Ditto. I'm = interested in this as well, depending on the scenario.

=
Regards,
Stan
=C2=A0

=C2=A0

(I started writing my tho= ughts, but decided just to ask. Except my thoughts run to scenarios, which = already work, which need new work?)

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: James Nguyen [mailto:james.huy.nguyen@gmail.com]
Sent: 12 May 2016 16:43
To: Dearlove, Christopher (UK)
Cc: Justin Dean; manet@ietf.org
Subject: Re: [manet] Updated after meeting Draft Recharter=

=C2=A0

=C2=A0

*** WARNING ***<= /b>

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.=

=C2=A0

=C2=A0

On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christop= her (UK) <chris.dearlove@baesystems.com> wrote:

As you know I had to duck= out early, and you were gone when I came back.

=C2=A0

Also not for a specific i= tem, but I presume would be permitted, is if anyone decided to work on conc= epts such as hierarchical or hybrid developments of OLSRv2. Someone actually me= ntioned one of those recently, but I=E2=80=99m not aware of anyone actively= pushing one. But in case they did, I presume would be allowed.

=C2=A0

+1

I'm interested in= hierarchical OLSRv2 deployment.=C2=A0 In addition, I'm also interested= how to make OLSRv2 networks interoperable with other non-OLSRv2 networks.= =C2=A0

James
=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)12= 45 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: manet [mailto:manet-= bounces@ietf.org] On Behalf Of Justin Dean
Sent: 12 May 2016 15:57
To: manet@ietf.o= rg
Subject: [manet] Updated after meeting Draft Recharter=

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachme= nts or reply.
For information regarding Red Flags that you can look out for in emai= ls you receive, click here.
If you feel the email is suspicious, please follow this process.

***= WARNING ***
EXTERNAL EMAIL -- This message originates from outside ou= r organization.

=C2=A0

Thanks to everyone who was able to participate in the voice chat =
today regarding the recharter.=C2=A0 Below is an updated draft charter base=
d upon discussions had in the chat.=C2=A0 I've also included inline com=
ments with (JWD ...) which of course will be removed when officially adopti=
ng the draft.=C2=A0 If something is missing or misrepresented please provid=
e feedback on the list so we may adjust it and update it accordingly.=C2=A0=
 The plan is to present the charter to Alvaro for adoption to be completed =
before the next IETF meeting so get your comments in ASAP.=

=C2=A0
=C2=A0
DRAFT CHARTER
=C2=A0
The purpose of the MANET working group is =
to standardize IP routing protocol functionality suitable for wireless rout=
ing application within both static and dynamic topologies with increased dy=
namics due to node motion or other factors.=C2=A0 

=C2=A0


Approaches are intended to be relatively l=
ightweight in nature, suitable for multiple hardware and wireless environme=
nts, and address scenarios where MANETs are deployed at the edges of an IP =
infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and m=
obile routers) should also be supported by MANET specifications and managem=
ent features.


=C2=A0


The MANET WG is responsible for the mainte=
nance of RFC5444, NHDP, OLSRv2, and DLEP. Of possible particular interest:=
=C2=A0type extensions for DLEP, security enhancements for RFC5=
444/NHDP/OLSRv2, best practices for MANET deployment/management,=C2=A0sourc=
e specific extensions for OLSRv2, and import/export of routing state for NH=
DP/OLSRv2.=C2=A0 


(JWD these are not promised deliverable items and we may want to =
remove them and just go with maintenance without listing them, also please =
correct me if I misrepresented the work talked about in the webex meeting h=
ead on May 12th)


The MANET WG will standardize a multicast MANET protocol framewor=
k based on previous work and lessons learned for scoped forwarding within M=
ANET networks.=C2=A0 As part of this framework the WG will produce a well d=
efined MANET multicast forwarding information base.

=C2=A0


The WG will produce an informational draft=
 outlining challenges and best practices for deploying and managing MANET n=
etworks. 


=C2=A0


The MANET WG will interact with the PIM wo=
rking group on issues relating to the multicast work.=C2=A0 The WG will als=
o pay attention to other IETF and IRTF work that is addressing topics relat=
ed to MANET environments.


=C2=A0


In summary, the WG will develop the follow=
ing drafts:


=C2=A0


(JWD MANET Management Document is removed as the requirement for=
 producing the document is no longer valid but the working group may work o=
n this if there is interest)


MANET Maintenance=C2=A0


 - DLEP mult=
iple flow extensions (JWD updated item)


 (JWD RFC5444 Security Extensions document has been removed as a =
deliverable but may still be worked upon under the auspices of MANET mainte=
nance.)


MANET Multicast


=C2=A0 - Mul=
ticast FIB (Standards)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************=


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




--

James Nguyen
Email: jame= s.huy.nguyen@gmail.com


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a11343b784af9250532a7358c-- From nobody Thu May 12 09:04:58 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D530C12D10C for ; Thu, 12 May 2016 09:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHMgGvLhM0dc for ; Thu, 12 May 2016 09:04:52 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B123F12D09E for ; Thu, 12 May 2016 09:04:52 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id lr7so57792164igb.1 for ; Thu, 12 May 2016 09:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lGHR5dTYrDr8Ri1pLbx3cPCWJn5+47oDNWbn9+VP/LE=; b=dRpAG/niOIKwU31oVhDE+zVV81czM1Lp8H48e9YXJFRLiSrIl3cI1tN9ok+kmMu2IM 6ZCl3yM41qhDAMarHRBNt+vayZeGqbpwH+oc+F+RnEa2zzzBRlP5flnghRdYiK5hJ6pS PZjLk4lJTdUCx+aplXa+w/TgWGg4FnIkhcOyicGoyTTgYdxyPcYJ1z/2QkYr6JMv8wBv CEg1LFCZ78Nh12NiYOHWsmV3Jmhh1O1XeNUnlZlQ9yj5kbchEIzOOUwuuoT0zNW6XUTn NFbkG2tOzUWYLbCHJ0G9kK4WK3cuYdOktt+1Mrwy+FpGSA3PWe6r058CFdsC5HetndRq 58tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lGHR5dTYrDr8Ri1pLbx3cPCWJn5+47oDNWbn9+VP/LE=; b=laptFFCi6fsUg7vrZuvZSpN8aUOHz+qgjgOLVmFXnKpMSbOQJXBlgRRyNuNCDqsm1j +rNNDKLjwFiSV4h7q1lKIrKAY3a/pspSBOcvKAFObUfwySivuUE96vkamea1MApxJ3EM UNtbtoZa3LGwtDw+VsBLpkdzd+bpunfxSCXSV/1aB+r2sVJVOkm0AhOaHj4sTW72HbMV a23ZvF4CkDPBflsy8WBZv9iIVAFMTa5uL4mFMRNEz0oVsTTEuhUg3B9zEB937168b+ou mJ28qJVKhMCJpJd2QSqEmPWzXheFSJP6rUdPrLDZhBP6ShOe1QYCvTOPEV+kHeRh2jy/ QJcw== X-Gm-Message-State: AOPr4FV7LoPKg2fJ8lDQ3MRtNUbzSGzLlhQ+VJvq5O2A7p0bTgUSwSKhxVQtAIgRXFuUktUf92qS9HaiKvc47Q== MIME-Version: 1.0 X-Received: by 10.50.150.42 with SMTP id uf10mr28063278igb.95.1463069092004; Thu, 12 May 2016 09:04:52 -0700 (PDT) Received: by 10.79.30.196 with HTTP; Thu, 12 May 2016 09:04:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 12:04:51 -0400 Message-ID: From: James Nguyen To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a1134cff282cfba0532a75158 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Updated after meeting Draft Recharter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 16:04:56 -0000 --001a1134cff282cfba0532a75158 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 12, 2016 at 11:50 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Can you expand on the latter? > > > > (I started writing my thoughts, but decided just to ask. Except my > thoughts run to scenarios, which already work, which need new work?) > > > > You could take coalition force communication as an example. If Force A runs OLSRv2 and Force B runs any other non-OLSRv2 protocol, I'm interested in making them interoperable. Another case, natural disaster's search and rescue mission, how can we help the law enforcement and the military to communicate well with each other? > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > *From:* James Nguyen [mailto:james.huy.nguyen@gmail.com] > *Sent:* 12 May 2016 16:43 > *To:* Dearlove, Christopher (UK) > *Cc:* Justin Dean; manet@ietf.org > *Subject:* Re: [manet] Updated after meeting Draft Recharter > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > > > > > On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > As you know I had to duck out early, and you were gone when I came back. > > > > Also not for a specific item, but I presume would be permitted, is if > anyone decided to work on concepts such as hierarchical or hybrid > developments of OLSRv2. Someone actually mentioned one of those recently, > but I=E2=80=99m not aware of anyone actively pushing one. But in case the= y did, I > presume would be allowed. > > > > +1 > > I'm interested in hierarchical OLSRv2 deployment. In addition, I'm also > interested how to make OLSRv2 networks interoperable with other non-OLSRv= 2 > networks. > > James > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean > *Sent:* 12 May 2016 15:57 > *To:* manet@ietf.org > *Subject:* [manet] Updated after meeting Draft Recharter > > > > > > **** WARNING **** > > > > *This message originates from outside our organisation, either from an > external partner or the internet. Consider carefully whether you should > click on any links, open any attachments or reply. For information > regarding **Red Flags* > * that you can look out for in emails you receive, click here > . > If you feel the email is suspicious, please follow this process > .* > > **** **WARNING ****** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > Thanks to everyone who was able to participate in the voice chat today re= garding the recharter. Below is an updated draft charter based upon discus= sions had in the chat. I've also included inline comments with (JWD ...) w= hich of course will be removed when officially adopting the draft. If some= thing is missing or misrepresented please provide feedback on the list so w= e may adjust it and update it accordingly. The plan is to present the char= ter to Alvaro for adoption to be completed before the next IETF meeting so = get your comments in ASAP. > > > > > > DRAFT CHARTER > > > > The purpose of the MANET working group is to standardize IP routing proto= col functionality suitable for wireless routing application within both sta= tic and dynamic topologies with increased dynamics due to node motion or ot= her factors. > > > > Approaches are intended to be relatively lightweight in nature, suitable = for multiple hardware and wireless environments, and address scenarios wher= e MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh inf= rastructures (e.g., a mixture of fixed and mobile routers) should also be s= upported by MANET specifications and management features. > > > > The MANET WG is responsible for the maintenance of RFC5444, NHDP, OLSRv2,= and DLEP. Of possible particular interest: type extensions for DLEP, secur= ity enhancements for RFC5444/NHDP/OLSRv2, best practices for MANET deployme= nt/management, source specific extensions for OLSRv2, and import/export of = routing state for NHDP/OLSRv2. > > (JWD these are not promised deliverable items and we may want to remove t= hem and just go with maintenance without listing them, also please correct = me if I misrepresented the work talked about in the webex meeting head on M= ay 12th) > > The MANET WG will standardize a multicast MANET protocol framework based = on previous work and lessons learned for scoped forwarding within MANET net= works. As part of this framework the WG will produce a well defined MANET = multicast forwarding information base. > > > > The WG will produce an informational draft outlining challenges and best = practices for deploying and managing MANET networks. > > > > The MANET WG will interact with the PIM working group on issues relating = to the multicast work. The WG will also pay attention to other IETF and IR= TF work that is addressing topics related to MANET environments. > > > > In summary, the WG will develop the following drafts: > > > > (JWD MANET Management Document is removed as the requirement for producin= g the document is no longer valid but the working group may work on this if= there is interest) > > MANET Maintenance > > - DLEP multiple flow extensions (JWD updated item) > > (JWD RFC5444 Security Extensions document has been removed as a delivera= ble but may still be worked upon under the auspices of MANET maintenance.) > > MANET Multicast > > - Multicast FIB (Standards) > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > -- > > James Nguyen > Email: james.huy.nguyen@gmail.com > --=20 James Nguyen Email: james.huy.nguyen@gmail.com --001a1134cff282cfba0532a75158 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 12, 2016 at 11:50 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Can you expand on the lat= ter?

=C2=A0

(I started writing my tho= ughts, but decided just to ask. Except my thoughts run to scenarios, which = already work, which need new work?)

=C2=A0

<= /span>
> You could take coalition force com= munication as an example.=C2=A0 If Force A runs OLSRv2 and Force B runs any= other non-OLSRv2 protocol, I'm interested in making them interoperable= .=C2=A0

Another case, natural disaster's search and = rescue mission, how can we help the law enforcement and the military to com= municate well with each other?=C2=A0
=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: James Nguyen [mailto:james.huy.nguyen@gmail.com]
Sent: 12 May 2016 16:43
To: Dearlove, Christopher (UK)
Cc: Justin Dean; manet@ietf.org
Subject: Re: [manet] Updated after meeting Draft Recharter=

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments= or reply.
For= information regarding Red Flags that you can look out for in emails you receive, click here.
If = you feel the email is suspicious, please follow this process.<= /u>

=C2=A0

=C2=A0

On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christop= her (UK) <chris.dearlove@baesystems.com> wrote:

As you know I had to duck= out early, and you were gone when I came back.

=C2=A0

Also not for a specific i= tem, but I presume would be permitted, is if anyone decided to work on conc= epts such as hierarchical or hybrid developments of OLSRv2. Someone actually me= ntioned one of those recently, but I=E2=80=99m not aware of anyone actively= pushing one. But in case they did, I presume would be allowed.

=C2=A0

+1

I'm interested in= hierarchical OLSRv2 deployment.=C2=A0 In addition, I'm also interested= how to make OLSRv2 networks interoperable with other non-OLSRv2 networks.= =C2=A0

James
=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)12= 45 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: manet [mailto:manet-= bounces@ietf.org] On Behalf Of Justin Dean
Sent: 12 May 2016 15:57
To: manet@ietf.o= rg
Subject: [manet] Updated after meeting Draft Recharter=

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachme= nts or reply.
For information regarding Red Flags that you can look out for in emai= ls you receive, click here.
If you feel the email is suspicious, please follow this process.

***= WARNING ***
EXTERNAL EMAIL -- This message originates from outside ou= r organization.

=C2=A0

Thanks to everyone who was able to participate in the voice chat =
today regarding the recharter.=C2=A0 Below is an updated draft charter base=
d upon discussions had in the chat.=C2=A0 I've also included inline com=
ments with (JWD ...) which of course will be removed when officially adopti=
ng the draft.=C2=A0 If something is missing or misrepresented please provid=
e feedback on the list so we may adjust it and update it accordingly.=C2=A0=
 The plan is to present the charter to Alvaro for adoption to be completed =
before the next IETF meeting so get your comments in ASAP.=

=C2=A0
=C2=A0
DRAFT CHARTER
=C2=A0
The purpose of the MANET working group is =
to standardize IP routing protocol functionality suitable for wireless rout=
ing application within both static and dynamic topologies with increased dy=
namics due to node motion or other factors.=C2=A0 

=C2=A0


Approaches are intended to be relatively l=
ightweight in nature, suitable for multiple hardware and wireless environme=
nts, and address scenarios where MANETs are deployed at the edges of an IP =
infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and m=
obile routers) should also be supported by MANET specifications and managem=
ent features.


=C2=A0


The MANET WG is responsible for the mainte=
nance of RFC5444, NHDP, OLSRv2, and DLEP. Of possible particular interest:=
=C2=A0type extensions for DLEP, security enhancements for RFC5=
444/NHDP/OLSRv2, best practices for MANET deployment/management,=C2=A0sourc=
e specific extensions for OLSRv2, and import/export of routing state for NH=
DP/OLSRv2.=C2=A0 


(JWD these are not promised deliverable items and we may want to =
remove them and just go with maintenance without listing them, also please =
correct me if I misrepresented the work talked about in the webex meeting h=
ead on May 12th)


The MANET WG will standardize a multicast MANET protocol framewor=
k based on previous work and lessons learned for scoped forwarding within M=
ANET networks.=C2=A0 As part of this framework the WG will produce a well d=
efined MANET multicast forwarding information base.

=C2=A0


The WG will produce an informational draft=
 outlining challenges and best practices for deploying and managing MANET n=
etworks. 


=C2=A0


The MANET WG will interact with the PIM wo=
rking group on issues relating to the multicast work.=C2=A0 The WG will als=
o pay attention to other IETF and IRTF work that is addressing topics relat=
ed to MANET environments.


=C2=A0


In summary, the WG will develop the follow=
ing drafts:


=C2=A0


(JWD MANET Management Document is removed as the requirement for=
 producing the document is no longer valid but the working group may work o=
n this if there is interest)


MANET Maintenance=C2=A0


 - DLEP mult=
iple flow extensions (JWD updated item)


 (JWD RFC5444 Security Extensions document has been removed as a =
deliverable but may still be worked upon under the auspices of MANET mainte=
nance.)


MANET Multicast


=C2=A0 - Mul=
ticast FIB (Standards)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************=


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




--

James Nguyen
Email: jame= s.huy.nguyen@gmail.com




--
James Nguyen
Email: james.huy.nguyen@gmail.com
--001a1134cff282cfba0532a75158-- From nobody Thu May 12 09:32:08 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110AB12D1CD for ; Thu, 12 May 2016 09:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoeEQVJMl6JZ for ; Thu, 12 May 2016 09:32:03 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97AAA12D676 for ; Thu, 12 May 2016 09:32:01 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id 190so101872298iow.1 for ; Thu, 12 May 2016 09:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kIF6cgFLjgyp9/WFkcBDt0OHz6r2jRcos7Ya2PUMixM=; b=nov9uE+8FzZcTMWl/GJ6oTAr+VXaQyjVzCU4PXggV+FdT24cnP58uRP81dHLtiFLLq qORR61O7aIJsx3/HWOBqbERcBl2pp/QtYmgV4JZ3Vtnfe5lRmDoa0Gh/XEvZFJxKKjZb TNGkKsNUNgg/tsdqvq0yUuRzf/oyloCAyeOxwSg92lPI11GnUrPcSz0GBS1vWnd+iRvd i1soIb8v1GHH+9QP3ZNfLE1Dtxa3scrprxhqM6E8kiLIq5xEySPb8LXphtJPLsNHny7f gHtYNHHqL1kotOG3cHMkyVIoBf3lzbS/QTdziVvrITWdzF0j4Vv3tKMXMQAvmB8LWeJu 2fdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kIF6cgFLjgyp9/WFkcBDt0OHz6r2jRcos7Ya2PUMixM=; b=BrM9WDlCFqSCSyVKD7NGjvWBKbtdUL11UPplcHH/BdyOZrrtqyrZOYWencj6qEJa5z JXdZSe/mkK4F/YJwx09O7ZRcQv4eoh9fOpRTHfq8h42+FGVrZXYhOyHqrz4VxpsWJGvP f3VtVu4UiyKKW926vsqgizVQ/rICOIazV8Mx7eRroJh0fpOg2PR+7vc6PoDSbEIrxeAn yrhOMLoituiXK9BT0UttwWzUZ1yzui5jPwJdhNy9A/ZKnbGAd8+8gfeO0SD52KlPr609 OrmoHIc5wm9hvfWlYLFrn3/fgMBv/YeZe0eygQ1uZuYGv8Oojp80Pi20SB/XRa6epbrk AShg== X-Gm-Message-State: AOPr4FX86BsVCbwIc4Ju3CGu6Xhk6DQ5cNxCUPxe/GPzF0SaOG19vM0mRG5D33S7ecra6Q6LmYN20bXYjCjXWQ== MIME-Version: 1.0 X-Received: by 10.36.83.20 with SMTP id n20mr7655639itb.61.1463070720934; Thu, 12 May 2016 09:32:00 -0700 (PDT) Received: by 10.79.72.134 with HTTP; Thu, 12 May 2016 09:32:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 12:32:00 -0400 Message-ID: From: Stan Ratliff To: James Nguyen Content-Type: multipart/alternative; boundary=001a114195e29a730d0532a7b282 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Updated after meeting Draft Recharter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 16:32:06 -0000 --001a114195e29a730d0532a7b282 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 12, 2016 at 12:04 PM, James Nguyen wrote: > > > On Thu, May 12, 2016 at 11:50 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > >> Can you expand on the latter? >> >> >> >> (I started writing my thoughts, but decided just to ask. Except my >> thoughts run to scenarios, which already work, which need new work?) >> >> >> > > You could take coalition force communication as an example. If Force A > runs OLSRv2 and Force B runs any other non-OLSRv2 protocol, I'm intereste= d > in making them interoperable. > Provided Force A is in one general locale, and Force B is in another, with some finite number of pre-defined gateway points, I think that already works. My interest is in environments where, due to mobility, the connectivity of the two routing protocols in play overlaps, and/or in cases where one protocol might be asked to carry traffic for the other (e.g., Force A gets dispersed to either side of a very wide formation, with Force B in the middle - Can B carry A's traffic?). The usual answer given in cases like this is to exploit route redistribution - each protocol takes the other's routes as external. In mobile scenarios, there's a whole host of problems associated with that. It quickly gets to a "boiling the ocean" scenario, so I wonder if there's an approach to bound at least part of the problem in order to focus on it and get a resolution. Regards, Stan > > Another case, natural disaster's search and rescue mission, how can we > help the law enforcement and the military to communicate well with each > other? > > >> *-- * >> >> >> >> >> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied >> Intelligence Laboratories * >> *_______________________________________________________________________= ___ >> * >> *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com >> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great >> Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >> >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >> >> >> >> *From:* James Nguyen [mailto:james.huy.nguyen@gmail.com] >> *Sent:* 12 May 2016 16:43 >> *To:* Dearlove, Christopher (UK) >> *Cc:* Justin Dean; manet@ietf.org >> *Subject:* Re: [manet] Updated after meeting Draft Recharter >> >> >> >> >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.* >> >> * Consider carefully whether you should click on any links, open any >> attachments or reply. For information regarding **Red Flags** that you >> can look out for in emails you receive, click here >> .* >> * If you feel the email is suspicious, please follow this process >> .* >> >> >> >> >> >> On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> wrote: >> >> As you know I had to duck out early, and you were gone when I came back. >> >> >> >> Also not for a specific item, but I presume would be permitted, is if >> anyone decided to work on concepts such as hierarchical or hybrid >> developments of OLSRv2. Someone actually mentioned one of those recently= , >> but I=E2=80=99m not aware of anyone actively pushing one. But in case th= ey did, I >> presume would be allowed. >> >> >> >> +1 >> >> I'm interested in hierarchical OLSRv2 deployment. In addition, I'm also >> interested how to make OLSRv2 networks interoperable with other non-OLSR= v2 >> networks. >> >> James >> >> >> *-- * >> >> >> >> >> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied >> Intelligence Laboratories * >> *_______________________________________________________________________= ___ >> * >> *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com >> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great >> Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >> >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >> >> >> >> *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean >> *Sent:* 12 May 2016 15:57 >> *To:* manet@ietf.org >> *Subject:* [manet] Updated after meeting Draft Recharter >> >> >> >> >> >> **** WARNING **** >> >> >> >> *This message originates from outside our organisation, either from an >> external partner or the internet. Consider carefully whether you should >> click on any links, open any attachments or reply. For information >> regarding **Red Flags* >> * that you can look out for in emails you receive, click here >> . >> If you feel the email is suspicious, please follow this process >> .* >> >> **** **WARNING ****** >> EXTERNAL EMAIL -- This message originates from outside our organization. >> >> >> >> Thanks to everyone who was able to participate in the voice chat today r= egarding the recharter. Below is an updated draft charter based upon discu= ssions had in the chat. I've also included inline comments with (JWD ...) = which of course will be removed when officially adopting the draft. If som= ething is missing or misrepresented please provide feedback on the list so = we may adjust it and update it accordingly. The plan is to present the cha= rter to Alvaro for adoption to be completed before the next IETF meeting so= get your comments in ASAP. >> >> >> >> >> >> DRAFT CHARTER >> >> >> >> The purpose of the MANET working group is to standardize IP routing prot= ocol functionality suitable for wireless routing application within both st= atic and dynamic topologies with increased dynamics due to node motion or o= ther factors. >> >> >> >> Approaches are intended to be relatively lightweight in nature, suitable= for multiple hardware and wireless environments, and address scenarios whe= re MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh in= frastructures (e.g., a mixture of fixed and mobile routers) should also be = supported by MANET specifications and management features. >> >> >> >> The MANET WG is responsible for the maintenance of RFC5444, NHDP, OLSRv2= , and DLEP. Of possible particular interest: type extensions for DLEP, secu= rity enhancements for RFC5444/NHDP/OLSRv2, best practices for MANET deploym= ent/management, source specific extensions for OLSRv2, and import/export of= routing state for NHDP/OLSRv2. >> >> (JWD these are not promised deliverable items and we may want to remove = them and just go with maintenance without listing them, also please correct= me if I misrepresented the work talked about in the webex meeting head on = May 12th) >> >> The MANET WG will standardize a multicast MANET protocol framework based= on previous work and lessons learned for scoped forwarding within MANET ne= tworks. As part of this framework the WG will produce a well defined MANET= multicast forwarding information base. >> >> >> >> The WG will produce an informational draft outlining challenges and best= practices for deploying and managing MANET networks. >> >> >> >> The MANET WG will interact with the PIM working group on issues relating= to the multicast work. The WG will also pay attention to other IETF and I= RTF work that is addressing topics related to MANET environments. >> >> >> >> In summary, the WG will develop the following drafts: >> >> >> >> (JWD MANET Management Document is removed as the requirement for produci= ng the document is no longer valid but the working group may work on this i= f there is interest) >> >> MANET Maintenance >> >> - DLEP multiple flow extensions (JWD updated item) >> >> (JWD RFC5444 Security Extensions document has been removed as a deliver= able but may still be worked upon under the auspices of MANET maintenance.) >> >> MANET Multicast >> >> - Multicast FIB (Standards) >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> >> -- >> >> James Nguyen >> Email: james.huy.nguyen@gmail.com >> > > > > -- > James Nguyen > Email: james.huy.nguyen@gmail.com > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a114195e29a730d0532a7b282 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 12, 2016 at 12:04 PM, James Nguyen <james.huy.ngu= yen@gmail.com> wrote:


O= n Thu, May 12, 2016 at 11:50 AM, Dearlove, Christopher (UK) <c= hris.dearlove@baesystems.com> wrote:

Can you expand on the lat= ter?

=C2=A0

(I started writing my tho= ughts, but decided just to ask. Except my thoughts run to scenarios, which = already work, which need new work?)

=C2=A0

<= /span>
> You could take coalition force com= munication as an example.=C2=A0 If Force A runs OLSRv2 and Force B runs any= other non-OLSRv2 protocol, I'm interested in making them interoperable= .=C2=A0

Provid= ed Force A is in one general locale, and Force B is in another, with some f= inite number of pre-defined gateway points, I think that already works. My = interest is in environments where, due to mobility, the connectivity of the= two routing protocols in play overlaps, and/or in cases where one protocol= might be asked to carry traffic for the other (e.g., Force A gets disperse= d to either side of a very wide formation, with Force B in the middle - Can= B carry A's traffic?).=C2=A0

The usual answer= given in cases like this is to exploit route redistribution - each protoco= l takes the other's routes as external. In mobile scenarios, there'= s a whole host of problems associated with that. It quickly gets to a "= ;boiling the ocean" scenario, so I wonder if there's an approach t= o bound at least part of the problem in order to focus on it and get a reso= lution.=C2=A0

Regards,
Stan
=C2=A0

Ano= ther case, natural disaster's search and rescue mission, how can we hel= p the law enforcement and the military to communicate well with each other?= =C2=A0
=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: James Nguyen [mailto:james.huy.nguyen@gmail.com]
Sent: 12 May 2016 16:43
To: Dearlove, Christopher (UK)
Cc: Justin Dean; manet@ietf.org
Subject: Re: [manet] Updated after meeting Draft Recharter=

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments= or reply.
For= information regarding Red Flags that you can look out for in emails you receive, click here.
If = you feel the email is suspicious, please follow this process.<= /u>

=C2=A0

=C2=A0

On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christop= her (UK) <chris.dearlove@baesystems.com> wrote:

As you know I had to duck= out early, and you were gone when I came back.

=C2=A0

Also not for a specific i= tem, but I presume would be permitted, is if anyone decided to work on conc= epts such as hierarchical or hybrid developments of OLSRv2. Someone actually me= ntioned one of those recently, but I=E2=80=99m not aware of anyone actively= pushing one. But in case they did, I presume would be allowed.

=C2=A0

+1

I'm interested in= hierarchical OLSRv2 deployment.=C2=A0 In addition, I'm also interested= how to make OLSRv2 networks interoperable with other non-OLSRv2 networks.= =C2=A0

James
=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)12= 45 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: manet [mailto:manet-= bounces@ietf.org] On Behalf Of Justin Dean
Sent: 12 May 2016 15:57
To: manet@ietf.o= rg
Subject: [manet] Updated after meeting Draft Recharter=

=C2=A0

=C2=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachme= nts or reply.
For information regarding Red Flags that you can look out for in emai= ls you receive, click here.
If you feel the email is suspicious, please follow this process.

***= WARNING ***
EXTERNAL EMAIL -- This message originates from outside ou= r organization.

=C2=A0

Thanks to everyone who was able to participate in the voice chat =
today regarding the recharter.=C2=A0 Below is an updated draft charter base=
d upon discussions had in the chat.=C2=A0 I've also included inline com=
ments with (JWD ...) which of course will be removed when officially adopti=
ng the draft.=C2=A0 If something is missing or misrepresented please provid=
e feedback on the list so we may adjust it and update it accordingly.=C2=A0=
 The plan is to present the charter to Alvaro for adoption to be completed =
before the next IETF meeting so get your comments in ASAP.=

=C2=A0
=C2=A0
DRAFT CHARTER
=C2=A0
The purpose of the MANET working group is =
to standardize IP routing protocol functionality suitable for wireless rout=
ing application within both static and dynamic topologies with increased dy=
namics due to node motion or other factors.=C2=A0 

=C2=A0


Approaches are intended to be relatively l=
ightweight in nature, suitable for multiple hardware and wireless environme=
nts, and address scenarios where MANETs are deployed at the edges of an IP =
infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and m=
obile routers) should also be supported by MANET specifications and managem=
ent features.


=C2=A0


The MANET WG is responsible for the mainte=
nance of RFC5444, NHDP, OLSRv2, and DLEP. Of possible particular interest:=
=C2=A0type extensions for DLEP, security enhancements for RFC5=
444/NHDP/OLSRv2, best practices for MANET deployment/management,=C2=A0sourc=
e specific extensions for OLSRv2, and import/export of routing state for NH=
DP/OLSRv2.=C2=A0 


(JWD these are not promised deliverable items and we may want to =
remove them and just go with maintenance without listing them, also please =
correct me if I misrepresented the work talked about in the webex meeting h=
ead on May 12th)


The MANET WG will standardize a multicast MANET protocol framewor=
k based on previous work and lessons learned for scoped forwarding within M=
ANET networks.=C2=A0 As part of this framework the WG will produce a well d=
efined MANET multicast forwarding information base.

=C2=A0


The WG will produce an informational draft=
 outlining challenges and best practices for deploying and managing MANET n=
etworks. 


=C2=A0


The MANET WG will interact with the PIM wo=
rking group on issues relating to the multicast work.=C2=A0 The WG will als=
o pay attention to other IETF and IRTF work that is addressing topics relat=
ed to MANET environments.


=C2=A0


In summary, the WG will develop the follow=
ing drafts:


=C2=A0


(JWD MANET Management Document is removed as the requirement for=
 producing the document is no longer valid but the working group may work o=
n this if there is interest)


MANET Maintenance=C2=A0


 - DLEP mult=
iple flow extensions (JWD updated item)


 (JWD RFC5444 Security Extensions document has been removed as a =
deliverable but may still be worked upon under the auspices of MANET mainte=
nance.)


MANET Multicast


=C2=A0 - Mul=
ticast FIB (Standards)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************=


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




--

James Nguyen
Email: jame= s.huy.nguyen@gmail.com




--
James Nguyen
Email: james.huy.nguyen@g= mail.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a114195e29a730d0532a7b282-- From nobody Thu May 12 11:00:41 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F6512D1D2 for ; Thu, 12 May 2016 11:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bOsMrHVdomV for ; Thu, 12 May 2016 11:00:36 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE2E12D11F for ; Thu, 12 May 2016 11:00:36 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id g17so40868330wme.0 for ; Thu, 12 May 2016 11:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=b2s4nIDiadPk8h5H/PfXsQ1fVYgpHJ7pc7l6KHvBTEg=; b=0+EZQLuAcWvhb8djmfyvpmGrv4QChmRCPZBa7ekWb+yaNKfpnPSrGXj2QpY5n9Fbc2 Asz7Uw39i4PP+p20UIdblQDuXL5lwuEf6XslaWuDBR0DSDy0skdRM2dvJBCM4M9HVU8L 7PtdHWj0aIxOpyHjIffGKQgi/HLrtfZB1fAPQh+F/mEe64/xRb6IMah47Kk0xDf90s2p Q/oEeguwawC3jcKqyFb46axoy8+sSe3ciBs9Rz7mH3JaRS15LrCXUCjsaiTZhaHQngQw CzU9EBdBEqGtBLhgLWIXFf/4TbPgwAVNJGpp8dAjy1yCWgnD/+0ET+0sl+yXm7+BWa79 92IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=b2s4nIDiadPk8h5H/PfXsQ1fVYgpHJ7pc7l6KHvBTEg=; b=ScXz4//8Nlk7gmBzNl9VxMlwJVqOK4u0eUjS/iPsBv4SJdvBCzONLJoB6v1yyTkR3y PpgLOiiNM/OUz2r5gLey+JxLGytgA9tZPAaWW7PeJgkoKORkC4CGSjZuQlW/EtLvEvg/ aMfSu/HcN0S/5kGEAViLqp8Lqy0d8x+tuEuP+kEWUV1Yx1juessW2yAKx0rQgQRBlNN1 Fpd3dy3GrGAF+zOcCOx9GrIEzHz+/ghaQCoXfjuPqa5QzBQwOd1rzBZ2IIS/k6CKGJIB od0mO2oI51dTgq7gZY7L+Jt+ZwgHf9s/CXIoFL/wkde3rkj5f6OlmNC0gCjqCW2lHHCV 628A== X-Gm-Message-State: AOPr4FXlRBtCZ4B/dFCuYZl8RQ5Qm+qNpWiOiMTk6Md+w50NzNGczgdS24Dm1wjjHMKuGw== X-Received: by 10.28.139.75 with SMTP id n72mr3746525wmd.28.1463076034741; Thu, 12 May 2016 11:00:34 -0700 (PDT) Received: from [10.0.156.187] (82-132-217-51.dab.02.net. [82.132.217.51]) by smtp.gmail.com with ESMTPSA id d1sm14524445wjb.47.2016.05.12.11.00.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 11:00:33 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-3A979D36-1E90-4B9C-877A-23C86339AE51 Content-Transfer-Encoding: 7bit Message-Id: <44047035-05EC-40F8-BC41-10F6D95AB218@gmail.com> X-Mailer: iPhone Mail (13E238) From: Christopher Dearlove Date: Thu, 12 May 2016 19:00:28 +0100 To: James Nguyen Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Updated after meeting Draft Recharter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 18:00:39 -0000 --Apple-Mail-3A979D36-1E90-4B9C-877A-23C86339AE51 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I was thinking about a discussion at a lower level. Where are the packets go= ing, what's missing from the basic capabilities each has, assuming a gateway= between them. Which depends on questions like numbers of gateways, whether p= ackets can transit networks and so on. -- =20 Christopher Dearlove > On 12 May 2016, at 17:04, James Nguyen wrote:= >=20 >=20 >=20 >> On Thu, May 12, 2016 at 11:50 AM, Dearlove, Christopher (UK) wrote: >> Can you expand on the latter? >>=20 >> =20 >>=20 >> (I started writing my thoughts, but decided just to ask. Except my though= ts run to scenarios, which already work, which need new work?) >>=20 > > You could take coalition force communication as an example. If Force A r= uns OLSRv2 and Force B runs any other non-OLSRv2 protocol, I'm interested in= making them interoperable. =20 >=20 > Another case, natural disaster's search and rescue mission, how can we hel= p the law enforcement and the military to communicate well with each other? = =20 > =20 >> -- >>=20 >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> _________________________________________________________________________= _ >>=20 >> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>=20 >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddo= w, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >>=20 >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >>=20 >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>=20 >> =20 >>=20 >> From: James Nguyen [mailto:james.huy.nguyen@gmail.com]=20 >> Sent: 12 May 2016 16:43 >> To: Dearlove, Christopher (UK) >> Cc: Justin Dean; manet@ietf.org >> Subject: Re: [manet] Updated after meeting Draft Recharter >>=20 >> =20 >>=20 >> =20 >>=20 >> *** WARNING *** >>=20 >> This message originates from outside our organisation, either from an ext= ernal partner or the internet. >> Consider carefully whether you should click on any links, open any attach= ments or reply. >> For information regarding Red Flags that you can look out for in emails y= ou receive, click here. >> If you feel the email is suspicious, please follow this process. >>=20 >> =20 >>=20 >> =20 >>=20 >> On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christopher (UK) wrote: >>=20 >> As you know I had to duck out early, and you were gone when I came back. >>=20 >> =20 >>=20 >> Also not for a specific item, but I presume would be permitted, is if any= one decided to work on concepts such as hierarchical or hybrid developments o= f OLSRv2. Someone actually mentioned one of those recently, but I=E2=80=99m n= ot aware of anyone actively pushing one. But in case they did, I presume wou= ld be allowed. >>=20 >> =20 >>=20 >> +1 >>=20 >> I'm interested in hierarchical OLSRv2 deployment. In addition, I'm also i= nterested how to make OLSRv2 networks interoperable with other non-OLSRv2 ne= tworks.=20 >>=20 >> James >> =20 >>=20 >> -- >>=20 >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> _________________________________________________________________________= _ >>=20 >> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>=20 >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddo= w, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >>=20 >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >>=20 >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>=20 >> =20 >>=20 >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean >> Sent: 12 May 2016 15:57 >> To: manet@ietf.org >> Subject: [manet] Updated after meeting Draft Recharter >>=20 >> =20 >>=20 >> =20 >>=20 >> *** WARNING *** >>=20 >> This message originates from outside our organisation, either from an ext= ernal partner or the internet. >> Consider carefully whether you should click on any links, open any attach= ments or reply. >> For information regarding Red Flags that you can look out for in emails y= ou receive, click here. >> If you feel the email is suspicious, please follow this process. >>=20 >> *** WARNING *** >> EXTERNAL EMAIL -- This message originates from outside our organization. >>=20 >> =20 >>=20 >> Thanks to everyone who was able to participate in the voice chat today re= garding the recharter. Below is an updated draft charter based upon discuss= ions had in the chat. I've also included inline comments with (JWD ...) whi= ch of course will be removed when officially adopting the draft. If somethi= ng is missing or misrepresented please provide feedback on the list so we ma= y adjust it and update it accordingly. The plan is to present the charter t= o Alvaro for adoption to be completed before the next IETF meeting so get yo= ur comments in ASAP. >> =20 >> =20 >> DRAFT CHARTER >> =20 >> The purpose of the MANET working group is to standardize IP routing proto= col functionality suitable for wireless routing application within both stat= ic and dynamic topologies with increased dynamics due to node motion or othe= r factors. =20 >> =20 >> Approaches are intended to be relatively lightweight in nature, suitable f= or multiple hardware and wireless environments, and address scenarios where M= ANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrast= ructures (e.g., a mixture of fixed and mobile routers) should also be suppor= ted by MANET specifications and management features. >> =20 >> The MANET WG is responsible for the maintenance of RFC5444, NHDP, OLSRv2,= and DLEP. Of possible particular interest: type extensions for DLEP, securi= ty enhancements for RFC5444/NHDP/OLSRv2, best practices for MANET deployment= /management, source specific extensions for OLSRv2, and import/export of rou= ting state for NHDP/OLSRv2. =20 >> (JWD these are not promised deliverable items and we may want to remove t= hem and just go with maintenance without listing them, also please correct m= e if I misrepresented the work talked about in the webex meeting head on May= 12th) >> The MANET WG will standardize a multicast MANET protocol framework based o= n previous work and lessons learned for scoped forwarding within MANET netwo= rks. As part of this framework the WG will produce a well defined MANET mul= ticast forwarding information base. >> =20 >> The WG will produce an informational draft outlining challenges and best p= ractices for deploying and managing MANET networks.=20 >> =20 >> The MANET WG will interact with the PIM working group on issues relating t= o the multicast work. The WG will also pay attention to other IETF and IRTF= work that is addressing topics related to MANET environments. >> =20 >> In summary, the WG will develop the following drafts: >> =20 >> (JWD MANET Management Document is removed as the requirement for producin= g the document is no longer valid but the working group may work on this if t= here is interest) >> MANET Maintenance=20 >> - DLEP multiple flow extensions (JWD updated item) >> (JWD RFC5444 Security Extensions document has been removed as a delivera= ble but may still be worked upon under the auspices of MANET maintenance.) >> MANET Multicast >> - Multicast FIB (Standards) >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >>=20 >> -- >>=20 >> James Nguyen >> Email: james.huy.nguyen@gmail.com >>=20 >=20 >=20 >=20 > --=20 > James Nguyen > Email: james.huy.nguyen@gmail.com > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-3A979D36-1E90-4B9C-877A-23C86339AE51 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I was thinking about a discussion at a= lower level. Where are the packets going, what's missing from the basic cap= abilities each has, assuming a gateway between them. Which depends on questi= ons like numbers of gateways, whether packets can transit networks and so on= .

--  
Christopher Dearlove

On 12 May 20= 16, at 17:04, James Nguyen <james.huy.nguyen@gmail.com> wrote:



On Thu, May 12, 2016 at 11:50 AM, Dearlove, Christopher (UK) <= span dir=3D"ltr"><chris.dearlove@baesystems.com> wrote:

Can you expand on the latte= r?

 =

(I started writing my thoug= hts, but decided just to ask. Except my thoughts run to scenarios, which alr= eady work, which need new work?)

 

> You could take coalition force commun= ication as an example.  If Force A runs OLSRv2 and Force B runs any oth= er non-OLSRv2 protocol, I'm interested in making them interoperable.  <= br>
Another case, natural disaster's search and rescue mission= , how can we help the law enforcement and the military to communicate well w= ith each other? 
 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________= ____________________________________

T:  = +44 (0)1245 242194  |  E: chris= .dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 =

From:<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-ser= if"" lang=3D"EN-US"> James Nguyen [mailto:james.huy.nguyen@gmail.com]
Sent: 12 May 2016 16:43
To: Dearlove, Christopher (UK)
Cc: Justin Dean; = manet@ietf.org
Subject: Re: [manet] Updated after meeting Draft Recharter<= /u>

 

 

*** WARNING ***=

This message originates from outside our organisa= tion, either from an external partner or the internet.
Cons= ider carefully whether you should click on any links, open any attachments o= r reply.
For i= nformation regarding Red Flags that you can look out for in emails you receive, click here.
If y= ou feel the email is suspicious, please follow this process.

 

 

On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

As you know I had to duck o= ut early, and you were gone when I came back.

 =

Also not for a specific ite= m, but I presume would be permitted, is if anyone decided to work on concept= s such as hierarchical or hybrid developments of OLSRv2. Someone actually men= tioned one of those recently, but I=E2=80=99m not aware of anyone actively p= ushing one. But in case they did, I presume would be allowed.<= u>

 =

+1

I'm interested in hier= archical OLSRv2 deployment.  In addition, I'm also interested how to ma= ke OLSRv2 networks interoperable with other non-OLSRv2 networks. 

James
 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________= ____________________________________

T:  = +44 (0)1245 2= 42194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 =

From: manet [mailto:manet-b= ounces@ietf.org] On Behalf Of Justin Dean
Sent: 12 May 2016 15:57
To: manet@ietf.or= g
Subject: [manet] Updated after meeting Draft Recharter<= u>

 

 

*** WARNING ***

This message originates from outside our organisa= tion, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachmen= ts or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here.
If you feel the email is suspicious, please follow this process.

*** <= /b>WARNING ***
EXTERNAL EMAIL -- This message originates from outside our o= rganization.

 

Thanks to everyone who was able to participate in the voice chat to=
day regarding the recharter.  Below is an updated draft charter based u=
pon discussions had in the chat.  I've also included inline comments wi=
th (JWD ...) which of course will be removed when officially adopting the dr=
aft.  If something is missing or misrepresented please provide feedback=
 on the list so we may adjust it and update it accordingly.  The plan i=
s to present the charter to Alvaro for adoption to be completed before the n=
ext IETF meeting so get your comments in ASAP.
 
 
DRAFT CHARTER
 
The purpose of the MANET working group is t=
o standardize IP routing protocol functionality suitable for wireless routin=
g application within both static and dynamic topologies with increased dynam=
ics due to node motion or other factors.  
 
Approaches are intended to be relatively li=
ghtweight in nature, suitable for multiple hardware and wireless environment=
s, and address scenarios where MANETs are deployed at the edges of an IP inf=
rastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobil=
e routers) should also be supported by MANET specifications and management f=
eatures.
 
The MANET WG is responsible for the mainten=
ance of RFC5444, NHDP, OLSRv2, and DLEP. Of possible particular interest:&nb=
sp;type extensions for DLEP, security enhancements for RFC5444/N=
HDP/OLSRv2, best practices for MANET deployment/management, source spec=
ific extensions for OLSRv2, and import/export of routing state for NHDP/OLSR=
v2.  
(JWD these are not promised deliverable items and we may want to re=
move them and just go with maintenance without listing them, also please cor=
rect me if I misrepresented the work talked about in the webex meeting head o=
n May 12th)
The MANET WG will standardize a multicast MANET protocol framework b=
ased on previous work and lessons learned for scoped forwarding within MANET=
 networks.  As part of this framework the WG will produce a well define=
d MANET multicast forwarding information base.
 
The WG will produce an informational draft o=
utlining challenges and best practices for deploying and managing MANET netw=
orks. 
 
The MANET WG will interact with the PIM wor=
king group on issues relating to the multicast work.  The WG will also p=
ay attention to other IETF and IRTF work that is addressing topics related t=
o MANET environments.
 
In summary, the WG will develop the followi=
ng drafts:
 
(JWD MANET Management Document is removed as the requirement for p=
roducing the document is no longer valid but the working group may work on t=
his if there is interest)
MANET Maintenance 
 - DLEP multip=
le flow extensions (JWD updated item)
 (JWD RFC5444 Security Extensions document has been removed as a de=
liverable but may still be worked upon under the auspices of MANET maintenan=
ce.)
MANET Multicast
  - Multi=
cast FIB (Standards)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************<= u>


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet




--

James Nguyen
Email: james= .huy.nguyen@gmail.com




--
James Nguyen
Email: james.huy.nguyen@gmail.com
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-3A979D36-1E90-4B9C-877A-23C86339AE51-- From nobody Fri May 13 06:34:37 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CD512B051 for ; Fri, 13 May 2016 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inf-net-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvoHMoHIieYX for ; Fri, 13 May 2016 06:34:32 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5B412B03B for ; Fri, 13 May 2016 06:34:31 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a17so30689375wme.0 for ; Fri, 13 May 2016 06:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inf-net-nl.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=/02nQ8RFarLmtnCtO+U9Ubp9fkFBmHPnSoXCaSvtAx4=; b=OyAZgJ/vKZ/z6wKcHG3ugt7vUHkzhtb0tqhSGmwiTOOMazCVkoV3+pUAL/PDBq1INF iW2R7apZcJS1zLHd3sdvWx5ecdNfUQExGSXhlXVorj0xEPVQnl9H0Hk4v+Js/eGKR4c5 C8fc2Ms/TpPNSBbu0R4USN1buOTY+gdpX837M13xAuUnV34BwmjoffV3TmO/AxKwGVMy 4OyZN5hNBfi/emMw5TDZhgvSAFARt+bWSRWrVR0Nj9GvCJUkJFPnQMDn4igpOvjnubws IAhRo1vfhv/d7jwklY/kaW1YAL7lmvVv4uKW6MEYtv9hIJ0XA6oXlexy8Al2zDts8WyK poWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=/02nQ8RFarLmtnCtO+U9Ubp9fkFBmHPnSoXCaSvtAx4=; b=XOcDlxVHYFmT9HLBXUObGTTeEo8ahsJWaHTYhcEErD9rLVvsrdRs7vkvdvu1E0qqiz bx/TnZOG0rovh24+6JXIuYIKsCLEywUJ38GwtnHd7lFcbQiD2/KvbmD7BtLVUQI+MsRE 3zerzqnJKKT/SPwBfFOS4id22YJ4+2yQaJEka8DhRf/i7WlnuW1+1POYZJ1+auipA2/j w0tJn+/MaGETFt/0bxEHsxptrUjynx287i6TjQxX2n0yjOLGn1jvg9jB0uRNUEnuzN73 2Q87z7TbbzaGIJk2xsql0JMaZkLllqZ/wXTML5NUATaBacq9X/RGa0Mi1RnimEiZ7+fD WPnw== X-Gm-Message-State: AOPr4FXqrPLJOwlq4QGnxqkaVzQrsj5W2l0kOY2i/oY9EffL1w2tBh6IVWXylIjL6qfEcQ== X-Received: by 10.28.156.195 with SMTP id f186mr3727290wme.74.1463146469700; Fri, 13 May 2016 06:34:29 -0700 (PDT) Received: from [10.87.1.227] ([145.15.244.19]) by smtp.gmail.com with ESMTPSA id y70sm3343655wmd.3.2016.05.13.06.34.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 May 2016 06:34:28 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5F37F534-D401-4FF8-B2DD-76BEAA10C24E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Teco Boot In-Reply-To: <44047035-05EC-40F8-BC41-10F6D95AB218@gmail.com> Date: Fri, 13 May 2016 15:34:27 +0200 Message-Id: References: <44047035-05EC-40F8-BC41-10F6D95AB218@gmail.com> To: Christopher Dearlove X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "manet@ietf.org" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Updated after meeting Draft Recharter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 13:34:35 -0000 --Apple-Mail=_5F37F534-D401-4FF8-B2DD-76BEAA10C24E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My thoughts on interconnecting MANETs are: what can we do when we have = dst-src-routing in place? Teco > Op 12 mei 2016, om 20:00 heeft Christopher Dearlove = het volgende geschreven: >=20 > I was thinking about a discussion at a lower level. Where are the = packets going, what's missing from the basic capabilities each has, = assuming a gateway between them. Which depends on questions like numbers = of gateways, whether packets can transit networks and so on. >=20 > -- > Christopher Dearlove >=20 > On 12 May 2016, at 17:04, James Nguyen = wrote: >=20 >>=20 >>=20 >> On Thu, May 12, 2016 at 11:50 AM, Dearlove, Christopher (UK) = wrote: >> Can you expand on the latter? >>=20 >>=20 >>=20 >> (I started writing my thoughts, but decided just to ask. Except my = thoughts run to scenarios, which already work, which need new work?) >>=20 >>=20 >>=20 >> > You could take coalition force communication as an example. If = Force A runs OLSRv2 and Force B runs any other non-OLSRv2 protocol, I'm = interested in making them interoperable. >>=20 >> Another case, natural disaster's search and rescue mission, how can = we help the law enforcement and the military to communicate well with = each other? >>=20 >>=20 >> -- >>=20 >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> = __________________________________________________________________________= >>=20 >> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>=20 >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >>=20 >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >>=20 >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>=20 >>=20 >>=20 >> From: James Nguyen [mailto:james.huy.nguyen@gmail.com] >> Sent: 12 May 2016 16:43 >> To: Dearlove, Christopher (UK) >> Cc: Justin Dean; manet@ietf.org >> Subject: Re: [manet] Updated after meeting Draft Recharter >>=20 >>=20 >>=20 >>=20 >>=20 >> *** WARNING *** >>=20 >> This message originates from outside our organisation, either from an = external partner or the internet. >> Consider carefully whether you should click on any links, open any = attachments or reply. >> For information regarding Red Flags that you can look out for in = emails you receive, click here. >> If you feel the email is suspicious, please follow this process. >>=20 >>=20 >>=20 >>=20 >>=20 >> On Thu, May 12, 2016 at 11:20 AM, Dearlove, Christopher (UK) = wrote: >>=20 >> As you know I had to duck out early, and you were gone when I came = back. >>=20 >>=20 >>=20 >> Also not for a specific item, but I presume would be permitted, is if = anyone decided to work on concepts such as hierarchical or hybrid = developments of OLSRv2. Someone actually mentioned one of those = recently, but I=E2=80=99m not aware of anyone actively pushing one. But = in case they did, I presume would be allowed. >>=20 >>=20 >>=20 >> +1 >>=20 >> I'm interested in hierarchical OLSRv2 deployment. In addition, I'm = also interested how to make OLSRv2 networks interoperable with other = non-OLSRv2 networks. >>=20 >> James >>=20 >>=20 >> -- >>=20 >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> = __________________________________________________________________________= >>=20 >> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>=20 >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >>=20 >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >>=20 >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>=20 >>=20 >>=20 >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean >> Sent: 12 May 2016 15:57 >> To: manet@ietf.org >> Subject: [manet] Updated after meeting Draft Recharter >>=20 >>=20 >>=20 >>=20 >>=20 >> *** WARNING *** >>=20 >> This message originates from outside our organisation, either from an = external partner or the internet. >> Consider carefully whether you should click on any links, open any = attachments or reply. >> For information regarding Red Flags that you can look out for in = emails you receive, click here. >> If you feel the email is suspicious, please follow this process. >>=20 >> *** WARNING *** >> EXTERNAL EMAIL -- This message originates from outside our = organization. >>=20 >>=20 >>=20 >> Thanks to everyone who was able to participate in the voice chat = today regarding the recharter. Below is an updated draft charter based = upon discussions had in the chat. I've also included inline comments = with (JWD ...) which of course will be removed when officially adopting = the draft. If something is missing or misrepresented please provide = feedback on the list so we may adjust it and update it accordingly. The = plan is to present the charter to Alvaro for adoption to be completed = before the next IETF meeting so get your comments in ASAP. >>=20 >>=20 >> DRAFT CHARTER >>=20 >> The purpose of the MANET working group is to standardize IP routing = protocol functionality suitable for wireless routing application within = both static and dynamic topologies with increased dynamics due to node = motion or other factors. >>=20 >> Approaches are intended to be relatively lightweight in nature, = suitable for multiple hardware and wireless environments, and address = scenarios where MANETs are deployed at the edges of an IP = infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed = and mobile routers) should also be supported by MANET specifications and = management features. >>=20 >> The MANET WG is responsible for the maintenance of RFC5444, NHDP, = OLSRv2, and DLEP. Of possible particular interest: type extensions for = DLEP, security enhancements for RFC5444/NHDP/OLSRv2, best practices for = MANET deployment/management, source specific extensions for OLSRv2, and = import/export of routing state for NHDP/OLSRv2. >> (JWD these are not promised deliverable items and we may want to = remove them and just go with maintenance without listing them, also = please correct me if I misrepresented the work talked about in the webex = meeting head on May 12th) >> The MANET WG will standardize a multicast MANET protocol framework = based on previous work and lessons learned for scoped forwarding within = MANET networks. As part of this framework the WG will produce a well = defined MANET multicast forwarding information base. >>=20 >> The WG will produce an informational draft outlining challenges and = best practices for deploying and managing MANET networks. >>=20 >> The MANET WG will interact with the PIM working group on issues = relating to the multicast work. The WG will also pay attention to other = IETF and IRTF work that is addressing topics related to MANET = environments. >>=20 >> In summary, the WG will develop the following drafts: >>=20 >> (JWD MANET Management Document is removed as the requirement for = producing the document is no longer valid but the working group may work = on this if there is interest) >> MANET Maintenance >> - DLEP multiple flow extensions (JWD updated item) >> (JWD RFC5444 Security Extensions document has been removed as a = deliverable but may still be worked upon under the auspices of MANET = maintenance.) >> MANET Multicast >> - Multicast FIB (Standards) >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >>=20 >> -- >>=20 >> James Nguyen >> Email: james.huy.nguyen@gmail.com >>=20 >>=20 >>=20 >>=20 >> -- >> James Nguyen >> Email: james.huy.nguyen@gmail.com >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_5F37F534-D401-4FF8-B2DD-76BEAA10C24E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXNdfjAAoJECQbXIDdIQWqU+oP/1ZrFoJgLmbnU6zyOsRDxMBa rGfdp1GddJNn08rR9qyQlAUSjes6yN6qheYWwo95Ct/l0+Ckmy5qbqbvnz76tHjO ptFzYe+ZjtruIkhnnNgkQSJY9v91Vb1PDt0Nb73pIzedPiJubPiBNAUXZJVlS3nG m6Hit6v8Z0sQDex78VEPxWZnRv3no3kGP02tGQVf8SnY4AgVEgF+oceL8ALT+5M7 TQx0SI4NoqJz/ipZjtXlvZXED6C16xcVn8YTLqT9QOVRcSuCZrWUxqxqcIZL4yDL YUhnJ96hC+lqzv3OUjfb6WftAX1XvAm7BYoJ6RHiD8WMn/5nBF5QwwMAp6qWjo1i 5LX3+MSGP9WNix4WsSon79E6U38yyXDyvt8CWMHIsWn1pqs3XhmcFfgI8HqdrmWR 1h6nGoD/PvSxV8jcNGtnM8sY8wvnOIxUNOGtpSNVnpblWb/3Wb/QldRRO25EzkMV hKsSAA2AW79TemRLI0jbfEHnueO330U0Aqci7f2gaRYm1Y74azzNuq121y6ew0xa 9khRbI6tYufgyShBeSRvSIWq0yYYTpsWohbg2XUTVyQ/yy871yUuvsiB0eEOx7oX FqaAjVRBSMZsymB5Y/IK1LHlcv4XLBPwf6oituAyWat7ShF/gMtlAxHZDfljzt92 lm3Xm4/T2yaobKsArqiw =Ej2n -----END PGP SIGNATURE----- --Apple-Mail=_5F37F534-D401-4FF8-B2DD-76BEAA10C24E-- From nobody Fri May 13 08:53:21 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0DB12D5A5; Fri, 13 May 2016 08:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ4IEz410T9H; Fri, 13 May 2016 08:53:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DF912D187; Fri, 13 May 2016 08:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1366; q=dns/txt; s=iport; t=1463154795; x=1464364395; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=H/7XYZi+vByKmiPoVTBbVH3g9++3zHhfkUkirQKN/Uo=; b=h71bBv8Kpk45DGjWCj7ZyHoR9Bxn/p/man5UTYMhpkHJGsY0DEtxqgQP WJCfy9dyT7zHn73eBV+NDK4Gs48TofcHJyRbAaB6geklMqYj+iWXWoeab +uQscfikIwmu+znu+IeFxsUzWSMWEt0ncfPwL6K3uwdNayj2N+N3PlmWP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AAD19zVX/51dJa1EFwODN1V+BrlQA?= =?us-ascii?q?Q2BDQVkJIVtAoEsOBQBAQEBAQEBZSeEQwEBAgI6LCECAgEILAQGBgobFxsBBgI?= =?us-ascii?q?BAgEDARKILw4stHGLeAEBAQEBAQEBAQEBAQEBAQEBAQEBARwFhiCETYE5gncwJ?= =?us-ascii?q?geFCwWYJwGFfYVlgjuBaRc3hAGIYY9AAR4BAUKCBg0OgQBLbgGHWn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208";a="104048535" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2016 15:53:09 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u4DFr9Rk030040 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 15:53:09 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 May 2016 10:53:08 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Fri, 13 May 2016 10:53:09 -0500 From: "Alvaro Retana (aretana)" To: "roll@ietf.org" , "manet@ietf.org" Thread-Topic: ITS BOF Virtual Interim Meeting: May 31, 2016 Thread-Index: AQHRrKXjwfV0xiFjKkys13IvOeBLRp+3FoWA Date: Fri, 13 May 2016 15:53:09 +0000 Message-ID: References: <20160512232644.31516.82715.idtracker@ietfa.amsl.com> In-Reply-To: <20160512232644.31516.82715.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [manet] FW: ITS BOF Virtual Interim Meeting: May 31, 2016 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:53:17 -0000 FYI.. On 5/12/16, 7:26 PM, "IETF-Announce on behalf of IESG Secretary" wrote: >The Intelligent Transportation Systems (its) BOF will hold a virtual >interim meeting on May 31, 2016 at 1000 EDT (1400 UTC). > >ITS Virtual BOF Session >Tuesday, May 31, 2016 >10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr > >JOIN WEBEX MEETING >https://ietf.webex.com/ietf/j.php?MTID=3Dm6a2426507fd79ed99642514b3c75c149 >Meeting number: 644 158 525 >Meeting password: may31st > >JOIN BY PHONE >1-877-668-4493 Call-in toll free number (US/Canada) >1-650-479-3208 Call-in toll number (US/Canada) >Access code: 644 158 525 > >Toll-free dialing restrictions: >https://www.webex.com/pdf/tollfree_restrictions.pdf > >Add this meeting to your calendar (Cannot add from mobile devices): >https://ietf.webex.com/ietf/j.php?MTID=3Dm5f3d256232517f6c2e17acdeca317f3f > >Need help? Go to: >http://help.webex.com > >IMPORTANT NOTICE: Please note that this WebEx service allows audio and >other information sent during the session to be recorded, which may be >discoverable in a legal matter. By joining this session, you >automatically consent to such recordings. If you do not consent to being >recorded, discuss your concerns with the host or do not join the >session. > From nobody Thu May 19 00:39:56 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8407D12D0CD for ; Thu, 19 May 2016 00:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNWYi5SCi630 for ; Thu, 19 May 2016 00:39:52 -0700 (PDT) Received: from cse.ust.hk (cssvr7.cse.ust.hk [143.89.41.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E5312B03E for ; Thu, 19 May 2016 00:39:51 -0700 (PDT) Received: from imail.cse.ust.hk (cssvr7.cse.ust.hk [143.89.41.157]) by cse.ust.hk (8.15.2/8.12.5) with ESMTP id u4J7dmZn000546 for ; Thu, 19 May 2016 15:39:48 +0800 Received: from 175.159.122.110 (SquirrelMail authenticated user dcab) by imail.cse.ust.hk with HTTP; Thu, 19 May 2016 15:39:48 +0800 Message-ID: <39f0ab72fec96c906b79de1639ddc914.squirrel@imail.cse.ust.hk> Date: Thu, 19 May 2016 15:39:48 +0800 From: "CHATZOPOULOS Dimitrios" To: manet@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Env-From: dcab Archived-At: Subject: [manet] [Deadline extension] Extremecom 2016 - The Mendonoma Expedition - Call for Papers and Demos X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 07:39:54 -0000 [Apologies if you receive multiple copies of this CFP] ****************************************************************** CALL FOR PAPERS AND DEMOS 7th Extreme Conference on Communication and Computing - The Mendonoma Expedition ExtremeCom 2016 14-19 August 2016, Manchester, Medocino county, CA, USA http://www.extremecom.org/ ****************************************************************** Scope ----- The Extreme Conference on Communication and Computing (ExtremeCom) brings together researchers and practitioners in areas related to communications in rural, remote or other extreme environments, and computing in extreme operating conditions such as extreme temperatures and energy constraints, extreme quantities ("big data"), extremely large-scale systems, and extreme levels of threat and uncertainty, in order to gain experience and insight into the challenges that such environments pose for the network and the users. We welcome a broad range of topics concerning both technical and economical aspects, for example wireless communication, mobile computing, low power devices and protocols, delay tolerant networks and other networking paradigms, distributed computing paradigms, big data, distributed systems, cloud computing, business and services models, user experiences and web applications. Researches addressing computing challenges in general mobile environments (even not completely extreme) are also welcomed by the conference. Following on from the success of ExtremeCom 2009 - The Midnight Sun Expedition in Laponia, Sweden, ExtremeCom 2010 - The Himalayan Expedition in Dharamsala, India, ExtremeCom 2011 - The Amazon Expedition in Manaus, Brazil, ExtremeCom 2012 - The Swiss Alps Winter Expedition in Zurich, Switzerland, ExtremeCom 2013 - The Volcanic Expedition in the Eyjafjallajökull Volcano region in Iceland, and ExtremeCom 2014 - The Galapagos Expedition in Ecuador, we present the ExtremeCom 2016 edition: The Mendonoma Expedition. The conference will contain 3 days of excursions in the stunning nature of coastal northern California (Mendocino county). Along the way, participants will get to see and experience the varying landscape and visit coastal areas, explore the Stornetta lands national monument, and hike to the Point Arena hot springs along the Garcia river. During these excursions, we will visit the landing site of the original trans-pacific coaxial cables, which is today one of North-America's most important transoceanic fiber landing station, as well as several deployment sites of the FurtherReach.Net rural network where participants will interact with subscribers, operators and developers of this service to learn from their experience. The immersion will not only give a better idea of both the technical and user requirements of such rural deployments, but it will also give many opportunities for informal research discussions between the participants. Participants that have their own software for scenarios like this will also, to as great an extent as possible, be encouraged to test and demonstrate it within this environment. After the excursions, there will be two days of paper presentations and demos. Focus will still be on informal research discussions, with the hope that the field experience will give participants the ability to discuss the topics in a new light. ****************************************************************** Important dates --------------- Submission deadline: June 4, 2016 Notification of acceptance: June 15, 2016 Early registration deadline: July 10, 2016 Registration deadline: July 21, 2016 Conference dates: August 14-19, 2016 ****************************************************************** Submission Guidelines --------------------- Participants should submit 6 page papers about ideas and visions about the topics of the conference or demo proposals to be shown during the conference. Visionary and thought-provoking papers that are likely to generate much discussion during the conference are especially solicited. The aim of the conference is to maintain an informal environment, where new research ideas can be discussed and developed. We will also have a demo session where participants can show their implementations and systems. If you want to show a demo, please submit a 2 page demo proposal using the same submission system as for conference papers, including the prefix "Demo: " in the title. We only accept PDF files, no greater than 6 pages in length (2 pages for the demos), including text, figures and references. Manuscripts should use the ACM templates (for LaTeX, please use Option 2 files), with 9pt fonts. Topics for the conference include, but are not limited to: ---------------------------------------------------------- * Testbeds for large-scale sustainable testing of mobile communication systems * Real deployments of networks in extreme environments * Business and service models for networks in rural, remote, and other challenging environments * Delay tolerant networking * User experience research * Big data research such as mining and modeling of mobility and social network * Cloud computing for extreme scalability * Mesh networks and sensor networks * Low-power and intermittent-power protocols * Mechanisms for emergency and urgent communications * Distributed computing for mobile environments * Networked applications and services * Operating system and middleware support for mobile computing and networking * Security, privacy, and trustworthiness of extreme communications * Underwater networking * Robotic communications and mobile augmented reality * Protocols, architectures, and applications for the Internet of Things Due to logistics, the number of participants will be limited. Priority will be given to authors of papers and those who register first. ****************************************************************** Organizers ****************************************************************** General co-chairs: ------------------ Pan Hui, HKUST, Hong Kong Anders Lindgren, SICS Swedish ICT, Sweden Local organization: ------------------- Yahel Ben-David, De Novo Group, USA Gary Levenson-Palmer, USA Publicity and publication chair: -------------------------------- Dimitris Chatzopoulos, HKUST, Hong Kong Yang Chen, Fudan university, Shanghai, China Web chair: ---------- Dimitris Chatzopoulos, HKUST, Hong Kong Technical Program Committee: ---------------------------- Scott Burleigh, JPL/NASA, USA Elwyn Davies, Folly Consulting, UK Michael Doering, Bosch Research, Germany Marco Fiore, CNR, Italy Alfredo Goldman, University of California Irvine, USA Christine Julien, University of Texas at Austin, USA James Kwok, Hong Kong University of Science and Technology, Hong Kong Jörg Ott, TU Munich, Germany Zhonghong Ou, Aalto University, Finland Veljko Pejovic, University of Ljubljana, Slovenia Arjuna Sathiaseelan, University of Cambridge, UK Jan Seedorf, NEC Labs, Germany Yu Wang, University of North Carolina at Charlotte Klaus Wehrle, RWTH Aachen University, Germany Lars Wolf, TU Braunschweig, Germany Steering Committee: ------------------- Jon Crowcroft, University of Cambridge, UK Avri Doria, USA Tristan Henderson, University of St. Andrews, UK Pan Hui, HKUST, Hong Kong Anders Lindgren, SICS Swedish ICT, Sweden From nobody Sun May 22 22:26:23 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9A712D645; Sun, 22 May 2016 22:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUIjazYws80k; Sun, 22 May 2016 22:26:20 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2FE12D1A9; Sun, 22 May 2016 22:26:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 3A5122409F2; Sun, 22 May 2016 22:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1463981180; bh=UcetCbWFfp7D4cXsRUbbsY+BEDSjN8wOBMnfWKFKWDE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=dUZikyV8QCXEA7/Lm9uXCnlDFfdEo9ufA4n+ZBtDhUbmQ6Rfl1gufgc/z2Vpsxal8 zCeZ88NzWOg8dUDsEZ2PI4aWZJGFh0BohO4eKj2YmNCFQuXBETEktNtNnz6GFE1ARM YrY+mSeiDuRwYicDy07j+tiwKRRRP9pq84c+P9gs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.1.100] (bzq-79-177-185-189.red.bezeqint.net [79.177.185.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 5F72B24046B; Sun, 22 May 2016 22:26:19 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-83206CA4-F8D7-4024-AD26-E20DB036518B Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (13E238) In-Reply-To: Date: Mon, 23 May 2016 08:26:16 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <20160504170444.8256.99788.idtracker@ietfa.amsl.com> To: Justin Dean Archived-At: Cc: manet-ads@ietf.org, "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 05:26:22 -0000 --Apple-Mail-83206CA4-F8D7-4024-AD26-E20DB036518B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So, how did that conversation with Mr. Ratliff go? Unless I've missed a data= tracker notification, motion has grind to a halt regarding this doc? Thomas -- Thomas Heide Clausen =E2=80=A2 @thclausen =E2=80=A2 thomasclaus= en.org=20 www.arkko.com/tools/allstats/thomasheideclausen.html > On 05 May 2016, at 05:55, Justin Dean wrote: >=20 > Ack. I'll talk with Stan ASAP and keep things moving. >=20 > Justin >=20 >> On Wed, May 4, 2016 at 1:06 PM, Dearlove, Christopher (UK) wrote: >> This includes all of the issues I listed in my previous email of comments= made at WGLC. >>=20 >> The authors request starting all the post-WGLC things to do. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> _________________________________________________________________________= _ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-83206CA4-F8D7-4024-AD26-E20DB036518B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
So, how did that conversation with Mr.= Ratliff go? Unless I've missed a datatracker notification, motion has grind= to a halt regarding this doc?

On= 05 May 2016, at 05:55, Justin Dean <bebemaster@gmail.com> wrote:

Ack. I'll talk with Stan ASAP and keep things m= oving.

Justin

On Wed, May 4, 2016 at 1:06 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
This includes all of the issues I listed in my previous ema= il of comments made at WGLC.

The authors request starting all the post-WGLC things to do.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-83206CA4-F8D7-4024-AD26-E20DB036518B-- From nobody Mon May 23 05:55:25 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D7F12D85E for ; Mon, 23 May 2016 05:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.345 X-Spam-Level: X-Spam-Status: No, score=-8.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6u-8J52GTLN for ; Mon, 23 May 2016 05:55:21 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495E612D85C for ; Mon, 23 May 2016 05:55:20 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.26,355,1459810800"; d="scan'208,217"; a="72519511" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 23 May 2016 13:55:18 +0100 X-IronPort-AV: E=Sophos;i="5.26,355,1459810800"; d="scan'208,217";a="119261261" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 23 May 2016 13:55:17 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.168]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 23 May 2016 13:55:17 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: draft-ietf-manet-olsrv2-multipath-08 Thread-Index: AdG08hEGuTDPBDyTRIGr+M/qpuSsmg== Date: Mon, 23 May 2016 12:55:16 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B6B6CGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: [manet] draft-ietf-manet-olsrv2-multipath-08 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 12:55:23 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B6B6CGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Was away last week, but managed to read through and red-ink the multipath d= raft. I have some more detailed notes on it, but here - and all I'll get to= right now - are my headline comments. Editorially, if this came from the usual OLSRv2 authors, we'd be doing some= work to make it a better fit to the style of the rest of the OLSRv2 suite.= It's not bad, it just could be a bit better. For example what are listed a= s Information Bases aren't, they are Protocol Sets. Together they might for= m a new Information Base, or be added to one. And more. There are also various other points that I'd make. For example, it says not= just for hop count. Given that OLSRv2 is not just for hop count, I wouldn'= t emphasis this. And I don't know why MP-OLSRv2 is indicated as being suita= ble especially for low data rate links. Technically, my first issue is that OLSRv2 distributes a partial topology, = so this is working at a disadvantage. OK, but this isn't discussed, and - w= ith the one exception of picking MPRs - tradeoffs of the incompleteness of = the topology and overheads aren't even discussed. For a start, TC messages = contain advertised neighbours. Advertised neighbours must include all MPR s= electors, but may include more neighbours - up to all neighbours. I would e= xpect a discussion of this. (I'm also not actually sure how good the altern= ative MPR heuristics are, that's me needing to read and think more.) I've been critical of AODVv2 underspecifying interaction with IP. I'm going= to make the same criticism here, given the suggestion of a reactive multi-= path route determination. I'm actually not keen on that idea at all, I thin= k it needs more discussion. It also, I think, is broken in that there is no= indication of how and when these paths are expired. This alone I think req= uires a new draft. And before that discussion on whether a reactive mechani= sm that OLSRv2 otherwise doesn't have is acceptable. (I don't think it is.) I'm not as familiar as I should be with loose source routing. Given that th= is protocol allows routes of non-minimum metric, is there any possibility o= f the interaction of the two allowing looping, especially with different ro= uters having possibly different views of the topology? Some sort of proof (= which might already exist) would be a good idea here. Incidentally why does= the multiplicative factor on route metrics (CUTOFF_RATIO) have to be stric= tly greater than one? One should work. The description of the multipath Dijkstra doesn't really explain fp and fe.= With the appendix one begins to get an idea, but the main text should not = depend on an appendix in that way. And those are defined parameters, not an= example. I don't understand (I may have missed) how SR_TC_INTERVAL is used. But the = description in 5.1 isn't clear. Why would we have separate TC messages? And= why would MP be prepared to do anything ten times slower? -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B6B6CGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Was away last week, but managed to read through and = red-ink the multipath draft. I have some more detailed notes on it, but her= e - and all I’ll get to right now - are my headline comments.

 

Editorially, if this came from the usual OLSRv2 auth= ors, we’d be doing some work to make it a better fit to the style of = the rest of the OLSRv2 suite. It’s not bad, it just could be a bit be= tter. For example what are listed as Information Bases aren’t, they are Protocol Sets. Together they might form a new= Information Base, or be added to one. And more.

 

There are also various other points that I’d m= ake. For example, it says not just for hop count. Given that OLSRv2 is not = just for hop count, I wouldn’t emphasis this. And I don’t know = why MP-OLSRv2 is indicated as being suitable especially for low data rate links.

 

Technically, my first issue is that OLSRv2 distribut= es a partial topology, so this is working at a disadvantage. OK, but this i= sn’t discussed, and - with the one exception of picking MPRs - tradeo= ffs of the incompleteness of the topology and overheads aren’t even discussed. For a start, TC messages contai= n advertised neighbours. Advertised neighbours must include all MPR selecto= rs, but may include more neighbours - up to all neighbours. I would expect = a discussion of this. (I’m also not actually sure how good the alternative MPR heuristics are, that’s me needing = to read and think more.)

 

I’ve been critical of AODVv2 underspecifying i= nteraction with IP. I’m going to make the same criticism here, given = the suggestion of a reactive multi-path route determination. I’m actu= ally not keen on that idea at all, I think it needs more discussion. It also, I think, is broken in that there is no indicatio= n of how and when these paths are expired. This alone I think requires a ne= w draft. And before that discussion on whether a reactive mechanism that OL= SRv2 otherwise doesn’t have is acceptable. (I don’t think it is.)

 

I’m not as familiar as I should be with loose = source routing. Given that this protocol allows routes of non-minimum metri= c, is there any possibility of the interaction of the two allowing looping,= especially with different routers having possibly different views of the topology? Some sort of proof (which might = already exist) would be a good idea here. Incidentally why does the multipl= icative factor on route metrics (CUTOFF_RATIO) have to be strictly greater = than one? One should work.

 

The description of the multipath Dijkstra doesn̵= 7;t really explain fp and fe. With the appendix one begins to get an idea, = but the main text should not depend on an appendix in that way. And those a= re defined parameters, not an example.

 

I don’t understand (I may have missed) how SR_= TC_INTERVAL is used. But the description in 5.1 isn’t clear. Why woul= d we have separate TC messages? And why would MP be prepared to do anything= ten times slower?

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________= ________________________________________________

T:  +44 (0)1245 24= 2194  |  E: chris.dearlove@baesystems.com

BAE Systems Appli= ed Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Esse= x CM2 8HN.
www.= baesystems.com/ai

B= AE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guil= dford, Surrey, GU2 7YP

 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B6B6CGLKXM0002VGREEN_-- From nobody Mon May 23 08:17:48 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F66E12D1D5; Mon, 23 May 2016 08:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzpQfiWoZH-a; Mon, 23 May 2016 08:17:45 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A24312D959; Mon, 23 May 2016 08:17:32 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id l63so30695657ita.1; Mon, 23 May 2016 08:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8KqMuz3oZ3dE6Ey7b6WwpxAcNKJ2S4GUQbB5WfeBXVo=; b=jFV0g3SZLwtoHI+h1cx8EBGvNqOUZ33W9I6FNMhZURefy6Mvykf6nGSziZGOMmOHhQ DWSwZZQFtCYyL7IU5J2mNeVDbfuqSV/g2hoI7oerDx/UaGN3zKGHXM8We8UNwMjmzV7H ycAf4TIRTmNrIZs5ah3RWiBaanX7ktwQUooiIMlRA+A0NSdOJKrASwAsB2dfS2t0FoRU J4hExiijILf/Ki5QBkSkkSCfzTBtVi6JMO9YmcUmyp9lhNwmF5Efsd+RfktAxMx0TFzD 21WT6+zS3UYZgakzp26qAGE9fTbw3C7bw7DAqierhck7PbcbPfBnBZY5ml9arlurHhq7 PWTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8KqMuz3oZ3dE6Ey7b6WwpxAcNKJ2S4GUQbB5WfeBXVo=; b=AJxi54kbwvQDSIPfPPjGub3WXgQ5pfxMGHWso1E8zmVrNMmf5WCZeXMnKKF/n4wzib V9LehFxLzTODgAuMve/XRGoS8JHbUDpO7EREtnDtBaIKEQaURpVlyryCZhVMMpQgQr7Z 3gvRV/FMj653CnPoTADaGoK0RiR1ayyv1xW9eVLgaH0clo1d8nKeZ0iOX9mjjmEkfm+x utqEQeE4POCWWWpAE4OZsO0R6WomaLF5dk6/e8YTRCndGWp3as9aFSosu9YTQqPEiFRX HVD9LR9PYiVyvxgkJM1SDqYpsX48JZIH1wR8LO1yLhfLyVho7vutDHsESxZbpEVVJERI ey6A== X-Gm-Message-State: AOPr4FW07DuwN0Lz091EbffAXXEbobsKcHmnzPSRUlXCiEBECIC+hnCXkSHKtefcs53Qw7iRdJoedHGqOFQpfg== MIME-Version: 1.0 X-Received: by 10.36.93.80 with SMTP id w77mr13717319ita.48.1464016651586; Mon, 23 May 2016 08:17:31 -0700 (PDT) Received: by 10.79.72.134 with HTTP; Mon, 23 May 2016 08:17:31 -0700 (PDT) In-Reply-To: References: <20160504170444.8256.99788.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 11:17:31 -0400 Message-ID: From: Stan Ratliff To: Thomas Clausen Content-Type: multipart/alternative; boundary=001a113a9838775df4053383f0c1 Archived-At: Cc: manet-ads@ietf.org, "manet@ietf.org" , "Dearlove, Christopher \(UK\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 15:17:47 -0000 --001a113a9838775df4053383f0c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mr. Clausen, The referenced discussion did take place. The consensus going forward was to begin the post-WGLC effort (e.g. find a document shepherd, do the write-up, etc). Regards, Stan On Mon, May 23, 2016 at 1:26 AM, Thomas Clausen wrote: > So, how did that conversation with Mr. Ratliff go? Unless I've missed a > datatracker notification, motion has grind to a halt regarding this doc? > > Thomas > > -- > > *Thomas Heide Clausen =E2=80=A2 @thc= lausen > =E2=80=A2 thomasclausen.org > www.arkko.com/tools/allstats/thomasheidecl= ausen.html > * > > On 05 May 2016, at 05:55, Justin Dean wrote: > > Ack. I'll talk with Stan ASAP and keep things moving. > > Justin > > On Wed, May 4, 2016 at 1:06 PM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > >> This includes all of the issues I listed in my previous email of comment= s >> made at WGLC. >> >> The authors request starting all the post-WGLC things to do. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> ________________________________________________________________________= __ >> >> _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a113a9838775df4053383f0c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113a9838775df4053383f0c1-- From nobody Mon May 23 15:10:14 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A2312DBCD for ; Mon, 23 May 2016 15:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOxaxcJRM7VU for ; Mon, 23 May 2016 15:10:10 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDB812DAC0 for ; Mon, 23 May 2016 15:10:09 -0700 (PDT) Received: by mail-lb0-x22d.google.com with SMTP id sh2so18018251lbb.1 for ; Mon, 23 May 2016 15:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=BJuxNpifV/gw8JjH6+gjmjcQwcA+AN4HhIVsCjQbtbQ=; b=qHkV/SGwUhXshGbDM7POw2NG15vhcdxSa/8VSeLSAxi0J7WR1pcviYAjIkRB5s+A86 x/Bzr/T+UxF7opNla6+Nzp119b/3V8VO7H32cbZGP8P8FRLaa5neiH2oX2uKzwi3e5q3 j5br7p6rY3D6UvbukIPW0LutO+/OgngztgUV5IcWy3HbEU3hEjtUY0FYQtlzVeV1BwG8 yhtSyd75CpmKekldwX3Cc8Q64UzdTxukdPEJsSuYAvI6/RMgVerTeRR/fXBFECrh/RSw ZskWxwZDCuI/yFbAXd9pZq7zPC3KQ+mrZdWKNSWmMc5s0U30t8yIN/IftLkWpSdVPMwP 7kvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BJuxNpifV/gw8JjH6+gjmjcQwcA+AN4HhIVsCjQbtbQ=; b=auREOThQnJB5tu8Y4ZXPz3Cz+XR6JLfnpwquiTNPfazLlQmMcNo4hdCidI7ugPE+Bv 5SwpmryhmgcZ7mBYRS5k4AR48+3CSKL45xdn0og4+gJeB+iasrj6LAtHXCWHtN7zRZve EsNiTtTeVG8ONxwjSWDyG2Y++ERiyMVjj2LZHlAW1qm+W43HCBXwIsBbd5yfDkIZY2pY 4XS5L+ZukowhYr+VrF5LYYWnTPstpeimgbqCashJ7MMncdC6HqrYpzrUDtgApPSChcpH L6km7Zs5Px52BbsncK/vMwnE9o+eUsRCAezOEJejipH9z+hkJ4sErB2a90mLdaIMJePC ACsw== X-Gm-Message-State: AOPr4FWMLc8rbJ87c41P/+O0Ju/S+19hc9FJDcAAdO5pb9Siq5uvwZXG8YTUceOWAfFfJqAZ5K4+mWOUGzqt8A== MIME-Version: 1.0 X-Received: by 10.112.10.37 with SMTP id f5mr6594844lbb.58.1464041407731; Mon, 23 May 2016 15:10:07 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.114.77.4 with HTTP; Mon, 23 May 2016 15:10:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 May 2016 00:10:07 +0200 X-Google-Sender-Auth: pNZHcpdtAdCf4JxZs3ob92Qi16s Message-ID: From: Jiazi YI To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a113606dc0b6263053389b41b Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-08 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 22:10:13 -0000 --001a113606dc0b6263053389b41b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Chris, thanks very much for your comments. Please check my reply inline: On Mon, May 23, 2016 at 2:55 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Was away last week, but managed to read through and red-ink the multipath > draft. I have some more detailed notes on it, but here - and all I=E2=80= =99ll get > to right now - are my headline comments. > > > > Editorially, if this came from the usual OLSRv2 authors, we=E2=80=99d be = doing > some work to make it a better fit to the style of the rest of the OLSRv2 > suite. It=E2=80=99s not bad, it just could be a bit better. For example w= hat are > listed as Information Bases aren=E2=80=99t, they are Protocol Sets. Toget= her they > might form a new Information Base, or be added to one. And more. > As you might have noticed, we try to make the style fit to the OLSRv2-related RFCs. If you have more specific comments, we would glad to make it better. Of course, we will check the style by ourselves also. > > > There are also various other points that I=E2=80=99d make. For example, i= t says > not just for hop count. Given that OLSRv2 is not just for hop count, I > wouldn=E2=80=99t emphasis this. And I don=E2=80=99t know why MP-OLSRv2 is= indicated as > being suitable especially for low data rate links. > Because the specification uses parallel paths, which can provide higher aggregated throughput. > > > Technically, my first issue is that OLSRv2 distributes a partial topology= , > so this is working at a disadvantage. OK, but this isn=E2=80=99t discusse= d, and - > with the one exception of picking MPRs - tradeoffs of the incompleteness = of > the topology and overheads aren=E2=80=99t even discussed. For a start, TC= messages > contain advertised neighbours. Advertised neighbours must include all MPR > selectors, but may include more neighbours - up to all neighbours. I woul= d > expect a discussion of this. (I=E2=80=99m also not actually sure how good= the > alternative MPR heuristics are, that=E2=80=99s me needing to read and thi= nk more.) > In a pure MP-OLSRv2 network, no modification is required regarding the MPR selection. Because the routers choose MPRs independently, and the MPR-selection is non-optimal, we can obtain multiple paths in most cases thanks to the topology redundancy. This has been proven in both simulation study and field tests with various node densities. I don=E2=80=99t understand (I may have missed) how SR_TC_INTERVAL is used. = But the > description in 5.1 isn=E2=80=99t clear. Why would we have separate TC mes= sages? And > why would MP be prepared to do anything ten times slower? This is to deal with the OLSRv2/MP-OLSRv2 mixed network. As we mentioned in our previous post, an MP-OLSR router can be recognized as source-enabled unless it generates a HELLO or TC message. So what we do is: - MP-OLSR enabled routers MUST generate TC messages even it's not required to do so according to normal OLSR process, but with longer interval. This is because the change from MP-OLSR enabled to OLSR-only router is very rare compared to topology changes. The corresponding SR_OLSR_HOLD_TIME will be set to longer value also. - During routing MPR selection, an MP-OLSR enabled router SHOULD be firstly considered. The number of MP-OLSR enabled MPRs MUST be equal or greater than NUMBER_OF_PATHS, providing there are enough MP-OLSR symmetric neighbors. Or else, all the MP-OLSR routers are selected as MPR. > > > I=E2=80=99ve been critical of AODVv2 underspecifying interaction with IP.= I=E2=80=99m > going to make the same criticism here, given the suggestion of a reactive > multi-path route determination. I=E2=80=99m actually not keen on that ide= a at all, > I think it needs more discussion. > The MP-OLSR is a bit different from AODVv2 -- the route calculation is local. It doesn't require DSR/AODV-like route discovery/route reply (which can have long delay). Therefore, no buffer (or very little buffer) is required: the packet is either sent out or dropped. I think there is no need to go to details on how to trigger the route calculation, which is implementation specific. Then for the source routing part, it's just standard IP routing. > It also, I think, is broken in that there is no indication of how and whe= n > these paths are expired. This alone I think requires a new draft. > In fact, in the previous revision (-06), there is a valid time field in the multi-path routing set. But it's removed to match RFC7181-style based on the comments received (because Routing Set in RFC7181 is not based on timer-based expiration either). All the tuples in the Multi-path Routing Set will be removed whenever there is need to update the OLSRv2 Routing Set. This can make it more reactive to topology changes. We will clarify it in the next revision. > And before that discussion on whether a reactive mechanism that OLSRv2 > otherwise doesn=E2=80=99t have is acceptable. (I don=E2=80=99t think it i= s.) > > Personally, I don't see why it's not acceptable. Here I just want to note that this is an experimental draft. As far as I can see, if we have: - a clear specification - a mechanism that can bring potential performance benefit and won't break existed networks - some simulation study and implementation that prove the idea actually works and can be implemented (the implementation is even not mandatory to standard track protocol -- although I think it's not a good policy) - people interested in the idea we already have good reason to move ahead? > > > I=E2=80=99m not as familiar as I should be with loose source routing. Giv= en that > this protocol allows routes of non-minimum metric, is there any possibili= ty > of the interaction of the two allowing looping, especially with different > routers having possibly different views of the topology? > When loose source routing is used, the forwarding decision is based on the forwarding table generated by OLSRv2. So if there is a loop, it's a loop in OLSRv2 (which is possible, due to attacks or high dynamic topology). > Some sort of proof (which might already exist) would be a good idea here. > Incidentally why does the multiplicative factor on route metrics > (CUTOFF_RATIO) have to be strictly greater than one? One should work. > > > > The description of the multipath Dijkstra doesn=E2=80=99t really explain = fp and > fe. With the appendix one begins to get an idea, but the main text should > not depend on an appendix in that way. And those are defined parameters, > not an example. > will clarify the description. and thanks again for the comments. regards Jiazi > > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a113606dc0b6263053389b41b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chris,=C2=A0

thanks very much for your comments. Please check m= y reply inline:=C2=A0

On Mon, May 23, 2016 at 2:55 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Was away last week, but managed to read through and = red-ink the multipath draft. I have some more detailed notes on it, but her= e - and all I=E2=80=99ll get to right now - are my headline comments.

=C2=A0

Editorially, if this came from the usual OLSRv2 auth= ors, we=E2=80=99d be doing some work to make it a better fit to the style o= f the rest of the OLSRv2 suite. It=E2=80=99s not bad, it just could be a bi= t better. For example what are listed as Information Bases aren=E2=80=99t, they are Protocol Sets. Together they might form a n= ew Information Base, or be added to one. And more.


As you might have noticed, we try to make the style= fit to the OLSRv2-related RFCs. If you have more specific comments, we wou= ld glad to make it better. Of course, we will check the style by ourselves = also.=C2=A0
=C2=A0

=C2=A0

There are also various other points that I=E2=80=99d= make. For example, it says not just for hop count. Given that OLSRv2 is no= t just for hop count, I wouldn=E2=80=99t emphasis this. And I don=E2=80=99t= know why MP-OLSRv2 is indicated as being suitable especially for low data rate links.


B= ecause the specification uses parallel paths, which can provide higher aggr= egated throughput.=C2=A0
=C2=A0

=C2=A0

Technically, my first issue is that OLSRv2 distribut= es a partial topology, so this is working at a disadvantage. OK, but this i= sn=E2=80=99t discussed, and - with the one exception of picking MPRs - trad= eoffs of the incompleteness of the topology and overheads aren=E2=80=99t even discussed. For a start, TC messages cont= ain advertised neighbours. Advertised neighbours must include all MPR selec= tors, but may include more neighbours - up to all neighbours. I would expec= t a discussion of this. (I=E2=80=99m also not actually sure how good the alternative MPR heuristics are, that=E2=80=99s me needin= g to read and think more.)


= In a pure MP-OLSRv2 network, no modification is required regarding the MPR = selection. Because the routers choose MPRs independently, and the MPR-selec= tion is non-optimal, we can obtain multiple paths in most cases thanks to t= he topology redundancy. This has been proven in both simulation study and f= ield tests with various node densities.=C2=A0

I don=E2=80=99t understand (I may have missed) how SR_TC_INTER= VAL is used. But the description in 5.1 isn=E2=80=99t clear. Why would we h= ave separate TC messages? And why would MP be prepared to do anything ten t= imes slower?


<= /div>
This is to deal with the OLSRv2/MP-OLSRv2 mixed network. As we me= ntioned in our previous post, an MP-OLSR router can be recognized as source= -enabled unless it generates a HELLO or TC message. So what we do is:=C2=A0=
=C2=A0 =C2=A0- MP-OLSR enabled routers MUST generate TC mes= sages even it's not required to do so according to normal OLSR process,= but with longer interval. This is because the change from MP-OLSR enabled = to OLSR-only router is very rare compared to topology changes. The correspo= nding SR_OLSR_HOLD_TIME will be set to longer value also.=C2=A0
= =C2=A0 =C2=A0 - During routing MPR selection, an MP-OLSR enabled router SHO= ULD be firstly considered. The number of MP-OLSR enabled MPRs MUST be equal= or greater than NUMBER_OF_PATHS, providing there are enough MP-OLSR symmet= ric neighbors. Or else, all the MP-OLSR routers are selected as MPR.
<= /div>

=C2=A0

=C2=A0

I=E2=80=99ve been critical of AODVv2 underspecifying= interaction with IP. I=E2=80=99m going to make the same criticism here, gi= ven the suggestion of a reactive multi-path route determination. I=E2=80=99= m actually not keen on that idea at all, I think it needs more discussion.


The MP-O= LSR is a bit different from AODVv2 -- the route calculation is local. It do= esn't require DSR/AODV-like route discovery/route reply (which can have= long delay). Therefore, no buffer (or very little buffer) is required: the= packet is either sent out or dropped. I think there is no need to go to de= tails on how to trigger the route calculation, which is implementation spec= ific.=C2=A0
Then for the source routing part, it's just stand= ard IP routing.=C2=A0
=C2=A0

It also, I= think, is broken in that there is no indication of how and when these path= s are expired. This alone I think requires a new draft.


In fact, in the previous revision (-06), ther= e is a valid time field in the multi-path routing set. But it's removed= to match RFC7181-style based on the comments received (because Routing Set= in RFC7181 is not based on timer-based expiration either). All the tuples = in the Multi-path Routing Set will be removed whenever there is need to upd= ate the OLSRv2 Routing Set. This can make it more reactive to topology chan= ges.=C2=A0
We will clarify it in the next revision.=C2=A0
=C2=A0

And before that discussion on whether a= reactive mechanism that OLSRv2 otherwise doesn=E2=80=99t have is acceptabl= e. (I don=E2=80=99t think it is.)


<= div>Personally, I don't see why it's not acceptable. Here I just wa= nt to note that this is an experimental draft. As far as I can see, if we h= ave:

=C2=A0 =C2=A0- a clear specification
=C2=A0 =C2=A0- a mechanism that can bring potential performance benefit a= nd won't break existed networks
=C2=A0 =C2=A0- some simulatio= n study and implementation that prove the idea actually works and can be im= plemented (the implementation is even not mandatory to standard track proto= col -- although I think it's not a good policy)
=C2=A0 =C2=A0= - people interested in the idea

we already have go= od reason to move ahead?=C2=A0
=C2=A0
=

=C2=A0

I=E2=80=99m not as familiar as I should be with loos= e source routing. Given that this protocol allows routes of non-minimum met= ric, is there any possibility of the interaction of the two allowing loopin= g, especially with different routers having possibly different views of the topology?


When loose source routing is used, the forwarding decision= is based on the forwarding table generated by OLSRv2. So if there is a loo= p, it's a loop in OLSRv2 (which is possible, due to attacks or high dyn= amic topology).=C2=A0

=C2=A0

Some sort of proof (which might already exist) would be a good idea he= re. Incidentally why does the multiplicative factor on route metrics (CUTOF= F_RATIO) have to be strictly greater than one? One should work.

=C2=A0

The description of the multipath Dijkstra doesn=E2= =80=99t really explain fp and fe. With the appendix one begins to get an id= ea, but the main text should not depend on an appendix in that way. And tho= se are defined parameters, not an example.


will clarify the description.=C2=A0

and thanks again for the comments.=C2=A0

regards=

Jiazi
=C2=A0

=

=C2=A0

=C2=A0

--

Christopher De= arlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________________________________________= ______

T: =C2=A0+44 (0)1245 242194<= /a> =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, = Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai=

BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office= : Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--001a113606dc0b6263053389b41b-- From nobody Mon May 23 21:24:12 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC2112DA81; Mon, 23 May 2016 21:24:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160524042410.20289.98393.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 21:24:10 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc6779bis-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 04:24:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Definition of Managed Objects for the Neighborhood Discovery Protocol Authors : Ulrich Herberg Robert G. Cole Ian D Chakeres Thomas Heide Clausen Filename : draft-ietf-manet-rfc6779bis-06.txt Pages : 71 Date : 2016-05-23 Abstract: This document revises, extends, and replaces RFC 6779. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The extensions described in this document add objects and values to support the NHDP optimization specified in RFC 7466. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6779bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-rfc6779bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc6779bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 24 05:28:57 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E016912D690 for ; Tue, 24 May 2016 05:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.617 X-Spam-Level: X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_FROM_MISSP_DKIM=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8stMlMI407t for ; Tue, 24 May 2016 05:28:52 -0700 (PDT) Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB99112D6A3 for ; Tue, 24 May 2016 05:28:51 -0700 (PDT) Received: from turig.iit.cnr.it (turig.iit.cnr.it [146.48.98.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxbk.iit.cnr.it (Postfix) with ESMTPSA id 8A601C0C34 for ; Tue, 24 May 2016 14:28:46 +0200 (CEST) Date: Tue, 24 May 2016 14:34:01 +0200 From: Elisabetta Biondi To: manet@ietf.org Message-ID: <57444a39.O0TlqXPPFjqBmUfD%chants16_publicity@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [manet] [ACM CHANTS 2016] Call for Papers - One week to deadline, register your paper now! X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 12:28:55 -0000 =============================================================================== =============================================================================== ACM CHANTS 2016 - 11th Workshop on Challenged Networks co-located with ACM MobiCom 2016 October 3-7, 2016, New York, USA www.acm-chants.org =============================================================================== =============================================================================== Challenged networks comprise those situations where communication is desired, but traditional Internet architectures fail to provide it effectively. Such networks may be characterized by intermittent connectivity, a heterogeneous mix of nodes, frequent nodal churn, and widely varying network conditions. Examples of challenged networks include deployments in rural and remote areas, networks to support emergency response operations, inter-planetary networks, sensor and wildlife monitoring networks, underwater networks, road vehicle networks, and, more recently, networks of micro aerial vehicles. The applications of challenged networks range from time-critical communications such as for disaster relief to delay-tolerant transmission in poorly connected regions or where censorship should be counteracted. However, challenged networking has also found many applications in everyday settings, for which they were not initially conceived, such as opportunistic networking supporting data-centric communications, traffic offloading from cellular networks, mobile cloud/edge computing, opportunistic and participatory sensing, challenged IoT. The increasing availability of wireless communications in embedded devices as well as integration of technologies such as Wi-Fi direct on Android platforms and LTE's D2D (device-to-device) communication on general purpose mobile devices, will further push the development of challenged networking solutions. Challenged networking has also chartered new directions for inter-disciplinary research, e.g., applying findings from social networks and network science. This workshop builds on the success of the ten previous CHANTS workshops, and WDTN 2005, and aims to stimulate research on the most novel topics of challenged networking research. This year's edition encourages submission of theoretical and experimental work (including studies of real deployment), with a primary interest in the **new directions of challenged networking such as mobile cloud/mobile edge computing, IoT, mobile data offloading, and challenged SDN**. The workshop seeks original work presented in the form of research papers describing new research approaches and results, as well as demo submissions. Highly disruptive work-in-progress and position papers are also welcome, provided they focus on particularly innovative, out-of-the-box, solutions or applications for challenged networks. All papers shall be forward-looking, describe their relationship to existing work, and shall argue their impact and implications for ongoing or future research. Topics of interest include, but are not limited to: - Delay/disruption-tolerant networks (DTNs), opportunistic communication and computing - Architecture, design, and implementation of communication systems for challenged networks - Modeling, analysis, and characterization of challenged networks and protocols - Challenged networking techniques for mobile cloud computing - Mobile data offloading via challenged networks - Challenged networking techniques for participatory and opportunistic sensing - Challenged networking in the Internet of Things - Big data analytics in challenged networking - Software-defined networking in challenged environments - Security/trust/privacy concerns and solutions in challenged networks - Energy-efficient communication in challenged networks - Information centric and content-centric networking in challenged networks - Real-world mobility trace collection, analysis, and modeling for challenged environments - Network science methods for challenged networks - Network coding in challenged networks - Novel challenged networking systems (e.g., networks of micro aerial vehicles) - Real deployment and case studies in various stages of use - Disrupted scenarios for challenged networks (e.g., disaster relief and emergency management) - Daily use applications (e.g., mobile social networking, crowdsourcing, censorship evasion, sensor networks, smart cities) - Test and simulation tools for evaluating challenged network systems - Configuration, management, and monitoring of challenged networks. PAPER FORMAT AND SUBMISSION INSTRUCTIONS ---------------------------------------- Submitted papers must be no longer than 6 pages, and should adhere to the standard ACM conference proceedings format. Demo proposals (to be published as part of the proceedings) must not be longer than 2 pages plus 1 page description of the precise setup and requirements (the 1-page setup description will not be published in the proceedings). Reviews will be single-blinded. Papers should neither have been published elsewhere nor being currently under review by another conference or journal. EDITORIAL FOLLOW-UPS -------------------- Extended versions of the selected workshop papers will be considered for possible fast track publication on the Computer Communications Journal (Elsevier), in a special section on Challenged Networks. IMPORTANT DATES --------------- - Abstract Registration: 25 May 2016 - Submission Deadline: 1 June 2016 - Acceptance Notification: 6 July 2016 - Camera Ready Due: 20 July 2016 PROGRAM COMMITTEE CHAIRS ------------------------ Chiara Boldrini (IIT-CNR, Italy) Marcelo Dias de Amorim (UPMC and CNRS, France) TECHNICAL PROGRAM COMMITTEE --------------------------- Kevin Almeroth (UC-Santa Barbara, USA) Mostafa Ammar (Georgia Institute of Technology, USA) Fehmi Ben Abdesslem (SICS Swedish ICT, Sweden) Guohong Cao (The Pennsylvania State University, USA) Marco Cello (Nokia Bell Labs) Vania Conan (Thales Communications & Security, France) Luis Costa (Universidade Federal do Rio de Janeiro, Brazil) Do Young Eun (North Carolina State University, USA) Kevin Fall (Carnegie Mellon University, USA) Stephen Farrell (Trinity College Dublin, Ireland) Domenico Giustiniano (IMDEA Networks Institute, Spain) Tristan Henderson (University of St Andrews, UK) Andrea Hess (Trinity College Dublin, Ireland) Pan Hui (Hong Kong Unive. of Science and Technology) Karin Anna Hummel (JKU Linz, Austria) Mohan Kumar (Rochester Institute of Technology, USA) Kyunghan Lee (UNIST, Korea) Anders Lindgren (SICS Swedish ICT, Sweden) Mirco Musolesi (University College London, UK) Katia Obraczka (UC Santa Cruz, USA) Melek Onen (Eurecom, France) Joerg Ott (Technische Universitat Munchen, Germany) Elena Pagani (Universita degli Studi di Milano, Italy) Andrea Passarella (IIT-CNR, Italy) Eric Rozner (IBM Research, USA) Pavlos Sermpezis (FORTH, Greece) Thrasyvoulos Spyropoulos (Eurecom, France) Stavros Toumpis (Athens University of Economics and Business, Greece) Thierry Turletti (INRIA, France) Yu Wang (University of North Carolina at Charlotte, USA) Eiko Yoneki (University of Cambridge, UK) Xiaolan Zhang (Fordham University, USA) WEB CHAIR --------- Fehmi Ben Abdesslem (SICS Swedish ICT, Sweden) PUBLICITY CHAIR --------------- Elisabetta Biondi (IIT-CNR, Italy) STEERING COMMITTEE ------------------ Kevin Almeroth (UC Santa Barbara, USA) Kevin Fall (Carnegie Mellon University, USA) Stephen Farrell (Trinity College Dublin, Ireland) Jorg Ott (Technische Universitat Munchen, Germany) Andrea Passarella (IIT-CNR, Italy) From nobody Tue May 24 08:39:20 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5321512D8CB for ; Tue, 24 May 2016 08:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.345 X-Spam-Level: X-Spam-Status: No, score=-8.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uhg1ug34oByI for ; Tue, 24 May 2016 08:39:14 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6752A12D893 for ; Tue, 24 May 2016 08:39:13 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.26,360,1459810800"; d="scan'208,217"; a="35945846" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 24 May 2016 16:39:11 +0100 X-IronPort-AV: E=Sophos;i="5.26,360,1459810800"; d="scan'208,217";a="119473554" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 24 May 2016 16:39:11 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.168]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Tue, 24 May 2016 16:39:11 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi YI Thread-Topic: [manet] draft-ietf-manet-olsrv2-multipath-08 Thread-Index: AdG08hEGuTDPBDyTRIGr+M/qpuSsmgARWp2AACYKAfA= Date: Tue, 24 May 2016 15:39:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B73A3GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-08 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 15:39:17 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B73A3GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgQ01EPiBiZWxvdy4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3Ig UHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJv cmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwg IEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxt c2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENN MiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9h aT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQg aW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJl eSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiB5aS5q aWF6aUBnbWFpbC5jb20gW21haWx0bzp5aS5qaWF6aUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBK aWF6aSBZSQ0KU2VudDogMjMgTWF5IDIwMTYgMjM6MTANClRvOiBEZWFybG92ZSwgQ2hyaXN0b3Bo ZXIgKFVLKQ0KQ2M6IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBkcmFmdC1p ZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDgNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMg bWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIg ZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVm dWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRh Y2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRo YXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJl PGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nw b3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1h aWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJh bmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1 bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQpIaSBDaHJp cywNCg0KdGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIGNoZWNrIG15 IHJlcGx5IGlubGluZToNCg0KT24gTW9uLCBNYXkgMjMsIDIwMTYgYXQgMjo1NSBQTSwgRGVhcmxv dmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0 bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0KV2FzIGF3YXkgbGFzdCB3 ZWVrLCBidXQgbWFuYWdlZCB0byByZWFkIHRocm91Z2ggYW5kIHJlZC1pbmsgdGhlIG11bHRpcGF0 aCBkcmFmdC4gSSBoYXZlIHNvbWUgbW9yZSBkZXRhaWxlZCBub3RlcyBvbiBpdCwgYnV0IGhlcmUg LSBhbmQgYWxsIEnigJlsbCBnZXQgdG8gcmlnaHQgbm93IC0gYXJlIG15IGhlYWRsaW5lIGNvbW1l bnRzLg0KDQpFZGl0b3JpYWxseSwgaWYgdGhpcyBjYW1lIGZyb20gdGhlIHVzdWFsIE9MU1J2MiBh dXRob3JzLCB3ZeKAmWQgYmUgZG9pbmcgc29tZSB3b3JrIHRvIG1ha2UgaXQgYSBiZXR0ZXIgZml0 IHRvIHRoZSBzdHlsZSBvZiB0aGUgcmVzdCBvZiB0aGUgT0xTUnYyIHN1aXRlLiBJdOKAmXMgbm90 IGJhZCwgaXQganVzdCBjb3VsZCBiZSBhIGJpdCBiZXR0ZXIuIEZvciBleGFtcGxlIHdoYXQgYXJl IGxpc3RlZCBhcyBJbmZvcm1hdGlvbiBCYXNlcyBhcmVu4oCZdCwgdGhleSBhcmUgUHJvdG9jb2wg U2V0cy4gVG9nZXRoZXIgdGhleSBtaWdodCBmb3JtIGEgbmV3IEluZm9ybWF0aW9uIEJhc2UsIG9y IGJlIGFkZGVkIHRvIG9uZS4gQW5kIG1vcmUuDQoNCkFzIHlvdSBtaWdodCBoYXZlIG5vdGljZWQs IHdlIHRyeSB0byBtYWtlIHRoZSBzdHlsZSBmaXQgdG8gdGhlIE9MU1J2Mi1yZWxhdGVkIFJGQ3Mu IElmIHlvdSBoYXZlIG1vcmUgc3BlY2lmaWMgY29tbWVudHMsIHdlIHdvdWxkIGdsYWQgdG8gbWFr ZSBpdCBiZXR0ZXIuIE9mIGNvdXJzZSwgd2Ugd2lsbCBjaGVjayB0aGUgc3R5bGUgYnkgb3Vyc2Vs dmVzIGFsc28uDQoNCkNNRD4gTGF0ZXIgZm9yIHRoaXMgb25lLg0KDQpUaGVyZSBhcmUgYWxzbyB2 YXJpb3VzIG90aGVyIHBvaW50cyB0aGF0IEnigJlkIG1ha2UuIEZvciBleGFtcGxlLCBpdCBzYXlz IG5vdCBqdXN0IGZvciBob3AgY291bnQuIEdpdmVuIHRoYXQgT0xTUnYyIGlzIG5vdCBqdXN0IGZv ciBob3AgY291bnQsIEkgd291bGRu4oCZdCBlbXBoYXNpcyB0aGlzLiBBbmQgSSBkb27igJl0IGtu b3cgd2h5IE1QLU9MU1J2MiBpcyBpbmRpY2F0ZWQgYXMgYmVpbmcgc3VpdGFibGUgZXNwZWNpYWxs eSBmb3IgbG93IGRhdGEgcmF0ZSBsaW5rcy4NCg0KQmVjYXVzZSB0aGUgc3BlY2lmaWNhdGlvbiB1 c2VzIHBhcmFsbGVsIHBhdGhzLCB3aGljaCBjYW4gcHJvdmlkZSBoaWdoZXIgYWdncmVnYXRlZCB0 aHJvdWdocHV0Lg0KDQpDTUQ+IE5vdCBjb252aW5jZWQgYnkgdGhhdCBhcmd1bWVudC4gWW914oCZ cmUgZ29pbmcgdG8gZ2FpbiBhIGZhY3RvciBvZiBtYXliZSB0d28gb3IgdGhyZWUgYXQgbW9zdCAo YW5kIG9ubHkgaWYgdGhlIG5ldHdvcmsgaXMgZGlmZmVyZW50aWFsbHkgbG9hZGVkIC0gYXQgd29y c3QgeW91IGxvc2UsIG5vdCBnYWluKSB3aGVyZWFzIHdoZW4gSSBzZWUgbG93IGRhdGEgcmF0ZSBw YXRocywgdGhhdCBjYW4gdmFyeSBieSBvcmRlcnMgb2YgbWFnbml0dWRlLg0KDQpUZWNobmljYWxs eSwgbXkgZmlyc3QgaXNzdWUgaXMgdGhhdCBPTFNSdjIgZGlzdHJpYnV0ZXMgYSBwYXJ0aWFsIHRv cG9sb2d5LCBzbyB0aGlzIGlzIHdvcmtpbmcgYXQgYSBkaXNhZHZhbnRhZ2UuIE9LLCBidXQgdGhp cyBpc27igJl0IGRpc2N1c3NlZCwgYW5kIC0gd2l0aCB0aGUgb25lIGV4Y2VwdGlvbiBvZiBwaWNr aW5nIE1QUnMgLSB0cmFkZW9mZnMgb2YgdGhlIGluY29tcGxldGVuZXNzIG9mIHRoZSB0b3BvbG9n eSBhbmQgb3ZlcmhlYWRzIGFyZW7igJl0IGV2ZW4gZGlzY3Vzc2VkLiBGb3IgYSBzdGFydCwgVEMg bWVzc2FnZXMgY29udGFpbiBhZHZlcnRpc2VkIG5laWdoYm91cnMuIEFkdmVydGlzZWQgbmVpZ2hi b3VycyBtdXN0IGluY2x1ZGUgYWxsIE1QUiBzZWxlY3RvcnMsIGJ1dCBtYXkgaW5jbHVkZSBtb3Jl IG5laWdoYm91cnMgLSB1cCB0byBhbGwgbmVpZ2hib3Vycy4gSSB3b3VsZCBleHBlY3QgYSBkaXNj dXNzaW9uIG9mIHRoaXMuIChJ4oCZbSBhbHNvIG5vdCBhY3R1YWxseSBzdXJlIGhvdyBnb29kIHRo ZSBhbHRlcm5hdGl2ZSBNUFIgaGV1cmlzdGljcyBhcmUsIHRoYXTigJlzIG1lIG5lZWRpbmcgdG8g cmVhZCBhbmQgdGhpbmsgbW9yZS4pDQoNCkluIGEgcHVyZSBNUC1PTFNSdjIgbmV0d29yaywgbm8g bW9kaWZpY2F0aW9uIGlzIHJlcXVpcmVkIHJlZ2FyZGluZyB0aGUgTVBSIHNlbGVjdGlvbi4gQmVj YXVzZSB0aGUgcm91dGVycyBjaG9vc2UgTVBScyBpbmRlcGVuZGVudGx5LCBhbmQgdGhlIE1QUi1z ZWxlY3Rpb24gaXMgbm9uLW9wdGltYWwsIHdlIGNhbiBvYnRhaW4gbXVsdGlwbGUgcGF0aHMgaW4g bW9zdCBjYXNlcyB0aGFua3MgdG8gdGhlIHRvcG9sb2d5IHJlZHVuZGFuY3kuIFRoaXMgaGFzIGJl ZW4gcHJvdmVuIGluIGJvdGggc2ltdWxhdGlvbiBzdHVkeSBhbmQgZmllbGQgdGVzdHMgd2l0aCB2 YXJpb3VzIG5vZGUgZGVuc2l0aWVzLg0KDQpDTUQ+IFJlZmVyZW5jZXM/IEFuZCBldmVuIGlmIHNv LCBJIHdvdWxkIGV4cGVjdCBhIGRpc2N1c3Npb24gb2YgdGhlIHN1YmplY3QuIEFuZCB0aGF0IHN0 aWxsIGRvZXNu4oCZdCBhZGRyZXNzIHRoZSBhZHZlcnRpc2VkIG5laWdoYm91cnMgaXNzdWUuDQoN CkkgZG9u4oCZdCB1bmRlcnN0YW5kIChJIG1heSBoYXZlIG1pc3NlZCkgaG93IFNSX1RDX0lOVEVS VkFMIGlzIHVzZWQuIEJ1dCB0aGUgZGVzY3JpcHRpb24gaW4gNS4xIGlzbuKAmXQgY2xlYXIuIFdo eSB3b3VsZCB3ZSBoYXZlIHNlcGFyYXRlIFRDIG1lc3NhZ2VzPyBBbmQgd2h5IHdvdWxkIE1QIGJl IHByZXBhcmVkIHRvIGRvIGFueXRoaW5nIHRlbiB0aW1lcyBzbG93ZXI/DQoNClRoaXMgaXMgdG8g ZGVhbCB3aXRoIHRoZSBPTFNSdjIvTVAtT0xTUnYyIG1peGVkIG5ldHdvcmsuIEFzIHdlIG1lbnRp b25lZCBpbiBvdXIgcHJldmlvdXMgcG9zdCwgYW4gTVAtT0xTUiByb3V0ZXIgY2FuIGJlIHJlY29n bml6ZWQgYXMgc291cmNlLWVuYWJsZWQgdW5sZXNzIGl0IGdlbmVyYXRlcyBhIEhFTExPIG9yIFRD IG1lc3NhZ2UuIFNvIHdoYXQgd2UgZG8gaXM6DQogICAtIE1QLU9MU1IgZW5hYmxlZCByb3V0ZXJz IE1VU1QgZ2VuZXJhdGUgVEMgbWVzc2FnZXMgZXZlbiBpdCdzIG5vdCByZXF1aXJlZCB0byBkbyBz byBhY2NvcmRpbmcgdG8gbm9ybWFsIE9MU1IgcHJvY2VzcywgYnV0IHdpdGggbG9uZ2VyIGludGVy dmFsLiBUaGlzIGlzIGJlY2F1c2UgdGhlIGNoYW5nZSBmcm9tIE1QLU9MU1IgZW5hYmxlZCB0byBP TFNSLW9ubHkgcm91dGVyIGlzIHZlcnkgcmFyZSBjb21wYXJlZCB0byB0b3BvbG9neSBjaGFuZ2Vz LiBUaGUgY29ycmVzcG9uZGluZyBTUl9PTFNSX0hPTERfVElNRSB3aWxsIGJlIHNldCB0byBsb25n ZXIgdmFsdWUgYWxzby4NCiAgICAtIER1cmluZyByb3V0aW5nIE1QUiBzZWxlY3Rpb24sIGFuIE1Q LU9MU1IgZW5hYmxlZCByb3V0ZXIgU0hPVUxEIGJlIGZpcnN0bHkgY29uc2lkZXJlZC4gVGhlIG51 bWJlciBvZiBNUC1PTFNSIGVuYWJsZWQgTVBScyBNVVNUIGJlIGVxdWFsIG9yIGdyZWF0ZXIgdGhh biBOVU1CRVJfT0ZfUEFUSFMsIHByb3ZpZGluZyB0aGVyZSBhcmUgZW5vdWdoIE1QLU9MU1Igc3lt bWV0cmljIG5laWdoYm9ycy4gT3IgZWxzZSwgYWxsIHRoZSBNUC1PTFNSIHJvdXRlcnMgYXJlIHNl bGVjdGVkIGFzIE1QUi4NCg0KIENNRD4gTm90IGhhcHB5IHdpdGggdGhhdC4gVGhhdCBhc3N1bWVz IGluIGVmZmVjdCB0aGF0IG11bHRpcGF0aCByb3V0ZXMgYXJlIG1vcmUgc3RhYmxlIC0gYmVjYXVz ZSB0aGF04oCZZCB3aGF0IHNlbmRpbmcgdGVuIHRpbWVzIGxlc3Mgb2Z0ZW4gbWVhbnMuIEFuZCBp ZiB5b3UgYXJlIHNlbmRpbmcgdGVuIHRpbWVzIGxlc3Mgb2Z0ZW4sIHRoYXQgd2lsbCByZXF1aXJl IHRlbiB0aW1lcyB0aGUgdmFsaWRpdHkgdGltZS4gV2hpY2ggd2lsbCBjYXVzZSB0aG9zZSBsaW5r cyB0byBoYW5nIGFyb3VuZCBsb25nZXIsIGFuZCB3aWxsIGJlIHVzZWQgYnkgbm9uLU1QIHJvdXRl cnMgaW4gdGhlIHNhbWUgd2F5LiAoSXTigJlzIGV2ZW4gcG9zc2libGUgdGhhdCBhIGNvbXBsaWFu dCBpbXBsZW1lbnRhdGlvbiBtaWdodCBjaG9vc2UgdG8gcHJlZmVyZW50aWFsbHkgdXNlIGxpbmtz IHdpdGggbG9uZ2VyIHZhbGlkaXR5IHRpbWVzLCBhbGwgZWxzZSBiZWluZyBlcXVhbC4gSeKAmXZl IG5ldmVyIHRyaWVkIHRoYXQsIGJ1dCBpdOKAmXMgYW4gb2J2aW91cyBwb3NzaWJpbGl0eSBpbiBz b21lIGhldGVyb2dlbmVvdXMgbmV0d29ya3MuKSBJZiB0ZW4gdGltZXMgbG9uZ2VyIGlzIE9LIGZv ciBzb21lIGxpbmtzLCB3aHkgbm90IGFsbD8gSSB0aGluayB0aGVyZeKAmXMgYSBwcm9ibGVtIGhl cmUgLSBob3cgbXVjaCB3b3JrIHdpdGggaGlnaGx5IG1vYmlsZSBtaXhlZCBuZXR3b3JrcyBoYXMg YmVlbiBkb25lPw0KDQpJ4oCZdmUgYmVlbiBjcml0aWNhbCBvZiBBT0RWdjIgdW5kZXJzcGVjaWZ5 aW5nIGludGVyYWN0aW9uIHdpdGggSVAuIEnigJltIGdvaW5nIHRvIG1ha2UgdGhlIHNhbWUgY3Jp dGljaXNtIGhlcmUsIGdpdmVuIHRoZSBzdWdnZXN0aW9uIG9mIGEgcmVhY3RpdmUgbXVsdGktcGF0 aCByb3V0ZSBkZXRlcm1pbmF0aW9uLiBJ4oCZbSBhY3R1YWxseSBub3Qga2VlbiBvbiB0aGF0IGlk ZWEgYXQgYWxsLCBJIHRoaW5rIGl0IG5lZWRzIG1vcmUgZGlzY3Vzc2lvbi4NCg0KVGhlIE1QLU9M U1IgaXMgYSBiaXQgZGlmZmVyZW50IGZyb20gQU9EVnYyIC0tIHRoZSByb3V0ZSBjYWxjdWxhdGlv biBpcyBsb2NhbC4gSXQgZG9lc24ndCByZXF1aXJlIERTUi9BT0RWLWxpa2Ugcm91dGUgZGlzY292 ZXJ5L3JvdXRlIHJlcGx5ICh3aGljaCBjYW4gaGF2ZSBsb25nIGRlbGF5KS4gVGhlcmVmb3JlLCBu byBidWZmZXIgKG9yIHZlcnkgbGl0dGxlIGJ1ZmZlcikgaXMgcmVxdWlyZWQ6IHRoZSBwYWNrZXQg aXMgZWl0aGVyIHNlbnQgb3V0IG9yIGRyb3BwZWQuIEkgdGhpbmsgdGhlcmUgaXMgbm8gbmVlZCB0 byBnbyB0byBkZXRhaWxzIG9uIGhvdyB0byB0cmlnZ2VyIHRoZSByb3V0ZSBjYWxjdWxhdGlvbiwg d2hpY2ggaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQpUaGVuIGZvciB0aGUgc291cmNlIHJv dXRpbmcgcGFydCwgaXQncyBqdXN0IHN0YW5kYXJkIElQIHJvdXRpbmcuDQoNCkNNRD4gTm8sIGl0 4oCZcyBpbnRyb2R1Y2VkIHNvbWV0aGluZyBuZXcgdG8gT0xTUnYyLCB0aGUgbmVlZCB0byBiZSB0 cmlnZ2VyZWQgYnkgSVAuIFNvbWVib2R5IChIZW5uaW5nPykgY3JpdGljaXNpbmcgQU9EVnYyIG1h ZGUgdGhlIG9ic2VydmF0aW9uIHRoaXMgaXNu4oCZdCBhY3R1YWxseSBlYXN5IHRvIGRvLiBBbmQg aXTigJlzIG5ldyB0byBPTFNSdjIsIGFuZCB1bm5lY2Vzc2FyeS4gSeKAmW0gc3Ryb25nbHkgYWdh aW5zdCB0aGlzIGFzIGEgc3BlY2lmaWNhdGlvbi4NCg0KTm90ZSB0aGF0IGFzIHRoaXMgaXMgbG9j YWwsIHlvdSBjb3VsZCBjaG9vc2UgdG8gZG8gdGhpcyBsb2NhbGx5IGlmIHlvdSB3YW50ZWQgdG8g YW5kIHN0aWxsIGludGVyb3BlcmF0ZS4gSSB3b3VsZG7igJl0IGJlIGFzIHNldCBhZ2FpbnN0IHRo aXMgYXMgYW4gb3B0aW9uIGluIGEgaGlnaGx5IHJlc291cmNlIGxpbWl0ZWQgcm91dGVyLiBCdXQg YXMgdGhlIG9ubHkgc3BlY2lmaWNhdGlvbiwgdGhhdCBtdXN0IGJlIGRvbmUgdGhpcyB3YXk/IE5v LiBJ4oCZbSBhZ2FpbnN0IHRoaXMgZHJhZnQgcHJvY2VlZGluZyB3aXRoIHRoaXMgYXMgdGhlIG9u bHkgb3B0aW9uLg0KDQpJdCBhbHNvLCBJIHRoaW5rLCBpcyBicm9rZW4gaW4gdGhhdCB0aGVyZSBp cyBubyBpbmRpY2F0aW9uIG9mIGhvdyBhbmQgd2hlbiB0aGVzZSBwYXRocyBhcmUgZXhwaXJlZC4g VGhpcyBhbG9uZSBJIHRoaW5rIHJlcXVpcmVzIGEgbmV3IGRyYWZ0Lg0KDQpJbiBmYWN0LCBpbiB0 aGUgcHJldmlvdXMgcmV2aXNpb24gKC0wNiksIHRoZXJlIGlzIGEgdmFsaWQgdGltZSBmaWVsZCBp biB0aGUgbXVsdGktcGF0aCByb3V0aW5nIHNldC4gQnV0IGl0J3MgcmVtb3ZlZCB0byBtYXRjaCBS RkM3MTgxLXN0eWxlIGJhc2VkIG9uIHRoZSBjb21tZW50cyByZWNlaXZlZCAoYmVjYXVzZSBSb3V0 aW5nIFNldCBpbiBSRkM3MTgxIGlzIG5vdCBiYXNlZCBvbiB0aW1lci1iYXNlZCBleHBpcmF0aW9u IGVpdGhlcikuIEFsbCB0aGUgdHVwbGVzIGluIHRoZSBNdWx0aS1wYXRoIFJvdXRpbmcgU2V0IHdp bGwgYmUgcmVtb3ZlZCB3aGVuZXZlciB0aGVyZSBpcyBuZWVkIHRvIHVwZGF0ZSB0aGUgT0xTUnYy IFJvdXRpbmcgU2V0LiBUaGlzIGNhbiBtYWtlIGl0IG1vcmUgcmVhY3RpdmUgdG8gdG9wb2xvZ3kg Y2hhbmdlcy4NCldlIHdpbGwgY2xhcmlmeSBpdCBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KWWVz LCBpdCBuZWVkcyBjbGFyaWZpY2F0aW9uIGhvd2V2ZXIgdGhlIHNldCBpcyBjcmVhdGVkLCBwcm9h Y3RpdmVseSBvciByZWFjdGl2ZWx5Lg0KDQpCdXQgdGhlcmXigJlzIG1vcmUuIElmIHByb2FjdGl2 ZSwgd2hlbiBpdCBleHBpcmVzLCBpdCBhY3R1YWxseSBpcyByZXBsYWNlZC4gKFRoZSBSb3V0aW5n IFNldCBpbiBPTFNSdjIgaXMgZGVzY3JpYmVkIGFzIHJlY2FsY3VsYXRlZCwgYnV0IG9mIGNvdXJz ZSBpbnRlbGxpZ2VudCBkaWZmZXJlbnRpYWwgdXBkYXRlIGlzIG5vdCBqdXN0IGFsbG93ZWQgYnV0 IGEgZ29vZCBpZGVhLikgQnV0IHJlYWN0aXZlPyBBcmUgeW91IGdvaW5nIHRvIHJlbW92ZSBpdCBh bmQgcmUtdHJpZ2dlciBpdHMgY2FsY3VsYXRpb24gZnJvbSBJUD8gT3IgaG93IG90aGVyd2lzZSB0 byBkZWNpZGUgd2hlbiB0byBzdG9wIHJlY2FsY3VsYXRpbmcgaXQ/DQpBbmQgYmVmb3JlIHRoYXQg ZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIGEgcmVhY3RpdmUgbWVjaGFuaXNtIHRoYXQgT0xTUnYyIG90 aGVyd2lzZSBkb2VzbuKAmXQgaGF2ZSBpcyBhY2NlcHRhYmxlLiAoSSBkb27igJl0IHRoaW5rIGl0 IGlzLikNCg0KUGVyc29uYWxseSwgSSBkb24ndCBzZWUgd2h5IGl0J3Mgbm90IGFjY2VwdGFibGUu IEhlcmUgSSBqdXN0IHdhbnQgdG8gbm90ZSB0aGF0IHRoaXMgaXMgYW4gZXhwZXJpbWVudGFsIGRy YWZ0LiBBcyBmYXIgYXMgSSBjYW4gc2VlLCBpZiB3ZSBoYXZlOg0KDQogICAtIGEgY2xlYXIgc3Bl Y2lmaWNhdGlvbg0KICAgLSBhIG1lY2hhbmlzbSB0aGF0IGNhbiBicmluZyBwb3RlbnRpYWwgcGVy Zm9ybWFuY2UgYmVuZWZpdCBhbmQgd29uJ3QgYnJlYWsgZXhpc3RlZCBuZXR3b3Jrcw0KICAgLSBz b21lIHNpbXVsYXRpb24gc3R1ZHkgYW5kIGltcGxlbWVudGF0aW9uIHRoYXQgcHJvdmUgdGhlIGlk ZWEgYWN0dWFsbHkgd29ya3MgYW5kIGNhbiBiZSBpbXBsZW1lbnRlZCAodGhlIGltcGxlbWVudGF0 aW9uIGlzIGV2ZW4gbm90IG1hbmRhdG9yeSB0byBzdGFuZGFyZCB0cmFjayBwcm90b2NvbCAtLSBh bHRob3VnaCBJIHRoaW5rIGl0J3Mgbm90IGEgZ29vZCBwb2xpY3kpDQogICAtIHBlb3BsZSBpbnRl cmVzdGVkIGluIHRoZSBpZGVhDQoNCndlIGFscmVhZHkgaGF2ZSBnb29kIHJlYXNvbiB0byBtb3Zl IGFoZWFkPw0KDQpDTUQ+IEkgZG9u4oCZdCBhZ3JlZS4gQSBzcGVjaWZpY2F0aW9uIGZpbGxzIGEg c3BhY2UuIEEgcG9vciBzcGVjaWZpY2F0aW9uIGlzIGhhcmQgdG8gcHVzaCBhc2lkZSBpZiBhIGJl dHRlciBvbmUgY29tZXMgYWxvbmcuIEFuZCBJIHRoaW5rIGEgbWFuZGF0b3J5IHJlYWN0aXZlIG1l Y2hhbmlzbSBpbiBhIG11bHRpcGF0aCBPTFNydjIgaXMgcG9vci4gQW5kIGl04oCZcyBlYXNpbHkg YWRkcmVzc2VkLCBkZWZpbmUgaG93IHlvdSBjYWxjdWxhdGUgaXQsIG1ha2UgdGhlIG5vcm0gdGhh dCB5b3UgbWFpbnRhaW4gKGFzIHRoZSBub3JtYWwgUm91dGluZyBTZXQpIGJ1dCAoaWYgeW91IHdh bnQgdG8pIGFsbG93IGEgcmVhY3RpdmUgYWx0ZXJuYXRpdmUgKHdoZXJlIHlvdSBjYW4gc2VuZCBy YXRoZXIgdGhhbiBkcm9wIC0gSSBzZWUgbm8gcmVhc29uIHRvIGRyb3AgLSB1c2luZyB0aGUgc3Rh bmRhcmQgUm91dGluZyBTZXQgaW4gdGhlIGludGVyaW0uDQoNCknigJltIG5vdCBhcyBmYW1pbGlh ciBhcyBJIHNob3VsZCBiZSB3aXRoIGxvb3NlIHNvdXJjZSByb3V0aW5nLiBHaXZlbiB0aGF0IHRo aXMgcHJvdG9jb2wgYWxsb3dzIHJvdXRlcyBvZiBub24tbWluaW11bSBtZXRyaWMsIGlzIHRoZXJl IGFueSBwb3NzaWJpbGl0eSBvZiB0aGUgaW50ZXJhY3Rpb24gb2YgdGhlIHR3byBhbGxvd2luZyBs b29waW5nLCBlc3BlY2lhbGx5IHdpdGggZGlmZmVyZW50IHJvdXRlcnMgaGF2aW5nIHBvc3NpYmx5 IGRpZmZlcmVudCB2aWV3cyBvZiB0aGUgdG9wb2xvZ3k/DQoNCldoZW4gbG9vc2Ugc291cmNlIHJv dXRpbmcgaXMgdXNlZCwgdGhlIGZvcndhcmRpbmcgZGVjaXNpb24gaXMgYmFzZWQgb24gdGhlIGZv cndhcmRpbmcgdGFibGUgZ2VuZXJhdGVkIGJ5IE9MU1J2Mi4gU28gaWYgdGhlcmUgaXMgYSBsb29w LCBpdCdzIGEgbG9vcCBpbiBPTFNSdjIgKHdoaWNoIGlzIHBvc3NpYmxlLCBkdWUgdG8gYXR0YWNr cyBvciBoaWdoIGR5bmFtaWMgdG9wb2xvZ3kpLg0KDQpDTUQ+IFRoYXTigJlzIG9uZSBvZiB0aG9z ZSBub24tcHJvb2YgYXJndW1lbnRzIHRoYXQgSeKAmW0gbm90IHN1cmUgb2YuIEkgY2Fu4oCZdCBz ZWUgYW4gaW5maW5pdGUgbG9vcCwgYnV0IHRoZSBzbGFjayBpbiB0aGUgcHJvY2VzcyBtZWFucyBz dXBwb3NlIHlvdSBoYXZlIEEgLSBCIC0gQyAtIEQgLSBFIGxvb3NlbHkgcm91dGVkLCBhbmQgbm93 IHlvdSBuZWVkIHRvIGdvIGZyb20gQiB0byBDLiBJcyBpdCBwb3NzaWJsZSBmb3IgRCB0byBiZSBv biB0aGUgc2hvcnRlc3QgcGF0aCBmcm9tIEIgdG8gQz8NCg0KU29tZSBzb3J0IG9mIHByb29mICh3 aGljaCBtaWdodCBhbHJlYWR5IGV4aXN0KSB3b3VsZCBiZSBhIGdvb2QgaWRlYSBoZXJlLiBJbmNp ZGVudGFsbHkgd2h5IGRvZXMgdGhlIG11bHRpcGxpY2F0aXZlIGZhY3RvciBvbiByb3V0ZSBtZXRy aWNzIChDVVRPRkZfUkFUSU8pIGhhdmUgdG8gYmUgc3RyaWN0bHkgZ3JlYXRlciB0aGFuIG9uZT8g T25lIHNob3VsZCB3b3JrLg0KDQpUaGUgZGVzY3JpcHRpb24gb2YgdGhlIG11bHRpcGF0aCBEaWpr c3RyYSBkb2VzbuKAmXQgcmVhbGx5IGV4cGxhaW4gZnAgYW5kIGZlLiBXaXRoIHRoZSBhcHBlbmRp eCBvbmUgYmVnaW5zIHRvIGdldCBhbiBpZGVhLCBidXQgdGhlIG1haW4gdGV4dCBzaG91bGQgbm90 IGRlcGVuZCBvbiBhbiBhcHBlbmRpeCBpbiB0aGF0IHdheS4gQW5kIHRob3NlIGFyZSBkZWZpbmVk IHBhcmFtZXRlcnMsIG5vdCBhbiBleGFtcGxlLg0KDQp3aWxsIGNsYXJpZnkgdGhlIGRlc2NyaXB0 aW9uLg0KDQphbmQgdGhhbmtzIGFnYWluIGZvciB0aGUgY29tbWVudHMuDQoNCnJlZ2FyZHMNCg0K SmlhemkNCg0KDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBF bmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUy ODAlMjkxMjQ1JTIwMjQyMTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208 bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBs aWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRv dywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRw Oi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpS ZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5 LCBHVTIgN1lQDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBw bGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLg0K WW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNj bG9zZSBvcg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B73A3GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db21tZW50cyBDTUQmZ3Q7IGJl bG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9v OnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+ Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0K QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFu PjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj N0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3 RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwv Yj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1z Zm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00y IDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBz dHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Ug TGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0 NTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4Qjky Ij5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3Vy cmV5LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHlpLmppYXppQGdtYWlsLmNvbSBbbWFpbHRvOnlpLmpp YXppQGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmlhemkgWUk8YnI+DQo8Yj5TZW50 OjwvYj4gMjMgTWF5IDIwMTYgMjM6MTA8YnI+DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJpc3Rv cGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW21hbmV0XSBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDg8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0 IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi IHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3Jv dW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioq KiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBm cm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFy dG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxs eSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2ht ZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1h dGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJv bmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91 IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLA0KIGNsaWNrIDxhIGhyZWY9 Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nw b3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+PC9l bT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xs b3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3Jr L3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91 cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9p PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBD aHJpcywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBjaGVjayBteSByZXBs eSBpbmxpbmU6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBNb24sIE1heSAyMywgMjAxNiBhdCAyOjU1IFBNLCBEZWFybG92ZSwgQ2hyaXN0b3Bo ZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t IiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5XYXMgYXdheSBsYXN0IHdlZWssIGJ1dCBtYW5hZ2VkIHRvIHJlYWQgdGhyb3VnaCBhbmQgcmVk LWluayB0aGUgbXVsdGlwYXRoIGRyYWZ0LiBJIGhhdmUgc29tZSBtb3JlIGRldGFpbGVkIG5vdGVz IG9uIGl0LCBidXQgaGVyZSAtIGFuZCBhbGwgSeKAmWxsIGdldCB0byByaWdodCBub3cgLSBhcmUg bXkgaGVhZGxpbmUNCiBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkVkaXRv cmlhbGx5LCBpZiB0aGlzIGNhbWUgZnJvbSB0aGUgdXN1YWwgT0xTUnYyIGF1dGhvcnMsIHdl4oCZ ZCBiZSBkb2luZyBzb21lIHdvcmsgdG8gbWFrZSBpdCBhIGJldHRlciBmaXQgdG8gdGhlIHN0eWxl IG9mIHRoZSByZXN0IG9mIHRoZSBPTFNSdjIgc3VpdGUuIEl04oCZcyBub3QgYmFkLCBpdCBqdXN0 IGNvdWxkDQogYmUgYSBiaXQgYmV0dGVyLiBGb3IgZXhhbXBsZSB3aGF0IGFyZSBsaXN0ZWQgYXMg SW5mb3JtYXRpb24gQmFzZXMgYXJlbuKAmXQsIHRoZXkgYXJlIFByb3RvY29sIFNldHMuIFRvZ2V0 aGVyIHRoZXkgbWlnaHQgZm9ybSBhIG5ldyBJbmZvcm1hdGlvbiBCYXNlLCBvciBiZSBhZGRlZCB0 byBvbmUuIEFuZCBtb3JlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHlvdSBtaWdodCBoYXZlIG5vdGljZWQsIHdlIHRyeSB0 byBtYWtlIHRoZSBzdHlsZSBmaXQgdG8gdGhlIE9MU1J2Mi1yZWxhdGVkIFJGQ3MuIElmIHlvdSBo YXZlIG1vcmUgc3BlY2lmaWMgY29tbWVudHMsIHdlIHdvdWxkIGdsYWQgdG8gbWFrZSBpdCBiZXR0 ZXIuIE9mIGNvdXJzZSwgd2Ugd2lsbCBjaGVjayB0aGUgc3R5bGUgYnkgb3Vyc2VsdmVzIGFsc28u Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DTUQmZ3Q7IExhdGVyIGZvciB0aGlzIG9u ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoZXJlIGFyZSBhbHNvIHZhcmlvdXMgb3RoZXIgcG9pbnRzIHRoYXQg SeKAmWQgbWFrZS4gRm9yIGV4YW1wbGUsIGl0IHNheXMgbm90IGp1c3QgZm9yIGhvcCBjb3VudC4g R2l2ZW4gdGhhdCBPTFNSdjIgaXMgbm90IGp1c3QgZm9yIGhvcCBjb3VudCwgSSB3b3VsZG7igJl0 IGVtcGhhc2lzIHRoaXMuIEFuZCBJIGRvbuKAmXQNCiBrbm93IHdoeSBNUC1PTFNSdjIgaXMgaW5k aWNhdGVkIGFzIGJlaW5nIHN1aXRhYmxlIGVzcGVjaWFsbHkgZm9yIGxvdyBkYXRhIHJhdGUgbGlu a3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVjYXVzZSB0aGUgc3BlY2lmaWNhdGlvbiB1c2VzIHBh cmFsbGVsIHBhdGhzLCB3aGljaCBjYW4gcHJvdmlkZSBoaWdoZXIgYWdncmVnYXRlZCB0aHJvdWdo cHV0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5DTUQmZ3Q7IE5vdCBjb252aW5jZWQgYnkgdGhhdCBhcmd1bWVudC4gWW91 4oCZcmUgZ29pbmcgdG8gZ2FpbiBhIGZhY3RvciBvZiBtYXliZSB0d28gb3IgdGhyZWUgYXQgbW9z dCAoYW5kIG9ubHkgaWYgdGhlIG5ldHdvcmsgaXMgZGlmZmVyZW50aWFsbHkgbG9hZGVkIC0gYXQg d29yc3QNCiB5b3UgbG9zZSwgbm90IGdhaW4pIHdoZXJlYXMgd2hlbiBJIHNlZSBsb3cgZGF0YSBy YXRlIHBhdGhzLCB0aGF0IGNhbiB2YXJ5IGJ5IG9yZGVycyBvZiBtYWduaXR1ZGUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UZWNobmljYWxseSwgbXkgZmlyc3QgaXNzdWUgaXMgdGhhdCBPTFNSdjIgZGlzdHJpYnV0 ZXMgYSBwYXJ0aWFsIHRvcG9sb2d5LCBzbyB0aGlzIGlzIHdvcmtpbmcgYXQgYSBkaXNhZHZhbnRh Z2UuIE9LLCBidXQgdGhpcyBpc27igJl0IGRpc2N1c3NlZCwgYW5kIC0gd2l0aCB0aGUgb25lIGV4 Y2VwdGlvbiBvZiBwaWNraW5nDQogTVBScyAtIHRyYWRlb2ZmcyBvZiB0aGUgaW5jb21wbGV0ZW5l c3Mgb2YgdGhlIHRvcG9sb2d5IGFuZCBvdmVyaGVhZHMgYXJlbuKAmXQgZXZlbiBkaXNjdXNzZWQu IEZvciBhIHN0YXJ0LCBUQyBtZXNzYWdlcyBjb250YWluIGFkdmVydGlzZWQgbmVpZ2hib3Vycy4g QWR2ZXJ0aXNlZCBuZWlnaGJvdXJzIG11c3QgaW5jbHVkZSBhbGwgTVBSIHNlbGVjdG9ycywgYnV0 IG1heSBpbmNsdWRlIG1vcmUgbmVpZ2hib3VycyAtIHVwIHRvIGFsbCBuZWlnaGJvdXJzLg0KIEkg d291bGQgZXhwZWN0IGEgZGlzY3Vzc2lvbiBvZiB0aGlzLiAoSeKAmW0gYWxzbyBub3QgYWN0dWFs bHkgc3VyZSBob3cgZ29vZCB0aGUgYWx0ZXJuYXRpdmUgTVBSIGhldXJpc3RpY3MgYXJlLCB0aGF0 4oCZcyBtZSBuZWVkaW5nIHRvIHJlYWQgYW5kIHRoaW5rIG1vcmUuKTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIGEgcHVyZSBNUC1PTFNSdjIgbmV0d29yaywgbm8gbW9kaWZpY2F0aW9uIGlzIHJlcXVp cmVkIHJlZ2FyZGluZyB0aGUgTVBSIHNlbGVjdGlvbi4gQmVjYXVzZSB0aGUgcm91dGVycyBjaG9v c2UgTVBScyBpbmRlcGVuZGVudGx5LCBhbmQgdGhlIE1QUi1zZWxlY3Rpb24gaXMgbm9uLW9wdGlt YWwsIHdlIGNhbiBvYnRhaW4gbXVsdGlwbGUgcGF0aHMgaW4gbW9zdCBjYXNlcyB0aGFua3MgdG8g dGhlIHRvcG9sb2d5DQogcmVkdW5kYW5jeS4gVGhpcyBoYXMgYmVlbiBwcm92ZW4gaW4gYm90aCBz aW11bGF0aW9uIHN0dWR5IGFuZCBmaWVsZCB0ZXN0cyB3aXRoIHZhcmlvdXMgbm9kZSBkZW5zaXRp ZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkNNRCZndDsgUmVmZXJlbmNlcz8gQW5kIGV2ZW4gaWYgc28sIEkgd291bGQg ZXhwZWN0IGEgZGlzY3Vzc2lvbiBvZiB0aGUgc3ViamVjdC4gQW5kIHRoYXQgc3RpbGwgZG9lc27i gJl0IGFkZHJlc3MgdGhlIGFkdmVydGlzZWQgbmVpZ2hib3VycyBpc3N1ZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGRvbuKAmXQgdW5kZXJzdGFuZCAoSSBtYXkgaGF2ZSBtaXNzZWQpIGhvdyBTUl9UQ19J TlRFUlZBTCBpcyB1c2VkLiBCdXQgdGhlIGRlc2NyaXB0aW9uIGluIDUuMSBpc27igJl0IGNsZWFy LiBXaHkgd291bGQgd2UgaGF2ZSBzZXBhcmF0ZSBUQyBtZXNzYWdlcz8gQW5kIHdoeSB3b3VsZCBN UCBiZSBwcmVwYXJlZCB0byBkbyBhbnl0aGluZyB0ZW4gdGltZXMgc2xvd2VyPzxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGlzIGlzIHRvIGRlYWwgd2l0aCB0aGUgT0xTUnYyL01QLU9MU1J2MiBtaXhlZCBuZXR3b3Jr LiBBcyB3ZSBtZW50aW9uZWQgaW4gb3VyIHByZXZpb3VzIHBvc3QsIGFuIE1QLU9MU1Igcm91dGVy IGNhbiBiZSByZWNvZ25pemVkIGFzIHNvdXJjZS1lbmFibGVkIHVubGVzcyBpdCBnZW5lcmF0ZXMg YSBIRUxMTyBvciBUQyBtZXNzYWdlLiBTbyB3aGF0IHdlIGRvIGlzOiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDstIE1QLU9MU1IgZW5hYmxlZCByb3V0ZXJzIE1VU1QgZ2VuZXJhdGUgVEMgbWVzc2FnZXMg ZXZlbiBpdCdzIG5vdCByZXF1aXJlZCB0byBkbyBzbyBhY2NvcmRpbmcgdG8gbm9ybWFsIE9MU1Ig cHJvY2VzcywgYnV0IHdpdGggbG9uZ2VyIGludGVydmFsLiBUaGlzIGlzIGJlY2F1c2UgdGhlIGNo YW5nZSBmcm9tIE1QLU9MU1IgZW5hYmxlZCB0byBPTFNSLW9ubHkgcm91dGVyIGlzIHZlcnkgcmFy ZSBjb21wYXJlZA0KIHRvIHRvcG9sb2d5IGNoYW5nZXMuIFRoZSBjb3JyZXNwb25kaW5nIFNSX09M U1JfSE9MRF9USU1FIHdpbGwgYmUgc2V0IHRvIGxvbmdlciB2YWx1ZSBhbHNvLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwOyAtIER1cmluZyByb3V0aW5nIE1QUiBzZWxlY3Rpb24sIGFuIE1QLU9MU1IgZW5hYmxlZCBy b3V0ZXIgU0hPVUxEIGJlIGZpcnN0bHkgY29uc2lkZXJlZC4gVGhlIG51bWJlciBvZiBNUC1PTFNS IGVuYWJsZWQgTVBScyBNVVNUIGJlIGVxdWFsIG9yIGdyZWF0ZXIgdGhhbiBOVU1CRVJfT0ZfUEFU SFMsIHByb3ZpZGluZyB0aGVyZSBhcmUgZW5vdWdoIE1QLU9MU1Igc3ltbWV0cmljIG5laWdoYm9y cy4gT3IgZWxzZSwNCiBhbGwgdGhlIE1QLU9MU1Igcm91dGVycyBhcmUgc2VsZWN0ZWQgYXMgTVBS LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DTUQmZ3Q7IE5vdCBoYXBw eSB3aXRoIHRoYXQuIFRoYXQgYXNzdW1lcyBpbiBlZmZlY3QgdGhhdCBtdWx0aXBhdGggcm91dGVz IGFyZSBtb3JlIHN0YWJsZSAtIGJlY2F1c2UgdGhhdOKAmWQgd2hhdCBzZW5kaW5nIHRlbiB0aW1l cyBsZXNzIG9mdGVuIG1lYW5zLiBBbmQgaWYgeW91IGFyZSBzZW5kaW5nIHRlbiB0aW1lcyBsZXNz IG9mdGVuLCB0aGF0IHdpbGwgcmVxdWlyZQ0KIHRlbiB0aW1lcyB0aGUgdmFsaWRpdHkgdGltZS4g V2hpY2ggd2lsbCBjYXVzZSB0aG9zZSBsaW5rcyB0byBoYW5nIGFyb3VuZCBsb25nZXIsIGFuZCB3 aWxsIGJlIHVzZWQgYnkgbm9uLU1QIHJvdXRlcnMgaW4gdGhlIHNhbWUgd2F5LiAoSXTigJlzIGV2 ZW4gcG9zc2libGUgdGhhdCBhIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiBtaWdodCBjaG9vc2Ug dG8gcHJlZmVyZW50aWFsbHkgdXNlIGxpbmtzIHdpdGggbG9uZ2VyIHZhbGlkaXR5IHRpbWVzLCBh bGwNCiBlbHNlIGJlaW5nIGVxdWFsLiBJ4oCZdmUgbmV2ZXIgdHJpZWQgdGhhdCwgYnV0IGl04oCZ cyBhbiBvYnZpb3VzIHBvc3NpYmlsaXR5IGluIHNvbWUgaGV0ZXJvZ2VuZW91cyBuZXR3b3Jrcy4p IElmIHRlbiB0aW1lcyBsb25nZXIgaXMgT0sgZm9yIHNvbWUgbGlua3MsIHdoeSBub3QgYWxsPyBJ IHRoaW5rIHRoZXJl4oCZcyBhIHByb2JsZW0gaGVyZSAtIGhvdyBtdWNoIHdvcmsgd2l0aCBoaWdo bHkgbW9iaWxlIG1peGVkIG5ldHdvcmtzIGhhcyBiZWVuIGRvbmU/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZ dmUgYmVlbiBjcml0aWNhbCBvZiBBT0RWdjIgdW5kZXJzcGVjaWZ5aW5nIGludGVyYWN0aW9uIHdp dGggSVAuIEnigJltIGdvaW5nIHRvIG1ha2UgdGhlIHNhbWUgY3JpdGljaXNtIGhlcmUsIGdpdmVu IHRoZSBzdWdnZXN0aW9uIG9mIGEgcmVhY3RpdmUgbXVsdGktcGF0aCByb3V0ZSBkZXRlcm1pbmF0 aW9uLiBJ4oCZbQ0KIGFjdHVhbGx5IG5vdCBrZWVuIG9uIHRoYXQgaWRlYSBhdCBhbGwsIEkgdGhp bmsgaXQgbmVlZHMgbW9yZSBkaXNjdXNzaW9uLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgTVAt T0xTUiBpcyBhIGJpdCBkaWZmZXJlbnQgZnJvbSBBT0RWdjIgLS0gdGhlIHJvdXRlIGNhbGN1bGF0 aW9uIGlzIGxvY2FsLiBJdCBkb2Vzbid0IHJlcXVpcmUgRFNSL0FPRFYtbGlrZSByb3V0ZSBkaXNj b3Zlcnkvcm91dGUgcmVwbHkgKHdoaWNoIGNhbiBoYXZlIGxvbmcgZGVsYXkpLiBUaGVyZWZvcmUs IG5vIGJ1ZmZlciAob3IgdmVyeSBsaXR0bGUgYnVmZmVyKSBpcyByZXF1aXJlZDogdGhlIHBhY2tl dA0KIGlzIGVpdGhlciBzZW50IG91dCBvciBkcm9wcGVkLiBJIHRoaW5rIHRoZXJlIGlzIG5vIG5l ZWQgdG8gZ28gdG8gZGV0YWlscyBvbiBob3cgdG8gdHJpZ2dlciB0aGUgcm91dGUgY2FsY3VsYXRp b24sIHdoaWNoIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiBmb3IgdGhlIHNvdXJj ZSByb3V0aW5nIHBhcnQsIGl0J3MganVzdCBzdGFuZGFyZCBJUCByb3V0aW5nLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5D TUQmZ3Q7IE5vLCBpdOKAmXMgaW50cm9kdWNlZCBzb21ldGhpbmcgbmV3IHRvIE9MU1J2MiwgdGhl IG5lZWQgdG8gYmUgdHJpZ2dlcmVkIGJ5IElQLiBTb21lYm9keSAoSGVubmluZz8pIGNyaXRpY2lz aW5nIEFPRFZ2MiBtYWRlIHRoZSBvYnNlcnZhdGlvbiB0aGlzIGlzbuKAmXQgYWN0dWFsbHkNCiBl YXN5IHRvIGRvLiBBbmQgaXTigJlzIG5ldyB0byBPTFNSdjIsIGFuZCB1bm5lY2Vzc2FyeS4gSeKA mW0gc3Ryb25nbHkgYWdhaW5zdCB0aGlzIGFzIGEgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5v dGUgdGhhdCBhcyB0aGlzIGlzIGxvY2FsLCB5b3UgY291bGQgY2hvb3NlIHRvIGRvIHRoaXMgbG9j YWxseSBpZiB5b3Ugd2FudGVkIHRvIGFuZCBzdGlsbCBpbnRlcm9wZXJhdGUuIEkgd291bGRu4oCZ dCBiZSBhcyBzZXQgYWdhaW5zdCB0aGlzIGFzIGFuIG9wdGlvbiBpbiBhDQogaGlnaGx5IHJlc291 cmNlIGxpbWl0ZWQgcm91dGVyLiBCdXQgYXMgdGhlIG9ubHkgc3BlY2lmaWNhdGlvbiwgdGhhdCBt dXN0IGJlIGRvbmUgdGhpcyB3YXk/IE5vLiBJ4oCZbSBhZ2FpbnN0IHRoaXMgZHJhZnQgcHJvY2Vl ZGluZyB3aXRoIHRoaXMgYXMgdGhlIG9ubHkgb3B0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkl0IGFsc28sIEkgdGhpbmssIGlzIGJyb2tlbiBpbiB0aGF0IHRoZXJlIGlzIG5vIGluZGlj YXRpb24gb2YgaG93IGFuZCB3aGVuIHRoZXNlIHBhdGhzIGFyZSBleHBpcmVkLiBUaGlzIGFsb25l IEkgdGhpbmsgcmVxdWlyZXMgYSBuZXcgZHJhZnQuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBm YWN0LCBpbiB0aGUgcHJldmlvdXMgcmV2aXNpb24gKC0wNiksIHRoZXJlIGlzIGEgdmFsaWQgdGlt ZSBmaWVsZCBpbiB0aGUgbXVsdGktcGF0aCByb3V0aW5nIHNldC4gQnV0IGl0J3MgcmVtb3ZlZCB0 byBtYXRjaCBSRkM3MTgxLXN0eWxlIGJhc2VkIG9uIHRoZSBjb21tZW50cyByZWNlaXZlZCAoYmVj YXVzZSBSb3V0aW5nIFNldCBpbiBSRkM3MTgxIGlzIG5vdCBiYXNlZCBvbiB0aW1lci1iYXNlZCBl eHBpcmF0aW9uDQogZWl0aGVyKS4gQWxsIHRoZSB0dXBsZXMgaW4gdGhlIE11bHRpLXBhdGggUm91 dGluZyBTZXQgd2lsbCBiZSByZW1vdmVkIHdoZW5ldmVyIHRoZXJlIGlzIG5lZWQgdG8gdXBkYXRl IHRoZSBPTFNSdjIgUm91dGluZyBTZXQuIFRoaXMgY2FuIG1ha2UgaXQgbW9yZSByZWFjdGl2ZSB0 byB0b3BvbG9neSBjaGFuZ2VzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd2lsbCBjbGFyaWZ5IGl0IGluIHRoZSBuZXh0IHJldmlz aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5ZZXMsIGl0IG5lZWRzIGNsYXJpZmljYXRpb24gaG93ZXZlciB0aGUgc2V0 IGlzIGNyZWF0ZWQsIHByb2FjdGl2ZWx5IG9yIHJlYWN0aXZlbHkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgdGhl cmXigJlzIG1vcmUuIElmIHByb2FjdGl2ZSwgd2hlbiBpdCBleHBpcmVzLCBpdCBhY3R1YWxseSBp cyByZXBsYWNlZC4gKFRoZSBSb3V0aW5nIFNldCBpbiBPTFNSdjIgaXMgZGVzY3JpYmVkIGFzIHJl Y2FsY3VsYXRlZCwgYnV0IG9mIGNvdXJzZSBpbnRlbGxpZ2VudA0KIGRpZmZlcmVudGlhbCB1cGRh dGUgaXMgbm90IGp1c3QgYWxsb3dlZCBidXQgYSBnb29kIGlkZWEuKSBCdXQgcmVhY3RpdmU/IEFy ZSB5b3UgZ29pbmcgdG8gcmVtb3ZlIGl0IGFuZCByZS10cmlnZ2VyIGl0cyBjYWxjdWxhdGlvbiBm cm9tIElQPyBPciBob3cgb3RoZXJ3aXNlIHRvIGRlY2lkZSB3aGVuIHRvIHN0b3AgcmVjYWxjdWxh dGluZyBpdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIGJlZm9yZSB0aGF0IGRpc2N1c3Np b24gb24gd2hldGhlciBhIHJlYWN0aXZlIG1lY2hhbmlzbSB0aGF0IE9MU1J2MiBvdGhlcndpc2Ug ZG9lc27igJl0IGhhdmUgaXMgYWNjZXB0YWJsZS4gKEkgZG9u4oCZdCB0aGluayBpdCBpcy4pPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UGVyc29uYWxseSwgSSBkb24ndCBzZWUgd2h5IGl0J3Mgbm90IGFj Y2VwdGFibGUuIEhlcmUgSSBqdXN0IHdhbnQgdG8gbm90ZSB0aGF0IHRoaXMgaXMgYW4gZXhwZXJp bWVudGFsIGRyYWZ0LiBBcyBmYXIgYXMgSSBjYW4gc2VlLCBpZiB3ZSBoYXZlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 LSBhIGNsZWFyIHNwZWNpZmljYXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDstIGEgbWVjaGFuaXNtIHRoYXQgY2FuIGJy aW5nIHBvdGVudGlhbCBwZXJmb3JtYW5jZSBiZW5lZml0IGFuZCB3b24ndCBicmVhayBleGlzdGVk IG5ldHdvcmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7LSBzb21lIHNpbXVsYXRpb24gc3R1ZHkgYW5kIGltcGxlbWVudGF0 aW9uIHRoYXQgcHJvdmUgdGhlIGlkZWEgYWN0dWFsbHkgd29ya3MgYW5kIGNhbiBiZSBpbXBsZW1l bnRlZCAodGhlIGltcGxlbWVudGF0aW9uIGlzIGV2ZW4gbm90IG1hbmRhdG9yeSB0byBzdGFuZGFy ZCB0cmFjayBwcm90b2NvbCAtLSBhbHRob3VnaCBJIHRoaW5rIGl0J3Mgbm90IGEgZ29vZCBwb2xp Y3kpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7LSBwZW9wbGUgaW50ZXJlc3RlZCBpbiB0aGUgaWRlYTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53ZSBhbHJlYWR5IGhhdmUg Z29vZCByZWFzb24gdG8gbW92ZSBhaGVhZD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q01EJmd0OyBJIGRvbuKAmXQgYWdy ZWUuIEEgc3BlY2lmaWNhdGlvbiBmaWxscyBhIHNwYWNlLiBBIHBvb3Igc3BlY2lmaWNhdGlvbiBp cyBoYXJkIHRvIHB1c2ggYXNpZGUgaWYgYSBiZXR0ZXIgb25lIGNvbWVzIGFsb25nLiBBbmQgSSB0 aGluayBhIG1hbmRhdG9yeSByZWFjdGl2ZQ0KIG1lY2hhbmlzbSBpbiBhIG11bHRpcGF0aCBPTFNy djIgaXMgcG9vci4gQW5kIGl04oCZcyBlYXNpbHkgYWRkcmVzc2VkLCBkZWZpbmUgaG93IHlvdSBj YWxjdWxhdGUgaXQsIG1ha2UgdGhlIG5vcm0gdGhhdCB5b3UgbWFpbnRhaW4gKGFzIHRoZSBub3Jt YWwgUm91dGluZyBTZXQpIGJ1dCAoaWYgeW91IHdhbnQgdG8pIGFsbG93IGEgcmVhY3RpdmUgYWx0 ZXJuYXRpdmUgKHdoZXJlIHlvdSBjYW4gc2VuZCByYXRoZXIgdGhhbiBkcm9wIC0gSSBzZWUgbm8g cmVhc29uDQogdG8gZHJvcCAtIHVzaW5nIHRoZSBzdGFuZGFyZCBSb3V0aW5nIFNldCBpbiB0aGUg aW50ZXJpbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJltIG5vdCBhcyBmYW1pbGlhciBhcyBJIHNob3VsZCBi ZSB3aXRoIGxvb3NlIHNvdXJjZSByb3V0aW5nLiBHaXZlbiB0aGF0IHRoaXMgcHJvdG9jb2wgYWxs b3dzIHJvdXRlcyBvZiBub24tbWluaW11bSBtZXRyaWMsIGlzIHRoZXJlIGFueSBwb3NzaWJpbGl0 eSBvZiB0aGUgaW50ZXJhY3Rpb24gb2YgdGhlIHR3bw0KIGFsbG93aW5nIGxvb3BpbmcsIGVzcGVj aWFsbHkgd2l0aCBkaWZmZXJlbnQgcm91dGVycyBoYXZpbmcgcG9zc2libHkgZGlmZmVyZW50IHZp ZXdzIG9mIHRoZSB0b3BvbG9neT8NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gbG9vc2Ugc291 cmNlIHJvdXRpbmcgaXMgdXNlZCwgdGhlIGZvcndhcmRpbmcgZGVjaXNpb24gaXMgYmFzZWQgb24g dGhlIGZvcndhcmRpbmcgdGFibGUgZ2VuZXJhdGVkIGJ5IE9MU1J2Mi4gU28gaWYgdGhlcmUgaXMg YSBsb29wLCBpdCdzIGEgbG9vcCBpbiBPTFNSdjIgKHdoaWNoIGlzIHBvc3NpYmxlLCBkdWUgdG8g YXR0YWNrcyBvciBoaWdoIGR5bmFtaWMgdG9wb2xvZ3kpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DTUQmZ3Q7IFRoYXTi gJlzIG9uZSBvZiB0aG9zZSBub24tcHJvb2YgYXJndW1lbnRzIHRoYXQgSeKAmW0gbm90IHN1cmUg b2YuIEkgY2Fu4oCZdCBzZWUgYW4gaW5maW5pdGUgbG9vcCwgYnV0IHRoZSBzbGFjayBpbiB0aGUg cHJvY2VzcyBtZWFucyBzdXBwb3NlIHlvdSBoYXZlIEEgLSBCIC0NCiBDIC0gRCAtIEUgbG9vc2Vs eSByb3V0ZWQsIGFuZCBub3cgeW91IG5lZWQgdG8gZ28gZnJvbSBCIHRvIEMuIElzIGl0IHBvc3Np YmxlIGZvciBEIHRvIGJlIG9uIHRoZSBzaG9ydGVzdCBwYXRoIGZyb20gQiB0byBDPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlNvbWUgc29ydCBvZiBwcm9vZiAod2hpY2ggbWlnaHQgYWxyZWFk eSBleGlzdCkgd291bGQgYmUgYSBnb29kIGlkZWEgaGVyZS4gSW5jaWRlbnRhbGx5IHdoeSBkb2Vz IHRoZSBtdWx0aXBsaWNhdGl2ZSBmYWN0b3Igb24gcm91dGUgbWV0cmljcyAoQ1VUT0ZGX1JBVElP KSBoYXZlIHRvIGJlIHN0cmljdGx5IGdyZWF0ZXINCiB0aGFuIG9uZT8gT25lIHNob3VsZCB3b3Jr LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBtdWx0 aXBhdGggRGlqa3N0cmEgZG9lc27igJl0IHJlYWxseSBleHBsYWluIGZwIGFuZCBmZS4gV2l0aCB0 aGUgYXBwZW5kaXggb25lIGJlZ2lucyB0byBnZXQgYW4gaWRlYSwgYnV0IHRoZSBtYWluIHRleHQg c2hvdWxkIG5vdCBkZXBlbmQgb24gYW4gYXBwZW5kaXggaW4gdGhhdA0KIHdheS4gQW5kIHRob3Nl IGFyZSBkZWZpbmVkIHBhcmFtZXRlcnMsIG5vdCBhbiBleGFtcGxlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPndpbGwgY2xhcmlmeSB0aGUgZGVzY3JpcHRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCB0aGFua3MgYWdhaW4gZm9y IHRoZSBjb21tZW50cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaWF6aTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MDdFN0UiPi0tDQo8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERl YXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUy MCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0 MjE5NDwvYT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6IDwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVj aG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJy Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+ PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50 ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMg Tm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1 cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50IGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQpy ZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhl IHNlbmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55 IG90aGVyIHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B73A3GLKXM0002VGREEN_-- From nobody Tue May 24 15:55:23 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA88112D59C for ; Tue, 24 May 2016 15:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL5lWE2UafJF for ; Tue, 24 May 2016 15:55:18 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEFB12B053 for ; Tue, 24 May 2016 15:55:17 -0700 (PDT) Received: by mail-lb0-x22c.google.com with SMTP id ww9so10106655lbc.2 for ; Tue, 24 May 2016 15:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=wq/TyTsVXISmVTEexW2EJBiF0yW3JPfwXYHbN0akhtU=; b=hsAtMKaeaurPdT7PjZHkmLwdm6zPJqWPvf3einynMiPuL/T6fI8yd6wyzA4a1X4IcH bTdzCfbQhcZoaH8tkPhz+qi1IIx66emVtphkjYPK4JB1BZnZ7IEKQYRIKprme5PEk2Tu UCLugN2OrZd7qqnunfXrhioZMBYWeLBiQYiI4DOuCf90uXA+wbBoOrmn63w+I3f7mgS6 Tevnqr7rnKASCy8kZfdIxT6l6W9fA4yhV+0YPUtFaoFf6GPLc1Y62gMakbGk4wAjl+pV IKUJq/omyWXp1IOMoUQGvUTbUAWDoLZuGX+199ehkteAoPrce2HWy96iNaFvYElKwxD0 tfZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wq/TyTsVXISmVTEexW2EJBiF0yW3JPfwXYHbN0akhtU=; b=FZg7zz/LIaz9M7UQ2pYLrOjPMrFAeA07/mA1jzUgHsFe6uUHTJQXp/W/pnam9F4GGB bD8XIgSkZt0SC7JRsaRwcZPBpty143BHb5j3ewJ3ezvRJIQwX3BoSZvqg9Ky+fujYq/E 9PBWhQFKBq2W6Rr3WzFy7Z9JSKj2YIIF+QSxgHvjV+bnoavhEeL+h+QASgSx+2vdKP5X VA4bDvQ8lzZTbNXvzKnIvA8B2LkRFDpXBN3UWoN48fokG/T5Fr/FrjOYS6UsIBlAgmWp EKvJP5Xx9PBxjAdcSJMhiLsNx7dD499wHDPuk2daFEmLu3oPt9sSAmmh8y67bVDKdfsc cBsA== X-Gm-Message-State: ALyK8tI3UQeRm6uP/0ABf7HAeVEruBYBGDqVAE5rfwERLHEx/D1XT37bw3Gf0a/ISFCxa8MBXanUsmMeOFL2CQ== MIME-Version: 1.0 X-Received: by 10.112.77.39 with SMTP id p7mr163837lbw.39.1464130514498; Tue, 24 May 2016 15:55:14 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.114.77.4 with HTTP; Tue, 24 May 2016 15:55:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 May 2016 00:55:14 +0200 X-Google-Sender-Auth: coJlHYuAav__pmwc6vpGfBbB_-I Message-ID: From: Jiazi YI To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a11c3ad0c38ba9d05339e73b2 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-08 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 22:55:22 -0000 --001a11c3ad0c38ba9d05339e73b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Chris, Please check the reply JY> below: > > > > There are also various other points that I=E2=80=99d make. For example, i= t says > not just for hop count. Given that OLSRv2 is not just for hop count, I > wouldn=E2=80=99t emphasis this. And I don=E2=80=99t know why MP-OLSRv2 is= indicated as > being suitable especially for low data rate links. > > > > Because the specification uses parallel paths, which can provide higher > aggregated throughput. > > > > CMD> Not convinced by that argument. You=E2=80=99re going to gain a facto= r of > maybe two or three at most (and only if the network is differentially > loaded - at worst you lose, not gain) whereas when I see low data rate > paths, that can vary by orders of magnitude. > JY> The metric of the paths are considered in the path calculation. We can expect that the multiple path obtained will not vary that much, and certainly not by orders of magnitude. About differential loading -- sure. It's written as part of the "experiments to be conducted": DRAFT> In some scenarios, weighted scheduling (over different paths) can be considered: for example, the paths with lower metrics (i.e., higher quality) can transfer more datagrams compared to paths with higher metrics. > > Technically, my first issue is that OLSRv2 distributes a partial topology= , > so this is working at a disadvantage. OK, but this isn=E2=80=99t discusse= d, and - > with the one exception of picking MPRs - tradeoffs of the incompleteness = of > the topology and overheads aren=E2=80=99t even discussed. For a start, TC= messages > contain advertised neighbours. Advertised neighbours must include all MPR > selectors, but may include more neighbours - up to all neighbours. I woul= d > expect a discussion of this. (I=E2=80=99m also not actually sure how good= the > alternative MPR heuristics are, that=E2=80=99s me needing to read and thi= nk more.) > > > > In a pure MP-OLSRv2 network, no modification is required regarding the MP= R > selection. Because the routers choose MPRs independently, and the > MPR-selection is non-optimal, we can obtain multiple paths in most cases > thanks to the topology redundancy. This has been proven in both simulatio= n > study and field tests with various node densities. > > > > CMD> References? And even if so, I would expect a discussion of the > subject. And that still doesn=E2=80=99t address the advertised neighbours= issue. > *Some papers from co-authors of the draft:* [1] Multipath optimized link state routing for mobile ad hoc networks J Yi, A Adnane, S David, B Parrein Ad Hoc Networks 9 (1), 28-47 https://hal.archives-ouvertes.fr/hal-00521719/file/MPOLSR_2.pdf [2] Simulation and performance analysis of MP-OLSR for mobile ad hoc networks J Yi, E Cizeron, S Hamma, B Parrein Wireless Communications and Networking Conference, 2008. IEEE WCNC 2008. http://arxiv.org/pdf/0902.4779.pdf [3] Multipath OLSR: simulation and testbed J Yi, S David, HA Adnane, B Parrein, X Lecourtier 5th OLSR Interop/Workshop http://hal.univ-nantes.fr/file/index/docid/424891/filename/Multipath_OLSR_S= imulation_and_Testbed.pdf [4] QOS ENHANCED HYBRID MULTIPATH ROUTING PROTOCOL FOR MOBILE ADHOC NETWORK= S J Yi, B Parrein, D Radu Wireless Personal Multimedia Communications (WPMC), 2011 14th International Symposium on http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D6081479&url=3Dhtt= p%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6081479 *And from other 3rd party researchers, who used tested MP-OLSR and developed extensions based on MP-OLSR:* Experimental performance comparison of single-path and multipath routing in VANETs 2014 IEEE Global Information Infrastructure and Networking Symposium (GIIS) http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=3Dtrue&arnumber=3D= 6934283 QOS ENHANCED HYBRID MULTIPATH ROUTING PROTOCOL FOR MOBILE ADHOC NETWORKS International Journal of Distributed and Parallel Systems3.6 (Nov 2012): 89-105. http://airccse.org/journal/ijdps/papers/3612ijdps08.pdf A multipath routing strategy to prevent flooding disruption attacks in link state routing protocols for MANETs Journal of Network and Computer Applications Volume 36, Issue 2, March 2013, Pages 744=E2=80=93755 http://www.sciencedirect.com/science/article/pii/S1084804512002603 Performance Evaluation of MBA-OLSR Routing Protocol for MANETs Waheb A. Jabbar, Mahamod Ismail, and Rosdiadee Nordin Journal of Computer Networks and Communications Volume 2014 (2014), Article ID 951638 http://www.hindawi.com/journals/jcnc/2014/951638/abs/ An enhanced MP-OLSR protocol for MANETs A Boushaba, A Benabbou, R Benabbou 2014 International Conference on Next Generation Networks and Services (NGNS) http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D6990231&url=3Dhtt= p%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6990231 There are about 200~ citations of [1][2][3][4], so above is far away from a complete list of research related to MP-OLSR. Generally speaking, tests/simulations have been performed from very sparse networks (such 4-node network) to dense and mobile networks. And no issue is reported regarding exploring multiple paths because of OLSR's partial topology. > > > I don=E2=80=99t understand (I may have missed) how SR_TC_INTERVAL is used= . But the > description in 5.1 isn=E2=80=99t clear. Why would we have separate TC mes= sages? And > why would MP be prepared to do anything ten times slower? > > > > This is to deal with the OLSRv2/MP-OLSRv2 mixed network. As we mentioned > in our previous post, an MP-OLSR router can be recognized as source-enabl= ed > unless it generates a HELLO or TC message. So what we do is: > > - MP-OLSR enabled routers MUST generate TC messages even it's not > required to do so according to normal OLSR process, but with longer > interval. This is because the change from MP-OLSR enabled to OLSR-only > router is very rare compared to topology changes. The corresponding > SR_OLSR_HOLD_TIME will be set to longer value also. > > - During routing MPR selection, an MP-OLSR enabled router SHOULD be > firstly considered. The number of MP-OLSR enabled MPRs MUST be equal or > greater than NUMBER_OF_PATHS, providing there are enough MP-OLSR symmetri= c > neighbors. Or else, all the MP-OLSR routers are selected as MPR. > > > > CMD> Not happy with that. That assumes in effect that multipath routes > are more stable - because that=E2=80=99d what sending ten times less ofte= n means. > And if you are sending ten times less often, that will require ten times > the validity time. Which will cause those links to hang around longer, an= d > will be used by non-MP routers in the same way. (It=E2=80=99s even possib= le that a > compliant implementation might choose to preferentially use links with > longer validity times, all else being equal. I=E2=80=99ve never tried tha= t, but > it=E2=80=99s an obvious possibility in some heterogeneous networks.) If t= en times > longer is OK for some links, why not all? I think there=E2=80=99s a probl= em here - > how much work with highly mobile mixed networks has been done? > JY> Let me clarify: The assumption is not multi-path routes are more stable, but simply multi-path routers won't change from a multipath enabled router to multipath disabled router (or very rare). The multipath enabled routers generate TC messages as ordinary OLSRv2 routers. *Additionally*, if those routers didn't generate TC message in certain interval (the longer SR_TC_INTERVAL), those MP-OLSR routers are required to generate TC messages. The latter is more for declaring: hey, I'm multipath enabled! The validity time SR_OLSR_HOLD_TIME is related to identifying the router is multipath enabled or not -- it has nothing to do with link stability. > > > I=E2=80=99ve been critical of AODVv2 underspecifying interaction with IP.= I=E2=80=99m > going to make the same criticism here, given the suggestion of a reactive > multi-path route determination. I=E2=80=99m actually not keen on that ide= a at all, > I think it needs more discussion. > > > > The MP-OLSR is a bit different from AODVv2 -- the route calculation is > local. It doesn't require DSR/AODV-like route discovery/route reply (whic= h > can have long delay). Therefore, no buffer (or very little buffer) is > required: the packet is either sent out or dropped. I think there is no > need to go to details on how to trigger the route calculation, which is > implementation specific. > > Then for the source routing part, it's just standard IP routing. > > > > CMD> No, it=E2=80=99s introduced something new to OLSRv2, the need to be = triggered > by IP. Somebody (Henning?) criticising AODVv2 made the observation this > isn=E2=80=99t actually easy to do. And it=E2=80=99s new to OLSRv2, and un= necessary. I=E2=80=99m > strongly against this as a specification. > > > > Note that as this is local, you could choose to do this locally if you > wanted to and still interoperate. I wouldn=E2=80=99t be as set against th= is as an > option in a highly resource limited router. But as the only specification= , > that must be done this way? No. I=E2=80=99m against this draft proceeding= with this > as the only option. > JY> Although we haven't found proactive algorithms to solve the multipath issue yet, we can make the reactive part optional for further extensibility. > > > It also, I think, is broken in that there is no indication of how and whe= n > these paths are expired. This alone I think requires a new draft. > > > > In fact, in the previous revision (-06), there is a valid time field in > the multi-path routing set. But it's removed to match RFC7181-style based > on the comments received (because Routing Set in RFC7181 is not based on > timer-based expiration either). All the tuples in the Multi-path Routing > Set will be removed whenever there is need to update the OLSRv2 Routing > Set. This can make it more reactive to topology changes. > > We will clarify it in the next revision. > > > > Yes, it needs clarification however the set is created, proactively or > reactively. > > > > But there=E2=80=99s more. If proactive, when it expires, it actually is r= eplaced. > (The Routing Set in OLSRv2 is described as recalculated, but of course > intelligent differential update is not just allowed but a good idea.) But > reactive? Are you going to remove it and re-trigger its calculation from > IP? Or how otherwise to decide when to stop recalculating it? > JY> If reactive, it's simply re-trigger the calculation from IP "on demand". > And before that discussion on whether a reactive mechanism that OLSRv2 > otherwise doesn=E2=80=99t have is acceptable. (I don=E2=80=99t think it i= s.) > > > > Personally, I don't see why it's not acceptable. Here I just want to note > that this is an experimental draft. As far as I can see, if we have: > > > > - a clear specification > > - a mechanism that can bring potential performance benefit and won't > break existed networks > > - some simulation study and implementation that prove the idea actuall= y > works and can be implemented (the implementation is even not mandatory to > standard track protocol -- although I think it's not a good policy) > > - people interested in the idea > > > > we already have good reason to move ahead? > > > > CMD> I don=E2=80=99t agree. A specification fills a space. A poor specifi= cation is > hard to push aside if a better one comes along. And I think a mandatory > reactive mechanism in a multipath OLSrv2 is poor. And it=E2=80=99s easily > addressed, define how you calculate it, make the norm that you maintain (= as > the normal Routing Set) but (if you want to) allow a reactive alternative > (where you can send rather than drop - I see no reason to drop - using th= e > standard Routing Set in the interim. > JY> we agree to keep the specification as extendable as possible. And as mentioned above, we can make the reactive mechanism optional. > > > I=E2=80=99m not as familiar as I should be with loose source routing. Giv= en that > this protocol allows routes of non-minimum metric, is there any possibili= ty > of the interaction of the two allowing looping, especially with different > routers having possibly different views of the topology? > > > > When loose source routing is used, the forwarding decision is based on th= e > forwarding table generated by OLSRv2. So if there is a loop, it's a loop = in > OLSRv2 (which is possible, due to attacks or high dynamic topology). > > > > CMD> That=E2=80=99s one of those non-proof arguments that I=E2=80=99m not= sure of. I can=E2=80=99t > see an infinite loop, but the slack in the process means suppose you have= A > - B - C - D - E loosely routed, and now you need to go from B to C. Is it > possible for D to be on the shortest path from B to C? > JY> It should be very rare. I can *imagine* that might happen for IPv4 networks, if: - The network is big so that loose source routing must be used (more than 10 hops); AND - The the network is highly dynamic that A's local topology map is staled; AND - D accidentally moves to the shortest path from B to C. But I think it won't break anything, but brings temporary performance penalty: - The packet being forwarded will travel more hops, but it can get to the destination eventually. - after the correct topology information is propagated to router A, the problem will disappear automatically. This can also be mitigated by choosing the "key" routers in the loose source routing header carefully: if the routers are more stable and have higher willingness in forwarding the packets, they should be chosen as "key" routers, as specified in the document. cheers Jiazi > > > Some sort of proof (which might already exist) would be a good idea here. > Incidentally why does the multiplicative factor on route metrics > (CUTOFF_RATIO) have to be strictly greater than one? One should work. > > > > The description of the multipath Dijkstra doesn=E2=80=99t really explain = fp and > fe. With the appendix one begins to get an idea, but the main text should > not depend on an appendix in that way. And those are defined parameters, > not an example. > > > > will clarify the description. > > > > and thanks again for the comments. > > > > regards > > > > Jiazi > > > > > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --001a11c3ad0c38ba9d05339e73b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chris,=C2=A0

Please check the reply = JY> below:

=C2=A0

There are also various other points that I=E2=80=99d= make. For example, it says not just for hop count. Given that OLSRv2 is no= t just for hop count, I wouldn=E2=80=99t emphasis this. And I don=E2=80=99t know why MP-OLSRv2 is indicated as being suitable especially for low data = rate links.

=C2=A0

Because the specification uses parallel paths, which= can provide higher aggregated throughput.=C2=A0

=C2=A0

CMD> Not convinced by that argumen= t. You=E2=80=99re going to gain a factor of maybe two or three at most (and= only if the network is differentially loaded - at worst you lose, not gain) whereas when I see low data rate paths, that can vary = by orders of magnitude.


JY> The metric of the paths are considered i= n the path calculation. We can expect that the multiple path obtained will = not vary that much, and certainly not by orders of magnitude.=C2=A0
About differential loading -- sure. It's written as part of the &quo= t;experiments to be conducted":

DRAFT> =C2= =A0 =C2=A0 =C2=A0In
=C2=A0 =C2=A0 =C2=A0 some scenarios, wei= ghted scheduling (over different paths) can be considered: for
= =C2=A0 =C2=A0 =C2=A0 example, the paths with lower metrics (i.e., higher qu= ality) can
=C2=A0 =C2=A0 =C2=A0 transfer more datagrams compared = to paths with higher metrics.


<= div>

=C2=A0

Technically, my first issue is that OLSRv2 distribut= es a partial topology, so this is working at a disadvantage. OK, but this i= sn=E2=80=99t discussed, and - with the one exception of picking MPRs - tradeoffs of the incompleteness of the topology and overheads aren= =E2=80=99t even discussed. For a start, TC messages contain advertised neig= hbours. Advertised neighbours must include all MPR selectors, but may inclu= de more neighbours - up to all neighbours. I would expect a discussion of this. (I=E2=80=99m also not actually sure h= ow good the alternative MPR heuristics are, that=E2=80=99s me needing to re= ad and think more.)

=C2=A0

In a pure MP-OLSRv2 network, no modification is requ= ired regarding the MPR selection. Because the routers choose MPRs independe= ntly, and the MPR-selection is non-optimal, we can obtain multiple paths in= most cases thanks to the topology redundancy. This has been proven in both simulation study and field tests = with various node densities.=C2=A0

=C2=A0

CMD> References? And even if so, I= would expect a discussion of the subject. And that still doesn=E2=80=99t a= ddress the advertised neighbours issue.

<= /div>

Some papers from co-authors = of the draft:

[1] Multipath optimized link state routing for mobile ad hoc networ= ks
J Yi, A Adnane, S Da= vid, B Parrein
Ad Hoc N= etworks 9 (1), 28-47

[2] Simulation and performance analysis= of MP-OLSR for mobile ad hoc networks
J Yi, E Cizeron, S Hamma, B Parrein
Wireless Communications and Networking Confere= nce, 2008. IEEE WCNC 2008.=C2=A0

[3] Multipath OL= SR: simulation and testbed
J Yi, S David, HA Adnane, B Parrein, X Lecourtier
5th OLSR Interop/Workshop

[4] Q= OS ENHANCED HYBRID MULTIPATH ROUTING PROTOCOL FOR MOBILE ADHOC NETWORKS
J Yi, B Parrein, D R= adu
Wireless Person= al Multimedia Communications (WPMC), 2011 14th International Symposium on

And from other 3rd party rese= archers, who used tested MP-OLSR and developed extensions based on MP-OLSR:=

Exper= imental performance comparison of single-path and multipath routing in VANE= Ts
2014 IEEE Glob= al Information Infrastructure and Networking Symposium (GIIS)=C2=A0

=
QOS ENHANCED HYBR= ID MULTIPATH ROUTING PROTOCOL FOR MOBILE ADHOC NETWORKS
<= div>International Journal of Distributed= and Parallel Systems3.6 (Nov 2012): 89-105.

A multipath routing strategy to p= revent flooding disruption attacks in link state routing protocols for MANE= Ts
Journal of Network a= nd Computer Applications
Volume 36, Issue 2, March 2013, Pages 744=E2=80=93755

Performance Evaluation of MBA-OLSR Routing Protoco= l for MANETs
W= aheb A. Jabbar, Mahamod Ismail, and Rosdiadee Nordin
Journal of Computer Networks and C= ommunications
Volume 20= 14 (2014), Article ID 951638
http://www.hindawi.com/journals/jcnc/2014/951638/abs/

An enhanced MP-OLSR protocol for MANETs
A Boushaba, A Benabbou= , R Benabbou
2014 I= nternational Conference on Next Generation Networks and Services (NGNS)
=

=C2=A0

I don=E2=80=99t understand (I may have missed) how S= R_TC_INTERVAL is used. But the description in 5.1 isn=E2=80=99t clear. Why = would we have separate TC messages? And why would MP be prepared to do anyt= hing ten times slower?

=C2=A0

This is to deal with the OLSRv2/MP-OLSRv2 mixed netw= ork. As we mentioned in our previous post, an MP-OLSR router can be recogni= zed as source-enabled unless it generates a HELLO or TC message. So what we= do is:=C2=A0

=C2=A0 =C2=A0- MP-OLSR enabled routers MUST generate= TC messages even it's not required to do so according to normal OLSR p= rocess, but with longer interval. This is because the change from MP-OLSR e= nabled to OLSR-only router is very rare compared to topology changes. The corresponding SR_OLSR_HOLD_TIME will be set to lo= nger value also.=C2=A0

=C2=A0 =C2=A0 - During routing MPR selection, an MP-= OLSR enabled router SHOULD be firstly considered. The number of MP-OLSR ena= bled MPRs MUST be equal or greater than NUMBER_OF_PATHS, providing there ar= e enough MP-OLSR symmetric neighbors. Or else, all the MP-OLSR routers are selected as MPR.

=C2=A0

=C2=A0CMD> N= ot happy with that. That assumes in effect that multipath routes are more s= table - because that=E2=80=99d what sending ten times less often means. And= if you are sending ten times less often, that will require ten times the validity time. Which will cause those links to hang around l= onger, and will be used by non-MP routers in the same way. (It=E2=80=99s ev= en possible that a compliant implementation might choose to preferentially = use links with longer validity times, all else being equal. I=E2=80=99ve never tried that, but it=E2=80=99s an obvio= us possibility in some heterogeneous networks.) If ten times longer is OK f= or some links, why not all? I think there=E2=80=99s a problem here - how mu= ch work with highly mobile mixed networks has been done?


=C2=A0<= /div>

=C2=A0

I=E2=80=99ve been critical of AODVv2 underspecifying= interaction with IP. I=E2=80=99m going to make the same criticism here, gi= ven the suggestion of a reactive multi-path route determination. I=E2=80=99= m actually not keen on that idea at all, I think it needs more discussion. <= u>

=C2=A0

The MP-OLSR is a bit different from AODVv2 -- the ro= ute calculation is local. It doesn't require DSR/AODV-like route discov= ery/route reply (which can have long delay). Therefore, no buffer (or very = little buffer) is required: the packet is either sent out or dropped. I think there is no need to go to details o= n how to trigger the route calculation, which is implementation specific.= =C2=A0

Then for the source routing part, it's just stan= dard IP routing.=C2=A0

=C2=A0

CMD> No, it=E2=80=99s introduced s= omething new to OLSRv2, the need to be triggered by IP. Somebody (Henning?)= criticising AODVv2 made the observation this isn=E2=80=99t actually easy to do. And it=E2=80=99s new to OLSRv2, and unnecessary. I=E2=80=99m s= trongly against this as a specification.

=C2=A0

Note that as this is local, you could choose= to do this locally if you wanted to and still interoperate. I wouldn=E2=80= =99t be as set against this as an option in a highly resource limited router. But as the only specification, that must b= e done this way? No. I=E2=80=99m against this draft proceeding with this as= the only option.


=

=C2=A0

It also, I think, is broken in that there is no indi= cation of how and when these paths are expired. This alone I think requires= a new draft.

=C2=A0

In fact, in the previous revision (-06), there is a = valid time field in the multi-path routing set. But it's removed to mat= ch RFC7181-style based on the comments received (because Routing Set in RFC= 7181 is not based on timer-based expiration either). All the tuples in the Multi-path Routing Set will be removed when= ever there is need to update the OLSRv2 Routing Set. This can make it more = reactive to topology changes.=C2=A0

We will clarify it in the next revision.=C2=A0

=C2=A0

Yes, it needs clarification however t= he set is created, proactively or reactively.

=C2=A0

But there=E2=80=99s more. If proactive, when= it expires, it actually is replaced. (The Routing Set in OLSRv2 is describ= ed as recalculated, but of course intelligent differential update is not just allowed but a good idea.) But reactive? Ar= e you going to remove it and re-trigger its calculation from IP? Or how oth= erwise to decide when to stop recalculating it?


And before that discussion on whether a reactive mec= hanism that OLSRv2 otherwise doesn=E2=80=99t have is acceptable. (I don=E2= =80=99t think it is.)

=C2=A0

Personally, I don't see why it's not accepta= ble. Here I just want to note that this is an experimental draft. As far as= I can see, if we have:

=C2=A0

=C2=A0 =C2=A0- a clear specification

=C2=A0 =C2=A0- a mechanism that can bring potential = performance benefit and won't break existed networks

=C2=A0 =C2=A0- some simulation study and implementat= ion that prove the idea actually works and can be implemented (the implemen= tation is even not mandatory to standard track protocol -- although I think= it's not a good policy)

=C2=A0 =C2=A0- people interested in the idea<= u>

=C2=A0

we already have good reason to move ahead?=C2=A0<= /u>

=C2=A0

CMD> I don=E2=80=99t agree. A spec= ification fills a space. A poor specification is hard to push aside if a be= tter one comes along. And I think a mandatory reactive mechanism in a multipath OLSrv2 is poor. And it=E2=80=99s easily addressed= , define how you calculate it, make the norm that you maintain (as the norm= al Routing Set) but (if you want to) allow a reactive alternative (where yo= u can send rather than drop - I see no reason to drop - using the standard Routing Set in the interim.

<= /div>

=C2=A0

=C2=A0

I=E2=80=99m not as familiar as I should be with loos= e source routing. Given that this protocol allows routes of non-minimum met= ric, is there any possibility of the interaction of the two allowing looping, especially with different routers having possibly differ= ent views of the topology?

=C2=A0

When loose source routing is used, the forwarding de= cision is based on the forwarding table generated by OLSRv2. So if there is= a loop, it's a loop in OLSRv2 (which is possible, due to attacks or hi= gh dynamic topology).=C2=A0

=C2=A0

CMD> That=E2=80=99s one of those n= on-proof arguments that I=E2=80=99m not sure of. I can=E2=80=99t see an inf= inite loop, but the slack in the process means suppose you have A - B - C - D - E loosely routed, and now you need to go from B to C. Is it possib= le for D to be on the shortest path from B to C?


JY>=C2=A0
It should be very rare. I can *imagine* that might happen for IPv4 network= s, if:


=C2=A0 =C2=A0- The packet being forwarded will travel more hops, but it = can get to the destination eventually.=C2=A0





=C2=A0

Some sort of proof (which might already exist) would= be a good idea here. Incidentally why does the multiplicative factor on ro= ute metrics (CUTOFF_RATIO) have to be strictly greater than one? One should work.

=C2=A0

The description of the multipath Dijkstra doesn=E2= =80=99t really explain fp and fe. With the appendix one begins to get an id= ea, but the main text should not depend on an appendix in that way. And those are defined parameters, not an example.

=C2=A0

will clarify the description.=C2=A0

=C2=A0

and thanks again for the comments.=C2=A0

=C2=A0

regards

=C2=A0

Jiazi

=C2=A0

=C2=A0

=C2=A0

--

Christopher De= arlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________________________________________= ______

T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, = Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai=

BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office= : Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************=


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

=C2=A0


--001a11c3ad0c38ba9d05339e73b2-- From nobody Wed May 25 16:51:21 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C9112DE64; Wed, 25 May 2016 16:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGDck26YCot6; Wed, 25 May 2016 16:51:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531FD12DE37; Wed, 25 May 2016 16:50:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7A22218000C; Wed, 25 May 2016 16:49:53 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160525234953.7A22218000C@rfc-editor.org> Date: Wed, 25 May 2016 16:49:53 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] RFC 7859 on Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 23:51:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7859 Title: Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols Author: C. Dearlove Status: Experimental Stream: IETF Date: May 2016 Mailbox: chris.dearlove@baesystems.com Pages: 17 Characters: 36651 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-manet-ibs-05.txt URL: https://www.rfc-editor.org/info/rfc7859 DOI: http://dx.doi.org/10.17487/RFC7859 This document extends RFC 7182, which specifies a framework for (and specific examples of) Integrity Check Values (ICVs) for packets and messages using the generalized packet/message format specified in RFC 5444. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an Identity-Based Signature (IBS), defined according to the Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507. This document is a product of the Mobile Ad-hoc Networks Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon May 30 09:04:01 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4C112D0DB; Mon, 30 May 2016 09:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycXc2ccjGn7y; Mon, 30 May 2016 09:03:58 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CC012D0FD; Mon, 30 May 2016 09:03:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 08DF426324E; Mon, 30 May 2016 09:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1464624237; bh=d4sxJsiAr/ry3TMbkT8hTXt0C0kMIeP3sSHwJG+kxZ0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=dmRrWsVyCdm5Kwb0lyfJOF//5B0Dv1kIAtqBeED2djOuLnX9ApVMrOD5A9oKhlUmT hjvt3l6YtdPzHwQKQRlMKHolC0sfLNj/LWIgtsMGqTOpnwUuHgz0Pq9HUD34W0f/5X WpvOyPytsAHmUnjqX/zoATu8IVAqUYLz8ojRxavU= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [129.104.89.231] (unknown [129.104.89.231]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id CE96A2408A3; Mon, 30 May 2016 09:03:55 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_ABAB396E-7D4B-47DD-B8F7-B0A6A3D7DB6D" From: ietf@thomasclausen.org In-Reply-To: Date: Mon, 30 May 2016 18:03:50 +0200 Sendlaterdate: Mon, 30 May 2016 18:03:50 +0200 Message-Id: <7B2659F0-40E1-4DEC-AE65-D9C027198BC9@thomasclausen.org> References: <20160504170444.8256.99788.idtracker@ietfa.amsl.com> To: Stan Ratliff X-Mailer: Apple Mail (2.3124) Archived-At: Cc: manet-ads@ietf.org, "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 16:04:00 -0000 --Apple-Mail=_ABAB396E-7D4B-47DD-B8F7-B0A6A3D7DB6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mr. Ratliff, > On 23 May 2016, at 17:17, Stan Ratliff wrote: >=20 > Mr. Clausen,=20 >=20 > The referenced discussion did take place. Very well. Given that you affirmed a week ago that: > The consensus going forward was to begin the post-WGLC effort (e.g. = find a document shepherd, do the write-up, etc).=20 I believe that it is legitimate to ask: has any progress been made by = the chairs on those post-WGLC efforts? WGLC closed 4+ weeks ago on this document.=20 Thomas >=20 > Regards, > Stan >=20 >=20 > On Mon, May 23, 2016 at 1:26 AM, Thomas Clausen = > wrote: > So, how did that conversation with Mr. Ratliff go? Unless I've missed = a datatracker notification, motion has grind to a halt regarding this = doc? >=20 > Thomas >=20 > -- > Thomas Heide Clausen=C2=A0 = =E2=80=A2 @thclausen=C2=A0 =E2=80=A2 = thomasclausen.org=C2=A0 > www.arkko.com/tools/allstats/thomasheideclausen.html = >=20 > On 05 May 2016, at 05:55, Justin Dean > wrote: >=20 >> Ack. I'll talk with Stan ASAP and keep things moving. >>=20 >> Justin >>=20 >> On Wed, May 4, 2016 at 1:06 PM, Dearlove, Christopher (UK) = > = wrote: >> This includes all of the issues I listed in my previous email of = comments made at WGLC. >>=20 >> The authors request starting all the post-WGLC things to do. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> = __________________________________________________________________________= >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet = >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = >=20 >=20 --Apple-Mail=_ABAB396E-7D4B-47DD-B8F7-B0A6A3D7DB6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mr. Ratliff,

On = 23 May 2016, at 17:17, Stan Ratliff <ratliffstan@gmail.com> wrote:

Mr. Clausen, 

The referenced discussion did take = place.

Very = well.

Given that you affirmed a week = ago that:

= The consensus going forward was to begin the post-WGLC effort (e.g. find = a document shepherd, do  the write-up, = etc). 

I= believe that it is legitimate to ask: has any progress been made by the = chairs on those post-WGLC efforts?

WGLC closed 4+ weeks ago on this = document. 

Thomas




Regards,
Stan


On Mon, May 23, 2016 at 1:26 AM, Thomas Clausen = <ietf@thomasclausen.org> = wrote:
So, how did that conversation with Mr. = Ratliff go? Unless I've missed a datatracker notification, motion has = grind to a halt regarding this doc?

Thomas

--
Thomas Heide Clausen  =E2=80=A2  @thclausen   = =E2=80=A2  = thomasclausen.org www.arkko.com/tools/allstats/thomasheideclausen.html

On 05 May = 2016, at 05:55, Justin Dean <bebemaster@gmail.com> wrote:

Ack. I'll talk = with Stan ASAP and keep things moving.

Justin

On Wed, May 4, 2016 at 1:06 PM, = Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
This includes all of = the issues I listed in my previous email of comments made at WGLC.

The authors request starting all the post-WGLC things to do.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
= __________________________________________________________________________=

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



= --Apple-Mail=_ABAB396E-7D4B-47DD-B8F7-B0A6A3D7DB6D-- From nobody Mon May 30 09:19:43 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567D512D094; Mon, 30 May 2016 09:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwWczlf0pCTI; Mon, 30 May 2016 09:19:39 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF55D12B01E; Mon, 30 May 2016 09:19:38 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id a6so19792605vkg.3; Mon, 30 May 2016 09:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=DwjorMmvM2belLBMOL6VE0Z7694Q2+Vgc+2wLMUs2Tw=; b=ez4bb1bXVGwlfTyrpX1a9cQNrhQurA3V0NjJqo3wQqK44XWUEpyIeXdDsQI1No/jL+ RWL+ssaNLb7iDEuupVYsa64rkE5ibxqzuG1r9F4aRDyiPp4TmJubPU3l0JHERVrx6rW0 U6VtDrCjgRpD544zhmHD9gwJJSSca4szYxwmlGGhpwinMFVvw5OiYqGz0Dq7lT8lNAQE ZFH/DN354OvQdIGaZhOGOQ8DR6D97eBmp4EykyUH+xsUff0GdaWI3ELrwM0OWG80D7CH iRmu2Fu8xDIOeR04v4iy3F0FsLypJwsbnFCAQMVATc1ud5mlgfYfI8tkUvbYyuUux+hr EqdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DwjorMmvM2belLBMOL6VE0Z7694Q2+Vgc+2wLMUs2Tw=; b=M74rxykLVWKJ+077hptf3+u8n+tBfyEZucYBjB2YtpmHuXdjgsuC4W61cfzFifvo02 jHp0XZ0xpMCvj6UsWjIFmdrM54Ighvl0cnk/Gq6Eii2JGLIG/tpS/5Phz29ySHBhXrNt Z+v4syTusb5R2LyVmreIX42Aat0JVe3MOeKtZTu6NZDuL3wSdsPuM6aXtJh3AgFX5nBf pzIoUuM2UmrJJoRiR4GCcqk4aoOlf0xG+sec1VTXofJSwEliTck/BFJaBEVBZj6B0bm7 GEevzKOOmV1UbH+Fw4LcZeDWKrm+m67r+kU+uxfxLPNmpGf/ysbPIQ1SpH/tHyZ2NUdW 3oGg== X-Gm-Message-State: ALyK8tIVFDwF/eeNBoTI4CWbuc0HE2tu2QdUUVdCEJE8CSoH0rzAJDwoo5Q2j1iw4Vc4QTmlrDD2690RrOEGJg== MIME-Version: 1.0 X-Received: by 10.31.236.1 with SMTP id k1mr12401406vkh.130.1464625177789; Mon, 30 May 2016 09:19:37 -0700 (PDT) Received: by 10.176.5.134 with HTTP; Mon, 30 May 2016 09:19:37 -0700 (PDT) In-Reply-To: <7B2659F0-40E1-4DEC-AE65-D9C027198BC9@thomasclausen.org> References: <20160504170444.8256.99788.idtracker@ietfa.amsl.com> <7B2659F0-40E1-4DEC-AE65-D9C027198BC9@thomasclausen.org> Date: Mon, 30 May 2016 12:19:37 -0400 Message-ID: From: Justin Dean To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=94eb2c095b00738c310534119f86 Archived-At: Cc: manet-ads@ietf.org, Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 16:19:41 -0000 --94eb2c095b00738c310534119f86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ack. Thanks for the poke. This will be taken care of post haste. Justin On Mon, May 30, 2016 at 12:03 PM, wrote: > Mr. Ratliff, > > On 23 May 2016, at 17:17, Stan Ratliff wrote: > > Mr. Clausen, > > The referenced discussion did take place. > > > Very well. > > Given that you affirmed a week ago that: > > The consensus going forward was to begin the post-WGLC effort (e.g. find = a > document shepherd, do the write-up, etc). > > > I believe that it is legitimate to ask: has any progress been made by the > chairs on those post-WGLC efforts? > > WGLC closed 4+ weeks ago on this document. > > Thomas > > > > > Regards, > Stan > > > On Mon, May 23, 2016 at 1:26 AM, Thomas Clausen > wrote: > >> So, how did that conversation with Mr. Ratliff go? Unless I've missed a >> datatracker notification, motion has grind to a halt regarding this doc? >> >> Thomas >> >> -- >> >> *Thomas Heide Clausen =E2=80=A2 @th= clausen >> =E2=80=A2 thomasclausen.org >> www.arkko.com/tools/allstats/thomasheidec= lausen.html >> * >> >> On 05 May 2016, at 05:55, Justin Dean wrote: >> >> Ack. I'll talk with Stan ASAP and keep things moving. >> >> Justin >> >> On Wed, May 4, 2016 at 1:06 PM, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> wrote: >> >>> This includes all of the issues I listed in my previous email of >>> comments made at WGLC. >>> >>> The authors request starting all the post-WGLC things to do. >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer >>> BAE Systems Applied Intelligence Laboratories >>> >>> _______________________________________________________________________= ___ >>> >>> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > --94eb2c095b00738c310534119f86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ack.=C2=A0 Thanks for the poke. This will be taken ca= re of post haste.

Justin
<= br>
On Mon, May 30, 2016 at 12:03 PM, <ie= tf@thomasclausen.org> wrote:
Mr. Ratliff,

=
On 23 May 2016, at 17:17, S= tan Ratliff <= ratliffstan@gmail.com> wrote:

Mr. Cla= usen,=C2=A0

The referenced discussion did take place.

Very well.

Given that you affirmed a week ago that:

= The consensus going forward was to begin the post-WGLC effort (e.g. find a = document shepherd, do =C2=A0the write-up, etc).=C2=A0

I believe that it is legitimate to ask:= has any progress been made by the chairs on those post-WGLC efforts?
=

WGLC closed 4+ weeks ago on this document.=C2=A0
<= span class=3D"HOEnZb">

Thomas




Regards,
Stan


On Mon, May 23, 2016 at 1:26 AM, Thomas= Clausen <ietf@thomasclausen.org> wrote:
So, how did that conversation wi= th Mr. Ratliff go? Unless I've missed a datatracker notification, motio= n has grind to a halt regarding this doc?

Thomas
--<= div style=3D"font-family:UICTFontTextStyleTallBody">Thomas Heide Clausen=C2=A0= =C2=A0=E2=80=A2=C2=A0=C2=A0@thc= lausen=C2=A0=C2=A0 =E2=80=A2=C2=A0 thomasclausen.org=C2=A0
www.ar= kko.com/tools/allstats/thomasheideclausen.html
On 05 May 2016, at 05:55, Justin Dean <bebemaster@gmail.com> wrote:

=
Ack. I'll talk wit= h Stan ASAP and keep things moving.

Justin

On Wed, May 4, 2016 at 1:06 PM, D= earlove, Christopher (UK) <chris.dearlove@baesystems.com&g= t; wrote:
This includes all of the= issues I listed in my previous email of comments made at WGLC.

The authors request starting all the post-WGLC things to do.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________<= br>
_______________________________________________
manet mailing list
manet@ietf.org
https://www.iet= f.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



--94eb2c095b00738c310534119f86-- From nobody Mon May 30 14:25:36 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A93C12D666 for ; Mon, 30 May 2016 14:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qCqZLW1dgSm for ; Mon, 30 May 2016 14:25:33 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE55D12D667 for ; Mon, 30 May 2016 14:25:28 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id b73so55916921lfb.3 for ; Mon, 30 May 2016 14:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=BDNWPuvC9lH1Lmhz3wRV24k/LW7t+My3np3O7Z5N5j0=; b=VcNDuoO3R+S+bH87tZGsCLehJbrMlL9YrSlRvSqUkvqxuF9PNgf8AMlyh1bQm3A50d aqEV1ckBeeNsLYeb17d3HnQeGJKu9874UC4WFpP1aR8jPsiuX/V2ZIl9PNEYWXu9Cf1B v7WJsEULRjUz4jF4wyVIoZbACDsAE/srfag5oDwpY7Q5/gq9Qy6UE9p7Bu/CIb4kj0hV nUq3nd3X5wBjgGNDAwpjRI/YSvmuU22LDC4U+L87RPxn35Na66RvlvkV7ftCTPBNUpe3 ftLZGtZLLa2SXzVnGt6Qn6//x2k/CqurkvzTk4INRdLgY1Tm0bxuH5I8lugYlaa3mxfV oTbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=BDNWPuvC9lH1Lmhz3wRV24k/LW7t+My3np3O7Z5N5j0=; b=RvETyiooHRg1pYptTm/k2vmx+p52HW3nE71JknaOOUcEu4eDUOHCtIaY6t/FHiKzlo AgduG7/KyyHA9cjVAOw2MssaFt3GYfdGu+MfafXrDqqNZyigG2HNJErO+37Oav5g7UTg E/5kHf94UlI/kMo2wA6ixsXHdYx7zCy4nFvMtlBFXo69fDSzvoewWn0EH5RpFeWCLv1m +QF9Y5lf9/VAO/GqXP9zpc1Itpp7qMLN3GTti2GHxK+SWjUQJ0I16v/I/W33xJcYEqW5 98gvAFXg3qP57Xbdh/oCC345oZbkf97jCWAwdlSow2t71HaewXBDr0xSJjdtP6OJcmCN WQ6Q== X-Gm-Message-State: ALyK8tL9KsDQiiRVgG5WmM3G051VNB0MnOvyROdCWFZMm2luUEIflJfZX3IYURacd2KgxPECd+LF0i+tri3OTA== MIME-Version: 1.0 X-Received: by 10.25.150.195 with SMTP id y186mr8134323lfd.169.1464643526936; Mon, 30 May 2016 14:25:26 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.114.77.4 with HTTP; Mon, 30 May 2016 14:25:26 -0700 (PDT) Date: Mon, 30 May 2016 23:25:26 +0200 X-Google-Sender-Auth: qDnxcOz2BWctYymlNRpUzBTIyYY Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=001a11402104255359053415e5b9 Archived-At: Subject: [manet] draft-ietf-manet-olsrv2-multipath-08 WGLC finished X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 21:25:35 -0000 --001a11402104255359053415e5b9 Content-Type: text/plain; charset=UTF-8 Hi all, The WGLC of draft-ietf-manet-olsrv2-multipath-08 has finished. We got valuable comments from Chris -- thanks very much! Based on the comments received, a new revision will be submitted soon with following updates: - Make the style more consistent with other OLSRv2-RFC suite. - Make the reactive multipath calculation optional. Both proactive and reactive calculation can be used. Such modification won't impact interoperability. - Clarify the use of SR_TC_INTERVAL. - Clarify the generation/update of Multi-path routing Set (this is related to reactive/proactive calculation also) - Clarify the use of fp and fe in the multipath Dijkstra algorithm - Chris raised the concern about impact partial topology map on multipath calculation. As indicated in https://www.ietf.org/mail-archive/web/manet/current/msg19038.html , with non-trival amount of studies performed, no issue related to this has been reported yet. As it's related to the MPR-selection algorithm used, we can put it as one of the experimental points to make people pay attention to it, so that new issues can be reported. regards Jiazi --001a11402104255359053415e5b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0

The WGLC of draft-ietf-ma= net-olsrv2-multipath-08 has finished. We got valuable comments from Chris -= - thanks very much!

Based on the comments received= , a new revision will be submitted soon with following updates:
<= br>
=C2=A0 =C2=A0- Make the style more consistent with other OLSR= v2-RFC suite.=C2=A0

=C2=A0 =C2=A0- Make the reacti= ve multipath calculation optional. Both proactive and reactive calculation = can be used. Such modification won't impact interoperability.=C2=A0

=C2=A0 =C2=A0- Clarify the use of SR_TC_INTERVAL.=C2= =A0

=C2=A0 =C2=A0- Clarify the generation/update o= f Multi-path routing Set (this is related to reactive/proactive calculation= also)

=C2=A0 =C2=A0- Clarify the use of fp and fe= in the multipath Dijkstra algorithm

=C2=A0 =C2=A0= - Chris raised the concern about impact partial topology map on multipath c= alculation. As indicated in=C2=A0https://www.ietf.org/mail-archive/web/m= anet/current/msg19038.html , with non-trival amount of studies performe= d, no issue related to this has been reported yet. As it's related to t= he MPR-selection algorithm used, we can put it as one of the experimental p= oints to make people pay attention to it, so that new issues can be reporte= d.=C2=A0

regards

Jiazi
--001a11402104255359053415e5b9-- From nobody Tue May 31 12:43:45 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C60012D63E for ; Tue, 31 May 2016 12:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Za3Q2f3hp50 for ; Tue, 31 May 2016 12:43:42 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEEA012D7F2 for ; Tue, 31 May 2016 12:43:41 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id w16so85744168lfd.2 for ; Tue, 31 May 2016 12:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=woBU67vxB1h3WxAwtuS/n3qOXbvpUVgaGif8P5QPFAs=; b=tubW6iPgw6GE9qSpVIaJENp7p2SpBZaEypjdczr/kO5vHU2JW3i7L0TgpkYaOFtFCN XS3o7k5fIsgeFm5h8oYttKv0piSfCBLPSQ24DfaofUR/i5+4+PwyiuGqHC5r9Tp0M/Jy 6WmBQoxNhGQqFW/RBncqG7YTQLdhwK7aBgumTa5Q9bghXCwlcJ906af+l94i6Fqu90TD TlGcZljMGkfKFB0BjkHZ7sElWJIkHTxgDEIOn9O8BmYmNqFVLnlETg9CAoCAURO4Ns/c 3fi6rVDTot66zM3t0ZcrhX9IDORx229KlY9UdBdXQ87edSVd43F1JrvUrSugWgKV2I5p jJRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=woBU67vxB1h3WxAwtuS/n3qOXbvpUVgaGif8P5QPFAs=; b=L0HYIVIWN596V+2pUs7+gQIZFj0PW6CG8bFxEhcJvvp51EBqCSRuGkzkcFMw8ZKGi3 AedFPxIF23x66MC5Xx+UDeL63wR4cvNoJkgcr5nLCkeqB/Vq7kh9yhQDqReiYed8Uv9a U8znow4l/Rxqh9qMYZVCptpyPj23MJ6Ams2N03rCuneD+3m4LT23yphrU2Bid+BJXKGj gmSZrteUxwxlzhqXjA2rqbse+8Xmxdbx9FHsUKGNeBZS5mmroxtzEcqn6iFRmM6U1hYw BVuuRbQENXkD4VNMPoGQXaLdsrkuKm1XiSSUJSQjpBZQcuNcqyFJXutkUtYbdPC5w/G9 9b5A== X-Gm-Message-State: ALyK8tLeAmHTc/25Zqk9DuLqEY35TzGCerymGJ188frm5vF2dZAkmPLJmIjkNq2dMYajaWM8EnTJJLhcqa6jww== MIME-Version: 1.0 X-Received: by 10.25.151.139 with SMTP id z133mr101671lfd.30.1464723820020; Tue, 31 May 2016 12:43:40 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.114.77.4 with HTTP; Tue, 31 May 2016 12:43:39 -0700 (PDT) Date: Tue, 31 May 2016 21:43:39 +0200 X-Google-Sender-Auth: j_4_k9e_IhjEeNtXLEUuTldKtWk Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=001a114015d6fc9f55053428968d Archived-At: Subject: [manet] WGLC request for draft-ietf-manet-olsrv2-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 19:43:44 -0000 --001a114015d6fc9f55053428968d Content-Type: text/plain; charset=UTF-8 Hi, We submitted a new revision of draft-ietf-manet-olsrv2-sec-threats at the begin of May. The authors believe that the document is ready for WGLC. We would like to ask the WG chairs for a WGLC on the document. Here is the link to the draft: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-sec-threats-02 . It tends for informational track. regards Jiazi --001a114015d6fc9f55053428968d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

We submitted a new revision o= f=C2=A0draft-ietf-manet-olsrv2-sec-threats at the begin of May. The authors= believe that the document is ready for WGLC.=C2=A0

We would like to ask the WG chairs for a WGLC on the document.=C2=A0

Here is the link to the draft:=C2=A0
It tends for informational track.=C2=A0

regards

Jiazi
--001a114015d6fc9f55053428968d-- From nobody Tue May 31 13:38:19 2016 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C92512D64F for ; Tue, 31 May 2016 13:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rWOsd3BIDTT for ; Tue, 31 May 2016 13:38:17 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12E412D653 for ; Tue, 31 May 2016 13:38:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CD6462412A3 for ; Tue, 31 May 2016 13:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1464727096; bh=jFPE4I8JaCF+WRpCe11Qtr10wtmFMtWykc8Rmoo6qLE=; h=From:Subject:Date:References:In-Reply-To:To:From; b=lyzSLm96dQG+WJ2n/a9r8kxrI+kLqwKNPXWSzHMhSGlw/dxQ/IVOU712OQ4pROLHt ribZYa179mjdSAH+KYtRLoQZB8raNtavE15+hyFvQNueelGtJpQg51B+Ehkl5RhFyi UrPcZHLIziB+TwlDYz17yzLItmrEsefCqQ45Q808= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.66] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 603F52404DB for ; Tue, 31 May 2016 13:38:16 -0700 (PDT) From: Thomas Clausen Content-Type: multipart/alternative; boundary=Apple-Mail-06843AF0-8437-4E14-9DBF-7D15C9136DAC Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Tue, 31 May 2016 22:38:13 +0200 References: In-Reply-To: To: manet@ietf.org X-Mailer: iPhone Mail (13F69) Archived-At: Subject: Re: [manet] WGLC request for draft-ietf-manet-olsrv2-sec-threats-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:38:18 -0000 --Apple-Mail-06843AF0-8437-4E14-9DBF-7D15C9136DAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 31 mai 2016, at 21:43, Jiazi YI wrote: >=20 > Hi,=20 >=20 > We submitted a new revision of draft-ietf-manet-olsrv2-sec-threats at the b= egin of May. The authors believe that the document is ready for WGLC.=20 >=20 > We would like to ask the WG chairs for a WGLC on the document.=20 >=20 +1 Other recently-WGLCed documents are either forwarded to the AD, or are retur= ned to the authors for a revision, so a WGLC of this document would seem a g= ood way of "keeping the pipeline moving". Best, Thomas > Here is the link to the draft:=20 > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-sec-threats-02 .=20 > It tends for informational track.=20 >=20 > regards >=20 > Jiazi > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-06843AF0-8437-4E14-9DBF-7D15C9136DAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 31 mai 2016, at 21:4= 3, Jiazi YI <ietf@jiaziyi.com>= wrote:

Hi,&nbs= p;

We submitted a new revision of draft-ietf-manet-o= lsrv2-sec-threats at the begin of May. The authors believe that the document= is ready for WGLC. 

We would like to ask the W= G chairs for a WGLC on the document. 

<= /blockquote>

+1

Other recently-WGLCed docum= ents are either forwarded to the AD, or are returned to the authors for a re= vision, so a WGLC of this document would seem a good way of "keeping the pip= eline moving".

Best,

Thoma= s


Here is the link to the draft: 
It te= nds for informational track. 

regards

Jiazi
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-06843AF0-8437-4E14-9DBF-7D15C9136DAC--
Mr. Clausen,=C2=A0

The referenced discu= ssion did take place. The consensus going forward was to begin the post-WGL= C effort (e.g. find a document shepherd, do =C2=A0the write-up, etc).=C2=A0=

Regards,
Stan


On Mon, May 23, = 2016 at 1:26 AM, Thomas Clausen <ietf@thomasclausen.org> wrote:
So, how d= id that conversation with Mr. Ratliff go? Unless I've missed a datatrac= ker notification, motion has grind to a halt regarding this doc?
=

On 05 May 2016, at 05:55, Justin Dean <bebemaster@gmail.com= > wrote:

Ack. I'll talk with Stan ASAP and keep things moving.

J= ustin

On Wed, = May 4, 2016 at 1:06 PM, Dearlove, Christopher (UK) <chris.dear= love@baesystems.com> wrote:
This includes all of the issues I listed in my previous email of comments = made at WGLC.

The authors request starting all the post-WGLC things to do.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________<= br>
_________________________________= ______________
manet mailing list
manet@ietf.org
<= span>https://www.ietf.org/mailman/listinfo/manet

_____________________________________________= __
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet